[ python-Bugs-1478253 ] test_ctypes: undefined symbol: XGetExtensionVersion
Bugs item #1478253, was opened at 2006-04-28 08:59 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=1478253&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.5 Status: Open Resolution: None Priority: 5 Submitted By: balducci (balducci) Assigned to: Nobody/Anonymous (nobody) Summary: test_ctypes: undefined symbol: XGetExtensionVersion Initial Comment: Dear python maintainers, apologies if I'm wrong or I'm missing some evident point. Just built 2.5a2 on linux: myhost> uname -a Linux myhost 2.6.16.5 #1 Thu Apr 13 10:01:54 CEST 2006 i686 unknown I find that `make test' chokes in test_ctypes. Running the single test with `./python -E -tt ./Lib/test/regrtest.py -l -v -s test_ctypes' gives me the output shown in the attached file. As far as I could google around, I seem to understand that this problem has already appeared in the past. Basically, it is due to the fact that libglut (version 3.7) does not contain the XGetExtensionVersion function, which is instead defined in libXi: myhost> nm /usr/local/X11R6/lib/libglut.so.3|egrep -i xgetextensionversion U XGetExtensionVersion myhost> nm /usr/local/X11R6/lib/libXi.so|egrep -i xgetextensionversion 3930 T XGetExtensionVersion I seem to understand that libglut should be dlopen'ed together with libXi, in order to have XGetExtensionVersion available. Unfortunately, I don't speak python, so I'm not in the position to suggest any reasonable fix for this. I send this message in the hope of making something useful: if this is not the case, please, accept my apologies. I thank you very much for your time and effort in maintaining python. Ciao Gabriele -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes
Bugs item #1462152, was opened at 2006-03-31 15:02
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&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: 5
Submitted By: Matt Fleming (splitscreen)
>Assigned to: Tim Peters (tim_one)
Summary: Python does not check for POSIX compliant open() modes
Initial Comment:
Python does not check for POSIX-compliant modes when
passing them to open() and fopen().
According to the POSIX standard all modes should start
with either an 'a', 'r' or 'w'.
This patch implements this check in the
check_the_mode() function of fileobject.c and a test
has been modified in the test_file.py test.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 09:55
Message:
Logged In: YES
user_id=849994
Tim: Did you review file-modes.diff which is really the
latest patch? (There's no test in it either, but I'll add
one when I check it in)
--
Comment By: Tim Peters (tim_one)
Date: 2006-04-24 01:19
Message:
Logged In: YES
user_id=31435
This is still ;-) fine with me. There doesn't seem to be a
test in fileobject2.diff. WRT the docs, "must either be"
should say "must be one of" instead ("either" is proper for
two choices, but there are three). It should state that
this requirement is new in Python 2.5; in LaTeX, something like
\versionchanged[Restriction on first letter of mode string
introduced]{2.5}
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-12 10:14
Message:
Logged In: YES
user_id=1126061
Yeah, your patch looks much better.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-06 08:15
Message:
Logged In: YES
user_id=849994
splitscreen: your patch was incomplete and could have
overwritten memory.
tim_one: Attaching new patch implementing what I proposed in
my comment below.
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 21:59
Message:
Logged In: YES
user_id=1126061
Ok, uploading latest patch, not quite sure I've hit the mark
here.
Please review.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 20:43
Message:
Logged In: YES
user_id=849994
Yes, I want to remove 'U' from the mode since it's at this
point already recognized by Python, and it's not meaningful
to the underlying C library.
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 19:32
Message:
Logged In: YES
user_id=1126061
Ignore my question, it's for "universal newlines", right?
Have I understood your proposal correctly in that you want
to remove the 'U' from the mode?
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 14:14
Message:
Logged In: YES
user_id=1126061
That seems sensible. What does a mode containing 'U' mean
anyway?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 07:08
Message:
Logged In: YES
user_id=849994
Instead of this patch, I'd rather like check_the_mode to
* remove any 'U' from the mode string
* if 'U' was found:
* error out if the new string begins with 'w' or 'a'
* add a 'r' and 'b' if it isn't already given
* if not:
* error out if the string doesn't begin with 'w', 'r', 'a'
What do you think of it?
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 18:03
Message:
Logged In: YES
user_id=31435
There's a small danger of backward-incompatibility here,
since platforms are free to support any goofy mode
characters they like, and Python just passes on whatever the
user typed. I understand that some MS compilers in debug
mode raise internal exceptions, but that's an MS bug and the
workaround is dead easy ("don't do that").
All that said, I'm in favor of this patch ;-). However, if
it goes in two things are needed:
1. The error message should be more informative, like
PyErr_Format(PyExc_ValueError, "mode argument must "
"begin with 'w', 'r', or 'a', not '%.200s'", mode);
2. The Python docs should change to match (i.e., the
manual should document this new restriction on mode
strings).
WRT the test case, it's more natural to write, e.g.,
TESTFN in s
than
s.find(TESTFN) != -1
-
[ python-Bugs-1478326 ] Invalid value returned by util.get_platform() on HP
Bugs item #1478326, was opened at 2006-04-28 13: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=1478326&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Sébastien Sablé (sable)
Assigned to: Nobody/Anonymous (nobody)
Summary: Invalid value returned by util.get_platform() on HP
Initial Comment:
Hi,
I am working on a HP platform which is reported like
this by os.uname:
>>> print os.uname()
>>> ('HP-UX', 'newton', 'B.11.23', 'U', '9000/800')
as a result, distuils.util.get_platform() reports the
following value:
hp-ux-B.11.23-9000/800
Since this value is used by distutils "mainly to
distinguish platform-specific build directories", this
value is invalid as it contains a '/'; as a result the
directory structure in the build directory is messed up
and the installation fails.
The following patch corrected the problem:
--- util.py.old 2006-04-28 11:13:19.0 +0200
+++ util.py 2006-04-28 13:17:31.0 +0200
@@ -44,6 +44,7 @@
# (to accommodate BSD/OS), and translate spaces
(for "Power Macintosh")
osname = string.lower(osname)
osname = string.replace(osname, '/', '')
+machine = string.replace(machine, '/', '-')
machine = string.replace(machine, ' ', '_')
if osname[:5] == "linux":
regards
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478326&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-1465406 ] Allowing the definition of constants
Feature Requests item #1465406, was opened at 2006-04-05 23:30 Message generated for change (Comment added) made by ciw42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1465406&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: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Wilson (ciw42) Assigned to: Nobody/Anonymous (nobody) Summary: Allowing the definition of constants Initial Comment: One of the current optimizations due in v2.5 includes constant folding of expressions, which as it stands serves as a way of somply getting rid of a redundant arithmetic operations and the like. In practice, it's rare a developer would leave an expression such as "2+3" sat in his/her code, but by allowing the declaration of constants within a script, it could make this new feature *much* more useful. As an example, in a recent script I had the following at the top, outside the main loop: SCREEN_WIDTH=640 SCREEN_HEIGHT=480 SCREEN_RATIO=SCREEN_WIDTH/SCREEN_HEIGHT As SCREEN_RATIO is used a number of times during my main loop, it makes sense to pre-calculate it to avoid the extra processing, but if the compiler were aware that SCREEN_WIDTH and SCREEN_HEIGHT were constants, it could optimise out the calculation and I could include the calculation in-place. I frequently make use of "constants" to make my code more readable, and wonder whether there is any performance penalty or lack of optimisation going on due to them in fact being regular variables? -- >Comment By: Chris Wilson (ciw42) Date: 2006-04-28 13:38 Message: Logged In: YES user_id=1018283 I see your point, and it's a good example of why using namespaces is so important, but in practice, with my proposal in place, the code you propose simply wouldn't compile. Assuming the compiler simply substituted the literal "3.1415" for "pi" as I've proposed, you'd end up with "3.1415 = 4", and a syntax error for trying to assign to a literal value. You'd not get as far as running the code, so in practice there'd be no issues with it running incorrectly. Being able to declare constants is important as it allows the compiler to make the sort of optimistations I mentioned previously. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 13:55 Message: Logged In: YES user_id=21627 The problem is that declaring the value assignment const doesn't help. Consider this: from math import pi def area(r): return r*r*pi pi = 4 print area(10) So even though math.pi might be declared as a constant, hard-coding its value into the function area would break this program - the value of the variable pi might change not change inside math, but it might change where it is imported. -- Comment By: Chris Wilson (ciw42) Date: 2006-04-06 21:59 Message: Logged In: YES user_id=1018283 I've re-opened this, as I don't feel it would be difficult to implement or require any fundamental changes to the parser or runtime. In fact, it would be very easy, and potentially very useful beyond the scope of my initial suggestion. Appologies to rhettinger if this seems rude, but I would ask that you give the following some consideration. The addition of a "const" or similar compiler directive would allow the compiler to simply do an on-the-fly substitution for the specified value/string etc. There would be no code analysis required, and adding this type of functionality would carry no real overheads or further complicate the compilation process. There would be no changes required within the runtime. Once substituted, the already incorporated compiler constant folding features would then come into play. I suppose, that what I'm suggesting is effectively a basic pre-compiler macro feature. This in itself may prove useful in many other situations. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-04-05 23:57 Message: Logged In: YES user_id=80475 Python is too dynamic for this kind of optimization to be done automatically. If those "constants" are defined at the module level, they can be changed by code outside the module. Even within the module, it would take a thorough analysis of the code to determine that nothing was trying to alter the value of the global variable. If the "constant" is defined inside a function, it is still a local variable subject to change by later lines in function. Your best bet is to use the bind_consts recipe at ASPN. It will automatically turn some global references into locals: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277 940 I
[ python-Bugs-1478400 ] test_capi crashed -- thread.error: can't allocate lock
Bugs item #1478400, was opened at 2006-04-28 20:45 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=1478400&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: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: test_capi crashed -- thread.error: can't allocate lock Initial Comment: I have build Python 2.4.3 on HP-UX IPF platform and run the gmake test, and seeing the following error: test_capi crashed -- thread.error: can't allocate lock When I see the release notes of the Python 2.4.3, there is a mention of this fix in some platforms. Is this fixed in HP-UX IPF? Please let me know how to reslove this on HP-UX IPF platform. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478400&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478429 ] datetime.datetime.fromtimestamp ValueError. Rounding error
Bugs item #1478429, was opened at 2006-04-28 14:37 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=1478429&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Erwin Bonsma (eriban) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.datetime.fromtimestamp ValueError. Rounding error Initial Comment: The function datetime.datetime.fromtimestamp() can throw a ValueError when the timestamp is close to an integer value but not quite due to rounding errors. It then gives the following error: microsecond must be in 0..99 This can be seen by running the attached code (the values are taken from an actual event log), which gives the following output: 1146227423.0 -> 2006-04-28 14:30:23 1146227448.7 -> 2006-04-28 14:30:48.702000 1146227459.95 -> 2006-04-28 14:30:59.947000 1146227468.41 -> 2006-04-28 14:31:08.409000 1146227501.4 -> 2006-04-28 14:31:41.399000 1146227523.0 -> Error converting 1146227522.9976 microsecond must be in 0..99 Admittedly, I can work around the bug in this case, by summing the durations first, and calculating all times from "starttime" directly. Nevertheless, I think this is a bug in datetime, as it should work as long as the input time any floating point value within a given range (based on the date range that is supported). Details of my Python environment: Python 2.4.2 (#1, Feb 6 2006, 13:53:18) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-53)] on linux2 Cheers, Erwin -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478253 ] test_ctypes: undefined symbol: XGetExtensionVersion
Bugs item #1478253, was opened at 2006-04-28 10:59 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&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.5 Status: Open Resolution: None Priority: 5 Submitted By: balducci (balducci) Assigned to: Nobody/Anonymous (nobody) Summary: test_ctypes: undefined symbol: XGetExtensionVersion Initial Comment: Dear python maintainers, apologies if I'm wrong or I'm missing some evident point. Just built 2.5a2 on linux: myhost> uname -a Linux myhost 2.6.16.5 #1 Thu Apr 13 10:01:54 CEST 2006 i686 unknown I find that `make test' chokes in test_ctypes. Running the single test with `./python -E -tt ./Lib/test/regrtest.py -l -v -s test_ctypes' gives me the output shown in the attached file. As far as I could google around, I seem to understand that this problem has already appeared in the past. Basically, it is due to the fact that libglut (version 3.7) does not contain the XGetExtensionVersion function, which is instead defined in libXi: myhost> nm /usr/local/X11R6/lib/libglut.so.3|egrep -i xgetextensionversion U XGetExtensionVersion myhost> nm /usr/local/X11R6/lib/libXi.so|egrep -i xgetextensionversion 3930 T XGetExtensionVersion I seem to understand that libglut should be dlopen'ed together with libXi, in order to have XGetExtensionVersion available. Unfortunately, I don't speak python, so I'm not in the position to suggest any reasonable fix for this. I send this message in the hope of making something useful: if this is not the case, please, accept my apologies. I thank you very much for your time and effort in maintaining python. Ciao Gabriele -- >Comment By: Thomas Heller (theller) Date: 2006-04-28 17:02 Message: Logged In: YES user_id=11105 I don't know enough about linux shared libraries, either, to sugegst a fix or workaround. OTOH, I'm also not able to reproduce that problem on any of the linux machines that I have access to. What kind of system is this? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&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-1476166 ] Add SeaMonkey to webbrowser.py
Feature Requests item #1476166, was opened at 2006-04-25 14:32
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1476166&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: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Oleg Broytmann (phd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add SeaMonkey to webbrowser.py
Initial Comment:
Add SeaMonkey to webbrowser.py as yet another Mozilla
family browser. Just prepend "seamonkey" to the list
("mozilla-firefox", "firefox",
"mozilla-firebird",
"firebird",
"mozilla", "netscape") in the
register_X_browsers().
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 16:31
Message:
Logged In: YES
user_id=849994
Added in rev. 45780.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1476166&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1475009 ] Document os.path.join oddity on Windows
Bugs item #1475009, was opened at 2006-04-23 13:08
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475009&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: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Document os.path.join oddity on Windows
Initial Comment:
Please document that on windows
os.path.join("m:\\noo", "\\woo") => '\\woo'
>From reading the code I see that this is intetional,
however it need to be documented.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 16:37
Message:
Logged In: YES
user_id=849994
The documentation was already there. I added a parenthetical
note that on Windows, the drive letter is also thrown away.
(rev. 45781, 45782)
--
Comment By: Tim Peters (tim_one)
Date: 2006-04-23 17:38
Message:
Logged In: YES
user_id=31435
Noting that there's nothing special about Windows here:
>>> import posixpath
>>> posixpath.join('/noo', '/woo')
'/woo'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475009&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478400 ] test_capi crashed -- thread.error: can't allocate lock
Bugs item #1478400, was opened at 2006-04-28 13:45 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478400&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: Duplicate Priority: 5 Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: test_capi crashed -- thread.error: can't allocate lock Initial Comment: I have build Python 2.4.3 on HP-UX IPF platform and run the gmake test, and seeing the following error: test_capi crashed -- thread.error: can't allocate lock When I see the release notes of the Python 2.4.3, there is a mention of this fix in some platforms. Is this fixed in HP-UX IPF? Please let me know how to reslove this on HP-UX IPF platform. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 16:39 Message: Logged In: YES user_id=849994 Duplicate of #1473979. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478400&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478529 ] size limit exceeded for read() from network drive
Bugs item #1478529, was opened at 2006-04-28 17:46 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=1478529&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: Open Resolution: None Priority: 5 Submitted By: Mark Sheppard (markshep) Assigned to: Nobody/Anonymous (nobody) Summary: size limit exceeded for read() from network drive Initial Comment: If you've got a network share mounted as a local drive then Windows has a limit of 67,076,095 (0x03ff7fff) bytes for a read from an open file on that drive. Running the python read() method on an open file larger than this size throws an "IOError: [Errno 22] Invalid argument" exception. A fix would be for python to internally use multiple reads so as to not exceed this limit. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472949 ] shutil.copytree debug message problem
Bugs item #1472949, was opened at 2006-04-19 12:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472949&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: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christophe DUMEZ (hydr0g3n) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copytree debug message problem Initial Comment: I noticed a problem in shutil.copytree : try: if symlinks and os.path.islink(srcname): linkto = os.readlink(srcname) os.symlink(linkto, dstname) elif os.path.isdir(srcname): copytree(srcname, dstname, symlinks) else: copy2(srcname, dstname) # XXX What about devices, sockets etc.? except (IOError, os.error), why: errors.append((srcname, dstname, why)) 'why' isn't displayed in tuple, maybe this line would be better for debug : "errors.append((srcname, dstname, why.strerror))" then, it will display something (for example: 'permission denied'). -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 16:55 Message: Logged In: YES user_id=849994 >From rev. 45785, the line reads errors.append((srcname, dstname, str(why))) This way, you get the full information out of the IOError/OSError. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472949&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478326 ] Invalid value returned by util.get_platform() on HP
Bugs item #1478326, was opened at 2006-04-28 11:22
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478326&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: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Sébastien Sablé (sable)
Assigned to: Nobody/Anonymous (nobody)
Summary: Invalid value returned by util.get_platform() on HP
Initial Comment:
Hi,
I am working on a HP platform which is reported like
this by os.uname:
>>> print os.uname()
>>> ('HP-UX', 'newton', 'B.11.23', 'U', '9000/800')
as a result, distuils.util.get_platform() reports the
following value:
hp-ux-B.11.23-9000/800
Since this value is used by distutils "mainly to
distinguish platform-specific build directories", this
value is invalid as it contains a '/'; as a result the
directory structure in the build directory is messed up
and the installation fails.
The following patch corrected the problem:
--- util.py.old 2006-04-28 11:13:19.0 +0200
+++ util.py 2006-04-28 13:17:31.0 +0200
@@ -44,6 +44,7 @@
# (to accommodate BSD/OS), and translate spaces
(for "Power Macintosh")
osname = string.lower(osname)
osname = string.replace(osname, '/', '')
+machine = string.replace(machine, '/', '-')
machine = string.replace(machine, ' ', '_')
if osname[:5] == "linux":
regards
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 16:59
Message:
Logged In: YES
user_id=849994
Fixed in rev. 45786, 45787.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478326&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478253 ] test_ctypes: undefined symbol: XGetExtensionVersion
Bugs item #1478253, was opened at 2006-04-28 08:59 Message generated for change (Comment added) made by balducci You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&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.5 Status: Open Resolution: None Priority: 5 Submitted By: balducci (balducci) Assigned to: Nobody/Anonymous (nobody) Summary: test_ctypes: undefined symbol: XGetExtensionVersion Initial Comment: Dear python maintainers, apologies if I'm wrong or I'm missing some evident point. Just built 2.5a2 on linux: myhost> uname -a Linux myhost 2.6.16.5 #1 Thu Apr 13 10:01:54 CEST 2006 i686 unknown I find that `make test' chokes in test_ctypes. Running the single test with `./python -E -tt ./Lib/test/regrtest.py -l -v -s test_ctypes' gives me the output shown in the attached file. As far as I could google around, I seem to understand that this problem has already appeared in the past. Basically, it is due to the fact that libglut (version 3.7) does not contain the XGetExtensionVersion function, which is instead defined in libXi: myhost> nm /usr/local/X11R6/lib/libglut.so.3|egrep -i xgetextensionversion U XGetExtensionVersion myhost> nm /usr/local/X11R6/lib/libXi.so|egrep -i xgetextensionversion 3930 T XGetExtensionVersion I seem to understand that libglut should be dlopen'ed together with libXi, in order to have XGetExtensionVersion available. Unfortunately, I don't speak python, so I'm not in the position to suggest any reasonable fix for this. I send this message in the hope of making something useful: if this is not the case, please, accept my apologies. I thank you very much for your time and effort in maintaining python. Ciao Gabriele -- >Comment By: balducci (balducci) Date: 2006-04-28 17:05 Message: Logged In: YES user_id=1452725 Dear Thomas, thank you for your reply. I've investigated a little bit more the problem. 2.5a1 worked smoothly on test_ctypes: this makes me think that the problem isn't in my box (it's an old redhat-7.1, but I keep all the system up-2-date: kernel,X11,glibc etc.). Also, I've kept python up-2-date since 2.3.4 and never seen this. On the other hand, it is also true that the (verbose mode) output of test_ctypes in 2.5a1, while showing a test_GL line, does not contain any test_glu and/or test_glut lines (which, together with test_gl, give the errors in 2.5a2): so it might also be that these new tests (test_glu and test_glut) make some local (i.e. due to my box) problem evident. However, I'm incline to think that there must be something in 2.5a2 which has changed from 2.5a1: => Lib/ctypes/__init__.py heavily differ from 2.5a1 to 2.5a2 (the error reported in the attached file I sent seems to have been generated in __init__.py) => also, the traceback in the attachment quotes a file Lib/ctypes/test/test_find.py, which I don't find in 2.5a1 => the error is quite reasonable: libglut.so.3 does not define XGetExtensionVersion, which is instead defined in libXi.so I seem to understand that exactly this kind of problem was reported in the following thread: http://aspn.activestate.com/ASPN/Mail/Message/ctypes-users/2872534 I've seen just now that you got involved there! Well, as I said, I do not speak python, but from a glance to the thread I seem to understand that the problem could be in the use of RTLD_GLOBAL/RTLD_LOCAL (I don't know what these are for, but I guess that RTLD stands for RunTime Loader?) As I understand it, the problem seems to be as if one tries to compile a C program which calls XGetExtensionVersion with -lglut, but without -lXi. Perhaps the corresponding action should be done with test_ctypes, but I have no idea how this is done with python. I've also to admit that being the only one who has reported this problem on such a widespread platfrom like linux makes me perplexed. In the end, I don't know what to think: the problem is actually there and was not there with 2.5a1 (nor with any previous build since 2.3.4). I regret being unable to go deeper in this problem and I apoligize if this report is not clear enough. If there is any test I can do to make things clearer, please, just tell me. And THANK YOU for your work. Ciao Gabriele -- Comment By: Thomas Heller (theller) Date: 2006-04-28 15:02 Message: Logged In: YES user_id=11105 I don't know enough about linux shared libraries, either, to sugegst a fix or workaround. OTOH, I'm also not able to reproduce that problem on any of the linux machines that I have access to. What kind of system is this? -- You can respond by visiti
[ python-Bugs-1436226 ] fix inplace assignment for immutable sequences
Bugs item #1436226, was opened at 2006-02-21 23:11 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436226&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: None Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Georg Brandl (gbrandl) >Assigned to: Nobody/Anonymous (nobody) Summary: fix inplace assignment for immutable sequences Initial Comment: Currently: py> tup = ([], ) py> tup[0] += [1] Traceback (most recent call last): File "", line 1, in ? TypeError: object doesn't support item assignment py> tup ([1],) With this patch, no exception will be raised when the item one wants to assign is already there in the tuple. -- Comment By: Georg Brandl (gbrandl) Date: 2006-02-22 22:20 Message: Logged In: YES user_id=849994 You're right with the error handling *shame*. I had written the patch a few months ago and just posted it without looking at it again. Well, I don't think I'm able to come up with a new patch only for a couple of days. -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-22 02:44 Message: Logged In: YES user_id=6380 I see no error handling from the PySequence_GetItem() call; if this causes an error it should take precedence over the TypeError we're about to raise (IOW we shouldn't raise the TypeError). Also, shouldn't the same fix be made for attribute assignment? Finally -- doing this in PySequence_SetItem is too broad. Code like this passes without error: t = (1, 2) t[0] = t[0] That can't be right! You need to find a code path that's only taken for += and friends. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436226&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478429 ] datetime.datetime.fromtimestamp ValueError. Rounding error
Bugs item #1478429, was opened at 2006-04-28 14:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Erwin Bonsma (eriban) >Assigned to: Martin v. Löwis (loewis) Summary: datetime.datetime.fromtimestamp ValueError. Rounding error Initial Comment: The function datetime.datetime.fromtimestamp() can throw a ValueError when the timestamp is close to an integer value but not quite due to rounding errors. It then gives the following error: microsecond must be in 0..99 This can be seen by running the attached code (the values are taken from an actual event log), which gives the following output: 1146227423.0 -> 2006-04-28 14:30:23 1146227448.7 -> 2006-04-28 14:30:48.702000 1146227459.95 -> 2006-04-28 14:30:59.947000 1146227468.41 -> 2006-04-28 14:31:08.409000 1146227501.4 -> 2006-04-28 14:31:41.399000 1146227523.0 -> Error converting 1146227522.9976 microsecond must be in 0..99 Admittedly, I can work around the bug in this case, by summing the durations first, and calculating all times from "starttime" directly. Nevertheless, I think this is a bug in datetime, as it should work as long as the input time any floating point value within a given range (based on the date range that is supported). Details of my Python environment: Python 2.4.2 (#1, Feb 6 2006, 13:53:18) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-53)] on linux2 Cheers, Erwin -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 17:32 Message: Logged In: YES user_id=849994 Attaching a patch correcting this issue. Please review. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478429 ] datetime.datetime.fromtimestamp ValueError. Rounding error
Bugs item #1478429, was opened at 2006-04-28 14:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Erwin Bonsma (eriban) Assigned to: Martin v. Löwis (loewis) Summary: datetime.datetime.fromtimestamp ValueError. Rounding error Initial Comment: The function datetime.datetime.fromtimestamp() can throw a ValueError when the timestamp is close to an integer value but not quite due to rounding errors. It then gives the following error: microsecond must be in 0..99 This can be seen by running the attached code (the values are taken from an actual event log), which gives the following output: 1146227423.0 -> 2006-04-28 14:30:23 1146227448.7 -> 2006-04-28 14:30:48.702000 1146227459.95 -> 2006-04-28 14:30:59.947000 1146227468.41 -> 2006-04-28 14:31:08.409000 1146227501.4 -> 2006-04-28 14:31:41.399000 1146227523.0 -> Error converting 1146227522.9976 microsecond must be in 0..99 Admittedly, I can work around the bug in this case, by summing the durations first, and calculating all times from "starttime" directly. Nevertheless, I think this is a bug in datetime, as it should work as long as the input time any floating point value within a given range (based on the date range that is supported). Details of my Python environment: Python 2.4.2 (#1, Feb 6 2006, 13:53:18) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-53)] on linux2 Cheers, Erwin -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 17:32 Message: Logged In: YES user_id=849994 Really attaching a patch now. ;) -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 17:32 Message: Logged In: YES user_id=849994 Attaching a patch correcting this issue. Please review. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478429 ] datetime.datetime.fromtimestamp ValueError. Rounding error
Bugs item #1478429, was opened at 2006-04-28 10:37 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&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: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Erwin Bonsma (eriban) >Assigned to: Georg Brandl (gbrandl) Summary: datetime.datetime.fromtimestamp ValueError. Rounding error Initial Comment: The function datetime.datetime.fromtimestamp() can throw a ValueError when the timestamp is close to an integer value but not quite due to rounding errors. It then gives the following error: microsecond must be in 0..99 This can be seen by running the attached code (the values are taken from an actual event log), which gives the following output: 1146227423.0 -> 2006-04-28 14:30:23 1146227448.7 -> 2006-04-28 14:30:48.702000 1146227459.95 -> 2006-04-28 14:30:59.947000 1146227468.41 -> 2006-04-28 14:31:08.409000 1146227501.4 -> 2006-04-28 14:31:41.399000 1146227523.0 -> Error converting 1146227522.9976 microsecond must be in 0..99 Admittedly, I can work around the bug in this case, by summing the durations first, and calculating all times from "starttime" directly. Nevertheless, I think this is a bug in datetime, as it should work as long as the input time any floating point value within a given range (based on the date range that is supported). Details of my Python environment: Python 2.4.2 (#1, Feb 6 2006, 13:53:18) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-53)] on linux2 Cheers, Erwin -- >Comment By: Tim Peters (tim_one) Date: 2006-04-28 14:11 Message: Logged In: YES user_id=31435 Huh! My comment got lost. The patch looks good, but add 1 to `timet` instead of 1.0. We don't know whether the C time_t type is an integral or floating type, and using an integer literal works smoothly for both. For that matter, we don't know that time_t counts number of seconds either (e.g., perhaps it counts number of nanoseconds), but other code in Python assumes that it does, so there's no special sin in assuming it does here too. -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 13:32 Message: Logged In: YES user_id=849994 Really attaching a patch now. ;) -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 13:32 Message: Logged In: YES user_id=849994 Attaching a patch correcting this issue. Please review. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478253 ] test_ctypes: undefined symbol: XGetExtensionVersion
Bugs item #1478253, was opened at 2006-04-28 10:59 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&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.5 Status: Open Resolution: None Priority: 5 Submitted By: balducci (balducci) >Assigned to: Thomas Heller (theller) Summary: test_ctypes: undefined symbol: XGetExtensionVersion Initial Comment: Dear python maintainers, apologies if I'm wrong or I'm missing some evident point. Just built 2.5a2 on linux: myhost> uname -a Linux myhost 2.6.16.5 #1 Thu Apr 13 10:01:54 CEST 2006 i686 unknown I find that `make test' chokes in test_ctypes. Running the single test with `./python -E -tt ./Lib/test/regrtest.py -l -v -s test_ctypes' gives me the output shown in the attached file. As far as I could google around, I seem to understand that this problem has already appeared in the past. Basically, it is due to the fact that libglut (version 3.7) does not contain the XGetExtensionVersion function, which is instead defined in libXi: myhost> nm /usr/local/X11R6/lib/libglut.so.3|egrep -i xgetextensionversion U XGetExtensionVersion myhost> nm /usr/local/X11R6/lib/libXi.so|egrep -i xgetextensionversion 3930 T XGetExtensionVersion I seem to understand that libglut should be dlopen'ed together with libXi, in order to have XGetExtensionVersion available. Unfortunately, I don't speak python, so I'm not in the position to suggest any reasonable fix for this. I send this message in the hope of making something useful: if this is not the case, please, accept my apologies. I thank you very much for your time and effort in maintaining python. Ciao Gabriele -- >Comment By: Thomas Heller (theller) Date: 2006-04-28 21:06 Message: Logged In: YES user_id=11105 Gabriele, from the thread you mention I would assume that this patch may fix the problem for you - it should be applied to Lib/ctypes/test/test_find.py: Index: test_find.py === --- test_find.py(Revision 45791) +++ test_find.py(Arbeitskopie) @@ -39,9 +39,9 @@ if lib_glu: self.glu = CDLL(lib_glu, RTLD_GLOBAL) if lib_glut: -self.glut = CDLL(lib_glut) +self.glut = CDLL(lib_glut, RTLD_GLOBAL) if lib_gle: -self.gle = CDLL(lib_gle) +self.gle = CDLL(lib_gle, RTLD_GLOBAL) if lib_gl: def test_gl(self): About the differences between ctypes in 2.5a1 and 2.5a2: Python 2.5a2's ctypes contained changes that I had better not made. This has been reverted in 2.5a2 version, which explains the large differences. FWIW, it seems all the Python buildbots and other systems that test the 2.5a2 code doen't have the problem that you report. Which does not mean that your system is broken, just that it is different (but similar to that one mentioned in the thread on ctypes-users from last October)! Please try the patch and report back. -- Comment By: balducci (balducci) Date: 2006-04-28 19:05 Message: Logged In: YES user_id=1452725 Dear Thomas, thank you for your reply. I've investigated a little bit more the problem. 2.5a1 worked smoothly on test_ctypes: this makes me think that the problem isn't in my box (it's an old redhat-7.1, but I keep all the system up-2-date: kernel,X11,glibc etc.). Also, I've kept python up-2-date since 2.3.4 and never seen this. On the other hand, it is also true that the (verbose mode) output of test_ctypes in 2.5a1, while showing a test_GL line, does not contain any test_glu and/or test_glut lines (which, together with test_gl, give the errors in 2.5a2): so it might also be that these new tests (test_glu and test_glut) make some local (i.e. due to my box) problem evident. However, I'm incline to think that there must be something in 2.5a2 which has changed from 2.5a1: => Lib/ctypes/__init__.py heavily differ from 2.5a1 to 2.5a2 (the error reported in the attached file I sent seems to have been generated in __init__.py) => also, the traceback in the attachment quotes a file Lib/ctypes/test/test_find.py, which I don't find in 2.5a1 => the error is quite reasonable: libglut.so.3 does not define XGetExtensionVersion, which is instead defined in libXi.so I seem to understand that exactly this kind of problem was reported in the following thread: http://aspn.activestate.com/ASPN/Mail/Message/ctypes-users/2872534 I've seen just now that you got involved there! Well, as I said, I do not speak python, but from a glance to the thread I seem to understand that the problem could b
[ python-Bugs-1473560 ] urllib2.Request constructor to urllib.quote the url given
Bugs item #1473560, was opened at 2006-04-20 14:02
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&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: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nikos Kouremenos (nkour)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2.Request constructor to urllib.quote the url given
Initial Comment:
urllib2.Request('http://www.google.com/search?client=firefox&q=foo
bar', None)
this fails. it shouldn't
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 19:19
Message:
Logged In: YES
user_id=849994
I don't know what your problem is. This works perfectly for me:
>>> r =
urllib2.Request("http://www.google.com/search?client=firefox&q=foobar";,
None)
>>> o = urllib2.HTTPHandler()
>>> u = o.http_open(r)
>>> u.read()
"..."
Closing as "Works for me". If you have another problem,
please reopen
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478429 ] datetime.datetime.fromtimestamp ValueError. Rounding error
Bugs item #1478429, was opened at 2006-04-28 14:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&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: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Erwin Bonsma (eriban) Assigned to: Georg Brandl (gbrandl) Summary: datetime.datetime.fromtimestamp ValueError. Rounding error Initial Comment: The function datetime.datetime.fromtimestamp() can throw a ValueError when the timestamp is close to an integer value but not quite due to rounding errors. It then gives the following error: microsecond must be in 0..99 This can be seen by running the attached code (the values are taken from an actual event log), which gives the following output: 1146227423.0 -> 2006-04-28 14:30:23 1146227448.7 -> 2006-04-28 14:30:48.702000 1146227459.95 -> 2006-04-28 14:30:59.947000 1146227468.41 -> 2006-04-28 14:31:08.409000 1146227501.4 -> 2006-04-28 14:31:41.399000 1146227523.0 -> Error converting 1146227522.9976 microsecond must be in 0..99 Admittedly, I can work around the bug in this case, by summing the durations first, and calculating all times from "starttime" directly. Nevertheless, I think this is a bug in datetime, as it should work as long as the input time any floating point value within a given range (based on the date range that is supported). Details of my Python environment: Python 2.4.2 (#1, Feb 6 2006, 13:53:18) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-53)] on linux2 Cheers, Erwin -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 19:09 Message: Logged In: YES user_id=849994 Committed as rev. 45792, 45793, then. -- Comment By: Tim Peters (tim_one) Date: 2006-04-28 18:11 Message: Logged In: YES user_id=31435 Huh! My comment got lost. The patch looks good, but add 1 to `timet` instead of 1.0. We don't know whether the C time_t type is an integral or floating type, and using an integer literal works smoothly for both. For that matter, we don't know that time_t counts number of seconds either (e.g., perhaps it counts number of nanoseconds), but other code in Python assumes that it does, so there's no special sin in assuming it does here too. -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 17:32 Message: Logged In: YES user_id=849994 Really attaching a patch now. ;) -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-28 17:32 Message: Logged In: YES user_id=849994 Attaching a patch correcting this issue. Please review. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478429&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
