[ python-Bugs-1257525 ] Encodings iso8859_1 and latin_1 are redundant
Bugs item #1257525, was opened at 2005-08-12 07:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Encodings iso8859_1 and latin_1 are redundant Initial Comment: ./lib/encodings contains both: iso8859_1.py latin_1.py Only one should be present. Martin says that latin_1 is faster. Using the 'iso' name would correlate better with the other ISO encodings provided. If the latin_1 code is faster, then it should be in the iso8859_1.py file. If an automated process produces the 'iso*' encodings, then it should either produce the faster code or stop producing iso8859_1. Regardless, one of the files should be removed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1257525 ] Encodings iso8859_1 and latin_1 are redundant
Bugs item #1257525, was opened at 2005-08-12 14:22 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Encodings iso8859_1 and latin_1 are redundant Initial Comment: ./lib/encodings contains both: iso8859_1.py latin_1.py Only one should be present. Martin says that latin_1 is faster. Using the 'iso' name would correlate better with the other ISO encodings provided. If the latin_1 code is faster, then it should be in the iso8859_1.py file. If an automated process produces the 'iso*' encodings, then it should either produce the faster code or stop producing iso8859_1. Regardless, one of the files should be removed. -- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-12 14:49 Message: Logged In: YES user_id=38388 Good point. The iso8859_1.py codec should be removed and added as alias to latin-1. Martin is right: the latin-1 codec is not only faster, but the Unicode integration code also has a lot of short-cuts for the "latin-1" encoding, so overall performance is better if you use that name for the encoding. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1256786 ] slice object uses -1 as exclusive end-bound
Bugs item #1256786, was opened at 2005-08-11 16:08 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256786&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bryan G. Olson (bryango) >Assigned to: Michael Hudson (mwh) Summary: slice object uses -1 as exclusive end-bound Initial Comment: The slice object passed to __getitem__ or __setitem__ reports an incorrect 'stop' value when the step is negative and the slice includes the 0 index. If one then actually tries to slice with what slice.indices returns, the result is wrong. Here's a demo: class BuggerAll: def __init__(self, somelist): self.sequence = somelist[:] def __getitem__(self, key): if isinstance(key, slice): start, stop, step = key.indices(len(self.sequence)) # print 'Slice says start, stop, step are:', start, stop, step return self.sequence[start : stop : step] print range(10) [None : None : -2] print BuggerAll(range(10))[None : None : -2] The above should print the same sequence twice, but actually prints: [9, 7, 5, 3, 1] [] Un-commenting the print statement in __getitem__ shows: Slice says start, stop, step are: 9 -1 -2 The problem is the stop value of -1. The slice object seems to think that -1 is a valid exclusive-end-bound, but when slicing, Python interprets negative numbers as an offset from the high end of the sequence. That is, range(10)[9 : -1 : -2] is the same as, range(10)[[9 : 9 : -2] which is the empty list. So what should the slice.indices return in this case, so that slicing with the returned values will work correctly? My experiments indicate: The start value can be any of: None, any integer >= 9, -1 The stop value can be either: None, any integer <= -11 Step is correct; it must be:-2 My favorite choice here is (9, None, -2). The doc for slice.indices currently says: This method takes a single integer argument /length/ and computes information about the extended slice that the slice object would describe if applied to a sequence of length items. It returns a tuple of three integers; respectively these are the /start/ and /stop/ indices and the /step/ or stride length of the slice. Missing or out-of-bounds indices are handled in a manner consistent with regular slices. http://docs.python.org/ref/types.html So using (9, None, -2) would require changing both the code and the doc (because None is not an integer). A stop value of -11 (or less) would require changing only the code. -- >Comment By: Michael Hudson (mwh) Date: 2005-08-12 14:02 Message: Logged In: YES user_id=6656 This is clearly in my area. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256786&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1257525 ] Encodings iso8859_1 and latin_1 are redundant
Bugs item #1257525, was opened at 2005-08-12 07:22 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Encodings iso8859_1 and latin_1 are redundant Initial Comment: ./lib/encodings contains both: iso8859_1.py latin_1.py Only one should be present. Martin says that latin_1 is faster. Using the 'iso' name would correlate better with the other ISO encodings provided. If the latin_1 code is faster, then it should be in the iso8859_1.py file. If an automated process produces the 'iso*' encodings, then it should either produce the faster code or stop producing iso8859_1. Regardless, one of the files should be removed. -- >Comment By: liturgist (liturgist) Date: 2005-08-12 08:12 Message: Logged In: YES user_id=197677 Ok. How about if we specify iso8859_1 as "(see latin_1)" in the documentation? The code will work the same regardless of which encoding name the developer uses. Right? -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-12 07:49 Message: Logged In: YES user_id=38388 Good point. The iso8859_1.py codec should be removed and added as alias to latin-1. Martin is right: the latin-1 codec is not only faster, but the Unicode integration code also has a lot of short-cuts for the "latin-1" encoding, so overall performance is better if you use that name for the encoding. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1194328 ] Reading from a killed shell script with popen* under linux
Bugs item #1194328, was opened at 2005-05-03 09:44
Message generated for change (Comment added) made by boukthor
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Vinz (boukthor)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reading from a killed shell script with popen* under linux
Initial Comment:
These are problems I've run into under linux (Mandrake
10.0 through 2006.0, Debian 3.1 and Gentoo) with python
versions ranging from 2.3.3 to 2.4:
If you run this:
import os
pout = os.popen("/bin/sleep 999")
print pout.read()
print pout.close()
and kill the "sleep", you get the desired behaviour:
the read returns an empty string when the process gets
killed and the close returns the killing signal.
However, if you put the "sleep" command in a shell
script, for example this simple "/tmp/test.sh":
#!/bin/sh
sleep 999
and run the script through popen (or one of the popen*
method of the os and popen2 module)
import os
pout = os.popen("/tmp/test.sh")
print pout.read()
print pout.close()
then kill the sh running "test.sh", the read never
returns and the shell remains as a zombie. You can get
some strange behaviour with the Popen* classes too
(whether bypassing the shell intervention or not). For
example, run this (and kill the subshell):
import popen2
sub = popen2.Popen3("/tmp/test.sh")
print sub.wait()
print sub.fromchild.read()
this time the wait correctly returns the signal that
killed the shell and removes it from the process table,
but the read hangs again.
As an added oddity, if you run the popen command from
an interactive prompt and raise a KeyboardInterrupt by
pressing Ctrl-C before trying to read from the pipe,
you kill the subprocess with the SIGINT...
I have a final suggestion: if you try reading the
output of a popen* method with a "for" statement like this:
import os
pout = os.popen("for i in $(seq 1 10); do echo $i;
sleep 1; done")
for l in pout: print l,
it waits for the subprocess to complete before going
into the loop. To get the output as it is piped, you
have to use the poll method of the Popen* classes
(which is not available under OSes other than Unix):
sub = popen2.Popen3("for i in $(seq 1 10); do echo $i;
sleep 1; done")
while (-1 == sub.poll()): print sub.fromchild.readline()
I don't know if this last behaviour can be fixed or not
but I'd suggest some mention of this in the manual if
it can't.
--
>Comment By: Vinz (boukthor)
Date: 2005-08-12 13:48
Message:
Logged In: YES
user_id=638508
The report #1180160 was only loosely related to the above
problem. In fact it is probably closer to the following :
761888 popen2.Popen3 and popen2.Popen4 leaks filedescriptors
892939 Race condition in popen2
998246 Popen3.poll race condition
1183780 Popen4 wait() fails sporadically with threads
NB : This bug is very incapacitating for me since I can't
figure any workaround and though I understand that
developers may have other priorities, I'd appreciate some
acknowledgement that somebody at least read this report...
--
Comment By: Vinz (boukthor)
Date: 2005-05-03 09:49
Message:
Logged In: YES
user_id=638508
Oops, just saw the report #1180160. I missed it because I
searched for popen, not Popen before posting. My bad. I'll
cross-reference the two.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1194328&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1257525 ] Encodings iso8859_1 and latin_1 are redundant
Bugs item #1257525, was opened at 2005-08-12 07:22 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Encodings iso8859_1 and latin_1 are redundant Initial Comment: ./lib/encodings contains both: iso8859_1.py latin_1.py Only one should be present. Martin says that latin_1 is faster. Using the 'iso' name would correlate better with the other ISO encodings provided. If the latin_1 code is faster, then it should be in the iso8859_1.py file. If an automated process produces the 'iso*' encodings, then it should either produce the faster code or stop producing iso8859_1. Regardless, one of the files should be removed. -- >Comment By: liturgist (liturgist) Date: 2005-08-12 09:01 Message: Logged In: YES user_id=197677 Where could one see some of the "shortcuts" in the Unicode integration code that make using "latin_1" faster in the runtime? I greped *.py and *.c, but could not readily identify any candidates. -- Comment By: liturgist (liturgist) Date: 2005-08-12 08:12 Message: Logged In: YES user_id=197677 Ok. How about if we specify iso8859_1 as "(see latin_1)" in the documentation? The code will work the same regardless of which encoding name the developer uses. Right? -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-12 07:49 Message: Logged In: YES user_id=38388 Good point. The iso8859_1.py codec should be removed and added as alias to latin-1. Martin is right: the latin-1 codec is not only faster, but the Unicode integration code also has a lot of short-cuts for the "latin-1" encoding, so overall performance is better if you use that name for the encoding. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1257525 ] Encodings iso8859_1 and latin_1 are redundant
Bugs item #1257525, was opened at 2005-08-12 14:22 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: M.-A. Lemburg (lemburg) Summary: Encodings iso8859_1 and latin_1 are redundant Initial Comment: ./lib/encodings contains both: iso8859_1.py latin_1.py Only one should be present. Martin says that latin_1 is faster. Using the 'iso' name would correlate better with the other ISO encodings provided. If the latin_1 code is faster, then it should be in the iso8859_1.py file. If an automated process produces the 'iso*' encodings, then it should either produce the faster code or stop producing iso8859_1. Regardless, one of the files should be removed. -- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-12 16:30 Message: Logged In: YES user_id=38388 To answer your questions: Yes, the encoding is the same for both latin-1 and iso8859-1. Specifying latin-1 instead of iso8859-1 will allow the code to use short-cuts. You have to grep for 'latin-1'. -- Comment By: liturgist (liturgist) Date: 2005-08-12 16:01 Message: Logged In: YES user_id=197677 Where could one see some of the "shortcuts" in the Unicode integration code that make using "latin_1" faster in the runtime? I greped *.py and *.c, but could not readily identify any candidates. -- Comment By: liturgist (liturgist) Date: 2005-08-12 15:12 Message: Logged In: YES user_id=197677 Ok. How about if we specify iso8859_1 as "(see latin_1)" in the documentation? The code will work the same regardless of which encoding name the developer uses. Right? -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-12 14:49 Message: Logged In: YES user_id=38388 Good point. The iso8859_1.py codec should be removed and added as alias to latin-1. Martin is right: the latin-1 codec is not only faster, but the Unicode integration code also has a lot of short-cuts for the "latin-1" encoding, so overall performance is better if you use that name for the encoding. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1257687 ] Solaris 8 declares gethostname().
Bugs item #1257687, was opened at 2005-08-12 11:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257687&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hans Deragon (deragon) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris 8 declares gethostname(). Initial Comment: In portpy.h line 377, we find: #ifdef SOLARIS /* Unchecked */ extern int gethostname(char *, int); #endif Well, on Solaris 8, that function is declared in /usr/include/unistd.h, thus a conflict. In unistd.h, there are a few #ifdef prior the declaration, so there might be some situation where the function is not declared. Of course, I cannot copy and paste the relevant section of unistd.h because of copyright. You might want to ask Sun Microsystem a copy of this file to patch this problem. My work around was to comment the above code in portpy.h. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257687&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1257728 ] error message incorrectly claims Visual C++ is required
Bugs item #1257728, was opened at 2005-08-12 15:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257728&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: error message incorrectly claims Visual C++ is required Initial Comment: Thank you for the excellent distutils tool! Two problems: First, this error message is emitted on win32, but it appears to be incorrect, inasmuch as the Microsoft compiler is not actually required: """ error: Python was built with version 7.1 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed. Error: Subprocess exited with result 1 for project core """ Second, the usage of distutils is somewhat confusing, as the following line emits that error message: ./setup.py build -c mingw32; ./setup.py install but the following line, which I intuitively believed to be equivalent at first, works to compile and install the package: ./setup.py build -c mingw32 install -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257728&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1257731 ] Make set.remove() behave more like Set.remove()
Bugs item #1257731, was opened at 2005-08-12 10:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257731&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Make set.remove() behave more like Set.remove() Initial Comment: class H(set): def __hash__(self):return id(self) s=H() f=set() f.add(s) f.remove(s) # this fails -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257731&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1257731 ] Make set.remove() behave more like Set.remove()
Bugs item #1257731, was opened at 2005-08-12 10:31 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257731&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Make set.remove() behave more like Set.remove() Initial Comment: class H(set): def __hash__(self):return id(self) s=H() f=set() f.add(s) f.remove(s) # this fails -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257731&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1257772 ] tkapp read-only attributes
Bugs item #1257772, was opened at 2005-08-12 17:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257772&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: peeb (peeble) Assigned to: Martin v. Löwis (loewis) Summary: tkapp read-only attributes Initial Comment: same as bug: [ 1164742 ] Tkdnd.py crashes due to read-only attributes Python 2.4.1 (#1, Mar 30 2005, 23:01:07) [GCC 3.3.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import Tkinter >>> r=Tkinter.Tk() >>> r.a=1 >>> del r.a Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/lib-tk/Tkinter.py", line 1660, in __delattr__ return delattr(self.tk, attr) TypeError: 'tkapp' object has only read-only attributes (del .a) The problem vanishes commenting out the __delattr__ methods in class Tk (module Tkinter.py): class Tk(Misc, Wm): ... def __delattr__(self, attr): "Delegate attribute access to the interpreter object" return delattr(self.tk, attr) I don't know if there is same subtle problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257772&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1023290 ] proposed struct module format code addition
Feature Requests item #1023290, was opened at 2004-09-06 13:42
Message generated for change (Settings changed) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1023290&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Josiah Carlson (josiahcarlson)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: proposed struct module format code addition
Initial Comment:
I believe there should be a mechanism to load and
unload arbitrarily large integers via the struct
module. Currently, one would likely start with the 'Q'
format character, creating the integer in a block-wise
fashion with multiplies and shifts.
This is OK, though it tends to lend itself to certain
kinds of bugs.
There is currently another method for getting large
integers from strings and going back without the struct
module:
long(stri.encode('hex'), 16)
hex(inte)[2:].decode('hex')
Arguably, such things shouldn't be done for the packing
and unpacking of binary data in general (the string
slicing especially).
I propose a new format character for the struct module,
specifically because the struct module is to "Interpret
strings as packed binary data". Perhaps 'g' and 'G'
(eg. biGint) is sufficient, though any reasonable
character should suffice. Endianness should be
handled, and the number of bytes representing the
object would be the same as with the 's' formatting
code. That is, '>60G' would be an unsigned big-endian
integer represented by 60 bytes (null filled if the
magnitude of the passed integer is not large enough).
The only reason why one wouldn't want this
functionality in the struct module is "This module
performs conversions between Python values and C
structs represented as Python strings." and arbitrarily
large integers are not traditionally part of a C struct
(though I am sure many of us have implemented arbitrary
precision integers with structs). The reason "not a C
type" has been used to quash the 'bit' and 'nibble'
format character, because "masks and shifts" are able
to emulate them, and though "masks and shifts" could
also be used here, I have heard myself and others state
that there should be an easy method for converting
between large longs and strings.
A side-effect for allowing arbitrarily large integers
to be represented in this fashion is that its
functionality could, if desired, subsume the other
integer type characters, as well as fill in the gaps
for nonstandard size integers (3, 5, 6, 7 etc. byte
integers), that I (and I am sure others) have used in
various applications.
Currently no implementation exists, and I don't have
time to do one now. Having taken a look at
longobject.c and structmodule.c, I would likely be able
to make a patch to the documentation, structmodule.c,
and test_struct.py around mid October, if this
functionality is desireable to others and accepted.
While I doubt that a PEP for this is required, if
necessary I would write one up with a sample
implementation around mid October.
--
Comment By: Bob Ippolito (etrepum)
Date: 2004-10-05 18:59
Message:
Logged In: YES
user_id=139309
I would definitely have an immediate use for 3 byte integers.. the Mach-
O executable format has a couple fields that are 3 byte unsigned
integers (bit flags). py2app's supporting library macholib reads and
writes this format directly. Currently I have several places that look
like this:
class dylib_reference(Structure):
_fields_ = (
# XXX - ick, fix
('isym_flags', p_ulong),
#('isym', p_ubyte * 3),
#('flags', p_ubyte),
)
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-10-02 16:00
Message:
Logged In: YES
user_id=80475
If no one other that the OP supports this, I would like to
reject putting this in the struct module. Initially, it
seemed like a fit because the endian options and whatnot are
already in place; however, in one way or another each of the
posters except the OP has stated good reasons for it not
being in the struct module.
Variable length C structure members are not what the module
is about. Having to know the length in advance of the call
is a killer. The learning curve issues with struct are also
a problem. And, the use cases jsut don't point to struct.
Put in a simple function in binascii or let's drop it.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2004-10-02 15:34
Message:
Logged In: YES
user_id=341410
I have just attached a unified diff against structmodule.c
2.62 in CVS.
It implements the semantics I have been describing, compiles
c
[ python-Bugs-1257960 ] gen_send_ex: Assertion `f->f_back != ((void *)0)' failed.
Bugs item #1257960, was opened at 2005-08-12 19:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257960&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 8 Submitted By: Neil Schemenauer (nascheme) Assigned to: Nobody/Anonymous (nobody) Summary: gen_send_ex: Assertion `f->f_back != ((void *)0)' failed. Initial Comment: Triggering is trival. Create a script that contains: def f(): yield 1 g = f() Run with a debug version of Python: python: ../Objects/genobject.c:85: gen_send_ex: Assertion `f->f_back != ((void *)0)' failed. Aborted (core dumped) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257960&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1252149 ] IOError after normal write
Bugs item #1252149, was opened at 2005-08-04 19:30
Message generated for change (Comment added) made by patrick_gerken
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252149&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
>Status: Deleted
>Resolution: Invalid
Priority: 5
Submitted By: Patrick Gerken (patrick_gerken)
Assigned to: Nobody/Anonymous (nobody)
Summary: IOError after normal write
Initial Comment:
After some Bughunting of Code with ConfigParser stuff
which worked under Linux and didn't under Windows, it
all boiled down to these three lines of codes:
fp = open('bla','w+'
fp.readline()
fp.write('bla')
Traceback (most recent call last):
File "", line 1, in ?
fp.write('bla')
IOError: (0, 'Error')
The same test under linux is a success.
These teste have been run on the newest XP with
python 2.4.1.
--
>Comment By: Patrick Gerken (patrick_gerken)
Date: 2005-08-12 20:56
Message:
Logged In: YES
user_id=1324112
I could not believe it and was searching for verification for this
for a long time. If somebody does not believe it like I did:
The C faq from usenet(Which I should have checked first...)
answers this question too, and delivers two references:
References: ANSI Sec. 4.9.5.3
ISO Sec. 7.9.5.3
--
Comment By: Tim Peters (tim_one)
Date: 2005-08-04 19:51
Message:
Logged In: YES
user_id=31435
Well, this is pilot error, inherited from the limitations of C I/O:
the effect of mixing reads with writes on a file open for update
is entirely undefined unless a file-positioning operation occurs
between them (for example, a seek()). I can't guess what
you expect to happen, but seems most likely that what you
intend could be obtained reliably by inserting
fp.seek(fp.tell())
between your readline() and your write().
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252149&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1252149 ] IOError after normal write
Bugs item #1252149, was opened at 2005-08-04 15:30
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252149&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
>Group: Not a Bug
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Patrick Gerken (patrick_gerken)
Assigned to: Nobody/Anonymous (nobody)
Summary: IOError after normal write
Initial Comment:
After some Bughunting of Code with ConfigParser stuff
which worked under Linux and didn't under Windows, it
all boiled down to these three lines of codes:
fp = open('bla','w+'
fp.readline()
fp.write('bla')
Traceback (most recent call last):
File "", line 1, in ?
fp.write('bla')
IOError: (0, 'Error')
The same test under linux is a success.
These teste have been run on the newest XP with
python 2.4.1.
--
>Comment By: Tim Peters (tim_one)
Date: 2005-08-12 17:22
Message:
Logged In: YES
user_id=31435
It's not _necessary_ to design an I/O library this way, and the
Python docs aren't really clear about that Python's I/O
inherits the quirks of the platform C's I/O, so don't at all feel
bad about bringing it up. C libraries often exploit the latitude
allowed by the C standards here to increase efficiency
in "typical cases".
--
Comment By: Patrick Gerken (patrick_gerken)
Date: 2005-08-12 16:56
Message:
Logged In: YES
user_id=1324112
I could not believe it and was searching for verification for this
for a long time. If somebody does not believe it like I did:
The C faq from usenet(Which I should have checked first...)
answers this question too, and delivers two references:
References: ANSI Sec. 4.9.5.3
ISO Sec. 7.9.5.3
--
Comment By: Tim Peters (tim_one)
Date: 2005-08-04 15:51
Message:
Logged In: YES
user_id=31435
Well, this is pilot error, inherited from the limitations of C I/O:
the effect of mixing reads with writes on a file open for update
is entirely undefined unless a file-positioning operation occurs
between them (for example, a seek()). I can't guess what
you expect to happen, but seems most likely that what you
intend could be obtained reliably by inserting
fp.seek(fp.tell())
between your readline() and your write().
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1252149&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1208304 ] urllib2's urlopen() method causes a memory leak
Bugs item #1208304, was opened at 2005-05-25 09:20
Message generated for change (Comment added) made by jafo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208304&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Petr Toman (manekcz)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2's urlopen() method causes a memory leak
Initial Comment:
It seems that the urlopen(url) methd of the urllib2 module
leaves some undestroyable objects in memory.
Please try the following code:
==
if __name__ == '__main__':
import urllib2
a = urllib2.urlopen('http://www.google.com')
del a # or a = None or del(a)
# check memory on memory leaks
import gc
gc.set_debug(gc.DEBUG_SAVEALL)
gc.collect()
for it in gc.garbage:
print it
==
In our code, we're using lots of urlopens in a loop and
the number of unreachable objects grows beyond all
limits :) We also tried a.close() but it didn't help.
You can also try the following:
==
def print_unreachable_len():
# check memory on memory leaks
import gc
gc.set_debug(gc.DEBUG_SAVEALL)
gc.collect()
unreachableL = []
for it in gc.garbage:
unreachableL.append(it)
return len(str(unreachableL))
if __name__ == '__main__':
print "at the beginning", print_unreachable_len()
import urllib2
print "after import of urllib2", print_unreachable_len()
a = urllib2.urlopen('http://www.google.com')
print 'after urllib2.urlopen', print_unreachable_len()
del a
print 'after del', print_unreachable_len()
==
We're using WindowsXP with latest patches, Python 2.4
(ActivePython 2.4 Build 243 (ActiveState Corp.) based on
Python 2.4 (#60, Nov 30 2004, 09:34:21) [MSC v.1310
32 bit (Intel)] on win32).
--
>Comment By: Sean Reifschneider (jafo)
Date: 2005-08-12 22:30
Message:
Logged In: YES
user_id=81797
I've just tried it again using the current CVS version as
well as the version installed with Fedora Core 4, and in
both cases I was able to run over 100,000 retrievals of
http://127.0.0.1/test.html and http://127.0.0.1/google.html.
test.html is just "it works" and google.html was generated
with "wget -O google.html http://google.com/";.
I was able to reproduce this before, but now am not. My
urllib2.py includes the r.recv=r.read line. I have upgraded
from FC3 to FC4, could this be something related to an OS or
library interaction? I was going to try to confirm the last
message, but now I can't reproduce the failure.
--
Comment By: Brian Wellington (bwelling)
Date: 2005-08-12 02:22
Message:
Logged In: YES
user_id=63197
We just ran into this same problem, and worked around it by
simply removing the 'r.recv = r.read' line in urllib2.py,
and creating a recv alias to the read function in
HTTPResponse ('recv = read' in the class).
Not sure if this is the best solution, but it seems to work.
--
Comment By: Sean Reifschneider (jafo)
Date: 2005-06-29 03:52
Message:
Logged In: YES
user_id=81797
I give up, this code is kind of a maze of twisty little
passages. I did try doing "a.fp.close()" and that didn't
seem to help at all. Couldn't really make any progress on
that though. I also tried doing a "if a.headers.fp:
a.headers.fp.close()", which didn't do anything noticable.
--
Comment By: Sean Reifschneider (jafo)
Date: 2005-06-29 03:27
Message:
Logged In: YES
user_id=81797
I can reproduce this in both the python.org 2.4 RPM and in a
freshly built copy from CVS. If I run a few thousand
urlopen()s, I get:
Traceback (most recent call last):
File "/tmp/mt", line 26, in ?
File "/tmp/python/dist/src/Lib/urllib2.py", line 130, in
urlopen
File "/tmp/python/dist/src/Lib/urllib2.py", line 361, in open
File "/tmp/python/dist/src/Lib/urllib2.py", line 379, in _open
File "/tmp/python/dist/src/Lib/urllib2.py", line 340, in
_call_chain
File "/tmp/python/dist/src/Lib/urllib2.py", line 1026, in
http_open
File "/tmp/python/dist/src/Lib/urllib2.py", line 1001, in
do_open
urllib2.URLError:
Even if I do a a.close(). I'll investigate a bit further.
Sean
--
Comment By: A.M. Kuchling (akuchling)
Date: 2005-06-01 23:13
Message:
Logged In: YES
user_id=11375
Confirmed. The objects involved seem to be an HTTPResponse and the
socket._fileobject wrapper; the assignment 'r.recv=r.read' around line 1013
of urllib2.py seems to be critical to
[ python-Bugs-1257731 ] Make set.remove() behave more like Set.remove()
Bugs item #1257731, was opened at 2005-08-12 10:31 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257731&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Make set.remove() behave more like Set.remove() Initial Comment: class H(set): def __hash__(self):return id(self) s=H() f=set() f.add(s) f.remove(s) # this fails -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-12 18:58 Message: Logged In: YES user_id=80475 Fixed. Lib/test/test_set.py 1.21 and 1.16.2.2 Objects/setobject.c 1.47 and 1.31.2.2, -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257731&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1257960 ] gen_send_ex: Assertion `f->f_back != ((void *)0)' failed.
Bugs item #1257960, was opened at 2005-08-12 14:20 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257960&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core >Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Phillip J. Eby (pje) Summary: gen_send_ex: Assertion `f->f_back != ((void *)0)' failed. Initial Comment: Triggering is trival. Create a script that contains: def f(): yield 1 g = f() Run with a debug version of Python: python: ../Objects/genobject.c:85: gen_send_ex: Assertion `f->f_back != ((void *)0)' failed. Aborted (core dumped) -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-12 19:09 Message: Logged In: YES user_id=80475 I believe this is related to IDLE crash that I've been seeing. The problem did not occur just before the checkin: cvs up -D "2005-08-01 18:00" But emerged immediately after: cvs up -D "2005-08-01 21:00" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257960&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1257960 ] gen_send_ex: Assertion `f->f_back != ((void *)0)' failed.
Bugs item #1257960, was opened at 2005-08-12 19:20 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257960&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Neil Schemenauer (nascheme) Assigned to: Phillip J. Eby (pje) Summary: gen_send_ex: Assertion `f->f_back != ((void *)0)' failed. Initial Comment: Triggering is trival. Create a script that contains: def f(): yield 1 g = f() Run with a debug version of Python: python: ../Objects/genobject.c:85: gen_send_ex: Assertion `f->f_back != ((void *)0)' failed. Aborted (core dumped) -- >Comment By: Phillip J. Eby (pje) Date: 2005-08-13 03:29 Message: Logged In: YES user_id=56214 Sadly, this is not the cause of the IDLE problem, because it's the assert that's wrong here. The problem that's occurring is that f->f_back is NULL because the final garbage collection at shutdown is occurring with a NULL tstate->frame. Changing the assert to check that f->f_back==tstate->frame makes the (meaningless) error go away. Basically, the problem here is because this code used to be the iternext routine, and it was never called by the GC. Now, generators are closed when they are garbage collected, so they can be executed during interpreter shutdown. I've checked in a corrected assertion. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-13 00:09 Message: Logged In: YES user_id=80475 I believe this is related to IDLE crash that I've been seeing. The problem did not occur just before the checkin: cvs up -D "2005-08-01 18:00" But emerged immediately after: cvs up -D "2005-08-01 21:00" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257960&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
