[ python-Bugs-1534517 ] getlines() in linecache.py raises TypeError
Bugs item #1534517, was opened at 2006-08-04 15:04 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=1534517&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Behnel (scoder) Assigned to: Nobody/Anonymous (nobody) Summary: getlines() in linecache.py raises TypeError Initial Comment: In my doctests, I get the following error under 2.5. I'm on AMD64 in case that's of any interest. Traceback (most recent call last): File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/unittest.py", line 260, in run testMethod() File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 2182, in runTest test, out=new.write, clear_globs=False) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 1389, in run return self.__run(test, compileflags, out) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 1280, in __run got += _exception_traceback(exc_info) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 257, in _exception_traceback traceback.print_exception(exc_type, exc_val, exc_tb, file=excout) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/traceback.py", line 125, in print_exception print_tb(tb, limit, file) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/traceback.py", line 69, in print_tb line = linecache.getline(filename, lineno, f.f_globals) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/linecache.py", line 14, in getline lines = getlines(filename, module_globals) TypeError: __patched_linecache_getlines() takes exactly 2 arguments (3 given) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534517&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467929 ] %-formatting and dicts
Bugs item #1467929, was opened at 2006-04-10 14:39
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&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: M.-A. Lemburg (lemburg)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: %-formatting and dicts
Initial Comment:
This looks like a bug in the way the %-formatting code
works or is it a feature ?
>>> '%s %(a)s' % {'a': 'xyz'}
"{'a': 'xyz'} xyz"
>>> u'%s %(a)s' % {'a': 'xyz'}
u"{'a': 'xyz'} xyz"
Note that both strings and Unicode are affected.
Python 2.3 and 2.4 also show this behavior.
I would have expected an exception or the %-formatter
simply ignoring the first %s.
--
>Comment By: Skip Montanaro (montanaro)
Date: 2006-08-04 08:21
Message:
Logged In: YES
user_id=44345
Looks okay to me, though why is the FORMAT_TYPE_UNKNOWN test
necessary in the second case but not the first?
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-25 07:35
Message:
Logged In: YES
user_id=11375
So, what should '%s' % {} do? Should it be 1) '{}' or 2) an
error because the argument is a mapping but the format
specifier doesn't have a '(key)'?
I've attached a draft patch that fixes stringobject.c; if
the approach is deemed OK, I'll apply it to unicodeobject.c,
too. PyString_Format() records the type of argument being
processed (a tuple or a mapping) and raises ValueError if
you mix them, at the cost of two extra comparisons for each
format specifier processed. This preserves the current
behaviour of '%s' % dictionary.
Questions: 1) is the approach reasonably clear? 2) are the
additional two comparisons unacceptably slow? 3) Is
ValueError the right exception? 4) can someone come up with
a better exception message than "both keyed and unkeyed
format specifiers used"?
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-07-24 15:07
Message:
Logged In: YES
user_id=21627
IMO, it's correct to break backwards compatibility, as the
current behaviour clearly violates the spec; I'm not sure
whether it's good to break the behaviour *now* (i.e. with no
further betas before the release of 2.5).
Deferring to the release manager.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 08:37
Message:
Logged In: YES
user_id=849994
The library ref specifies that if a dict is supplied, the
format specifiers MUST include a mapping key, so the right
thing to do would be to raise an exception.
Is it worth breaking backwards compatibility, Martin?
--
Comment By: Hasan Diwan (hdiwan650)
Date: 2006-04-14 03:33
Message:
Logged In: YES
user_id=1185570
It looks as though it's a feature... The first %s will print
the whole dictionary as a string, the second, only that
value looked up by the key.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467929 ] %-formatting and dicts
Bugs item #1467929, was opened at 2006-04-10 21:39
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&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: M.-A. Lemburg (lemburg)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: %-formatting and dicts
Initial Comment:
This looks like a bug in the way the %-formatting code
works or is it a feature ?
>>> '%s %(a)s' % {'a': 'xyz'}
"{'a': 'xyz'} xyz"
>>> u'%s %(a)s' % {'a': 'xyz'}
u"{'a': 'xyz'} xyz"
Note that both strings and Unicode are affected.
Python 2.3 and 2.4 also show this behavior.
I would have expected an exception or the %-formatter
simply ignoring the first %s.
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-08-04 15:26
Message:
Logged In: YES
user_id=38388
The patch looks OK.
I'd make it a TypeError and use "cannot use positional and
named formatting parameters at the same time" as message.
Thanks.
--
Comment By: Skip Montanaro (montanaro)
Date: 2006-08-04 15:21
Message:
Logged In: YES
user_id=44345
Looks okay to me, though why is the FORMAT_TYPE_UNKNOWN test
necessary in the second case but not the first?
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-25 14:35
Message:
Logged In: YES
user_id=11375
So, what should '%s' % {} do? Should it be 1) '{}' or 2) an
error because the argument is a mapping but the format
specifier doesn't have a '(key)'?
I've attached a draft patch that fixes stringobject.c; if
the approach is deemed OK, I'll apply it to unicodeobject.c,
too. PyString_Format() records the type of argument being
processed (a tuple or a mapping) and raises ValueError if
you mix them, at the cost of two extra comparisons for each
format specifier processed. This preserves the current
behaviour of '%s' % dictionary.
Questions: 1) is the approach reasonably clear? 2) are the
additional two comparisons unacceptably slow? 3) Is
ValueError the right exception? 4) can someone come up with
a better exception message than "both keyed and unkeyed
format specifiers used"?
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-07-24 22:07
Message:
Logged In: YES
user_id=21627
IMO, it's correct to break backwards compatibility, as the
current behaviour clearly violates the spec; I'm not sure
whether it's good to break the behaviour *now* (i.e. with no
further betas before the release of 2.5).
Deferring to the release manager.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 15:37
Message:
Logged In: YES
user_id=849994
The library ref specifies that if a dict is supplied, the
format specifiers MUST include a mapping key, so the right
thing to do would be to raise an exception.
Is it worth breaking backwards compatibility, Martin?
--
Comment By: Hasan Diwan (hdiwan650)
Date: 2006-04-14 10:33
Message:
Logged In: YES
user_id=1185570
It looks as though it's a feature... The first %s will print
the whole dictionary as a string, the second, only that
value looked up by the key.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1534517 ] getlines() in linecache.py raises TypeError
Bugs item #1534517, was opened at 2006-08-04 15:04 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534517&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Behnel (scoder) Assigned to: Nobody/Anonymous (nobody) Summary: getlines() in linecache.py raises TypeError Initial Comment: In my doctests, I get the following error under 2.5. I'm on AMD64 in case that's of any interest. Traceback (most recent call last): File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/unittest.py", line 260, in run testMethod() File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 2182, in runTest test, out=new.write, clear_globs=False) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 1389, in run return self.__run(test, compileflags, out) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 1280, in __run got += _exception_traceback(exc_info) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 257, in _exception_traceback traceback.print_exception(exc_type, exc_val, exc_tb, file=excout) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/traceback.py", line 125, in print_exception print_tb(tb, limit, file) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/traceback.py", line 69, in print_tb line = linecache.getline(filename, lineno, f.f_globals) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/linecache.py", line 14, in getline lines = getlines(filename, module_globals) TypeError: __patched_linecache_getlines() takes exactly 2 arguments (3 given) -- Comment By: �iga Seilnacht (zseil) Date: 2006-08-04 15:30 Message: Logged In: YES user_id=1326842 This bug is caused by your custom doctest module. Doctest monkeypatches linecache's getlines() function. It was fixed in the standard library to support an aditional argument, but it looks that lxml is still using the 2.4 version. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534517&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1534517 ] getlines() in linecache.py raises TypeError
Bugs item #1534517, was opened at 2006-08-04 15:04 Message generated for change (Comment added) made by scoder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534517&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.5 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Stefan Behnel (scoder) Assigned to: Nobody/Anonymous (nobody) Summary: getlines() in linecache.py raises TypeError Initial Comment: In my doctests, I get the following error under 2.5. I'm on AMD64 in case that's of any interest. Traceback (most recent call last): File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/unittest.py", line 260, in run testMethod() File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 2182, in runTest test, out=new.write, clear_globs=False) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 1389, in run return self.__run(test, compileflags, out) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 1280, in __run got += _exception_traceback(exc_info) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 257, in _exception_traceback traceback.print_exception(exc_type, exc_val, exc_tb, file=excout) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/traceback.py", line 125, in print_exception print_tb(tb, limit, file) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/traceback.py", line 69, in print_tb line = linecache.getline(filename, lineno, f.f_globals) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/linecache.py", line 14, in getline lines = getlines(filename, module_globals) TypeError: __patched_linecache_getlines() takes exactly 2 arguments (3 given) -- >Comment By: Stefan Behnel (scoder) Date: 2006-08-04 16:06 Message: Logged In: YES user_id=313935 Argh! Sure. I only saw "doctest" and "linecache" and didn't even notice it was using the local file. No idea why it's there anyway. Thanks! Great time to close this 'bug' ... -- Comment By: �iga Seilnacht (zseil) Date: 2006-08-04 15:30 Message: Logged In: YES user_id=1326842 This bug is caused by your custom doctest module. Doctest monkeypatches linecache's getlines() function. It was fixed in the standard library to support an aditional argument, but it looks that lxml is still using the 2.4 version. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534517&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-1534607 ] IndexError: Add bad index to msg
Feature Requests item #1534607, was opened at 2006-08-04 09:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1534607&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Michael Kleehammer (mkleehammer) Assigned to: Nobody/Anonymous (nobody) Summary: IndexError: Add bad index to msg Initial Comment: It would be very helpful to add more information to the IndexErrors raised by the built-in classes. Today, these errors look like: IndexError: list index out of range When these occur, I usually have to add print statements before the error and reproduce the problem to determine what has gone wrong. If the list and tuple classes add the requested index and the length of the structure, it would help a lot. Below is a suggestion: IndexError: list index 30 out of range; len=27 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1534607&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1534630 ] Python 2.5 svn crash in _elementtree.c
Bugs item #1534630, was opened at 2006-08-04 11:29 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=1534630&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.5 Status: Open Resolution: None Priority: 9 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fredrik Lundh (effbot) Summary: Python 2.5 svn crash in _elementtree.c Initial Comment: /F's sourceforge screen scraper tool triggered a crash in _elementtree.c in the latest Python 2.5 svn. It seems that a Py_DECREF should probably be a Py_XDECREF unless there's some other logic bug I'm missing. Here's the patch if it's the former. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1530448 ] ctypes build fails on Solaris 10
Bugs item #1530448, was opened at 2006-07-28 17:04 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&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: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip -- >Comment By: Thomas Heller (theller) Date: 2006-08-04 20:29 Message: Logged In: YES user_id=11105 Yes, the patch was supposed to be applied to the top-level setup.py script, in the same directory as the README and the LICENSE files. If you applied the patch, and '-mimpure-text' does not appear on the linker command line (for me, it appears at the very end), the only explanation I see is that sys.platform == "sunos5" is not true on your system. Can that be? -- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 22:37 Message: Logged In: YES user_id=44345 make that "_ctypes.so"... -- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 22:14 Message: Logged In: YES user_id=44345 When I manually link _ctypes.o with -mimpure-text the link succeeds, but applying it to the configure script had no discernable effect. Was I supposed to apply it to the top-level Python configure script or to one deeper in the tree? Skip -- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 22:02 Message: Logged In: YES user_id=44345 Thomas, I did an svn up (rev 51078), deleted any local changes, created a new build directory, configured and built. I got the same error about ffi_closure_SYSV_inner. I then manually reran the link command without mention of ffi.o or sysv.o. It linked fine but when I ran make again it complained that _ctypes.so couldn't resolve ffi_prep_closure. This symbol is defined in ffi.o, so it appears either that ffi.c is needed in the source list or maybe ffi64.c needs to be modified to provide it. As far as I can tell it doesn't export any useful symbols: $ nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o: 00 s 00 s 00 s 00 s 00 s 00 s 00 f ffi64.c Skip -- Comment By: Thomas Heller (theller) Date: 2006-08-03 21:36 Message: Logged In: YES user_id=11105 Correction: The opti
[ python-Bugs-1530448 ] ctypes build fails on Solaris 10
Bugs item #1530448, was opened at 2006-07-28 10:04 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&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: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip -- >Comment By: Skip Montanaro (montanaro) Date: 2006-08-04 13:44 Message: Logged In: YES user_id=44345 It turned out to be a patch problem (something I've never encountered before): % patch -p0 < /home/titan/skipm/Desktop/setup.py\(2\).patch patching file setup.py Hunk #2 succeeded at 1361 with fuzz 2. I tried deleting setup.py, svn up'ing and reapplying the patch a couple other times. When I manually compared the new setup.py with the diff file I saw that the stuff below the "Is this still needed?" line wasn't actually applied. I manually updated setup.py from the diff file (good thing it was a simple diff!) It now builds properly. Thanks for all the work you put into this, Thomas. Skip -- Comment By: Thomas Heller (theller) Date: 2006-08-04 13:29 Message: Logged In: YES user_id=11105 Yes, the patch was supposed to be applied to the top-level setup.py script, in the same directory as the README and the LICENSE files. If you applied the patch, and '-mimpure-text' does not appear on the linker command line (for me, it appears at the very end), the only explanation I see is that sys.platform == "sunos5" is not true on your system. Can that be? -- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 15:37 Message: Logged In: YES user_id=44345 make that "_ctypes.so"... -- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 15:14 Message: Logged In: YES user_id=44345 When I manually link _ctypes.o with -mimpure-text the link succeeds, but applying it to the configure script had no discernable effect. Was I supposed to apply it to the top-level Python configure script or to one deeper in the tree? Skip -- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 15:02 Message: Logged In: YES user_id=44345 Thomas, I did an svn up (rev 51078), deleted any local changes, created a new build directory, configured and built. I got the same error about ffi_closure_SYSV_inner. I then manually reran the link command without mention of ffi.o or sysv.o. It linked fine but when I ran make again it complained that _ctypes.so couldn't resolve ffi_prep_clo
[ python-Bugs-1530448 ] ctypes build fails on Solaris 10
Bugs item #1530448, was opened at 2006-07-28 17:04 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip -- >Comment By: Thomas Heller (theller) Date: 2006-08-04 20:58 Message: Logged In: YES user_id=11105 I apologize for the damaged patch - I could not apply it correctly either. Somehow an empty line made into it, or whatever. Thanks for testing! Committed as r51113. -- Comment By: Skip Montanaro (montanaro) Date: 2006-08-04 20:44 Message: Logged In: YES user_id=44345 It turned out to be a patch problem (something I've never encountered before): % patch -p0 < /home/titan/skipm/Desktop/setup.py\(2\).patch patching file setup.py Hunk #2 succeeded at 1361 with fuzz 2. I tried deleting setup.py, svn up'ing and reapplying the patch a couple other times. When I manually compared the new setup.py with the diff file I saw that the stuff below the "Is this still needed?" line wasn't actually applied. I manually updated setup.py from the diff file (good thing it was a simple diff!) It now builds properly. Thanks for all the work you put into this, Thomas. Skip -- Comment By: Thomas Heller (theller) Date: 2006-08-04 20:29 Message: Logged In: YES user_id=11105 Yes, the patch was supposed to be applied to the top-level setup.py script, in the same directory as the README and the LICENSE files. If you applied the patch, and '-mimpure-text' does not appear on the linker command line (for me, it appears at the very end), the only explanation I see is that sys.platform == "sunos5" is not true on your system. Can that be? -- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 22:37 Message: Logged In: YES user_id=44345 make that "_ctypes.so"... -- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 22:14 Message: Logged In: YES user_id=44345 When I manually link _ctypes.o with -mimpure-text the link succeeds, but applying it to the configure script had no discernable effect. Was I supposed to apply it to the top-level Python configure script or to one deeper in the tree? Skip -- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 22:02 Message: Logged In: YES user_id=44345 Tho
[ python-Bugs-1529269 ] Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)
Bugs item #1529269, was opened at 2006-07-26 23:17 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&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: Guido Ostkamp (ostkamp) Assigned to: Thomas Heller (theller) Summary: Python 2.5b2 fails to build on Solaris 10 (GCC Compiler) Initial Comment: Hello, as promised here is the second report because of problems with building Python 2.5b2 on Solaris 10 (Sparc). I have been using the GCC this time. These are the problems (for full logs please see attachments): building '_ctypes' extension gcc -shared build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules /_ctypes/_ctypes.o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/ Modules/_ctypes/callbacks.o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Pyth on-2.5b2/Modules/_ctypes/callproc.o build/temp.solaris-2.10-sun4us-2.5/home/ostk amp/Python-2.5b2/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-sun4us-2.5/ho me/ostkamp/Python-2.5b2/Modules/_ctypes/cfield.o build/temp.solaris-2.10-sun4us- 2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/malloc_closure.o build/temp.solari s-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/prep_cif. o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/l ibffi/src/sparc/ffi.o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5 b2/Modules/_ctypes/libffi/src/sparc/v8.o build/temp.solaris-2.10-sun4us-2.5/home /ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v9.o -o build/lib.solaris -2.10-sun4us-2.5/_ctypes.so ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeedcca5 is non-aligned ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeedccab is non-aligned ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeedccaf is non-aligned ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeedccb3 is non-aligned ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeeeae06 is non-aligned ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeeecaf6 is non-aligned collect2: ld returned 1 exit status building '_curses' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/ home/ostkamp/Python-2.5b2/./Include -I./Include -I. -I/home/ostkamp/Python-2.5b2 /Include -I/home/ostkamp/Python-2.5b2 -c /home/ostkamp/Python-2.5b2/Modules/_cur sesmodule.c -o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu les/_cursesmodule.o /home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c: In function `PyCursesWindow_ GetStr': /home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c:822: warning: implicit declar ation of function `mvwgetnstr' gcc -shared build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules /_cursesmodule.o -lcurses -ltermcap -o build/lib.solaris-2.10-sun4us-2.5/_curses .so *** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fata l: relocation error: file build/lib.solaris-2.10-sun4us-2.5/_curses.so: symbol m vwgetnstr: referenced symbol not found building '_curses_panel' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/ home/ostkamp/Python-2.5b2/./Include -I./Include -I. -I/home/ostkamp/Python-2.5b2 /Include -I/home/ostkamp/Python-2.5b2 -c /home/ostkamp/Python-2.5b2/Modules/_cur ses_panel.c -o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu les/_curses_panel.o gcc -shared build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules /_curses_panel.o -lpanel -lcurses -ltermcap -o build/lib.solaris-2.10-sun4us-2.5 /_curses_panel.so *** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses running build_scripts Regards, Guido -- >Comment By: Thomas Heller (theller) Date: 2006-08-04 21:04 Message: Logged In: YES user_id=11105 Guido, in SVN revision 51113 a change was committed that adds the '-mimpure-text' flag to the linker when linking the _ctypes.so file. This fixed the b
[ python-Bugs-1534738 ] Win32 debug version of _msi creates _msi.pyd, not _msi_d.pyd
Bugs item #1534738, was opened at 2006-08-04 19:11 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=1534738&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: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Win32 debug version of _msi creates _msi.pyd, not _msi_d.pyd Initial Comment: The .vcproj file has the the output file set to _msi.pyd for the debug target instead of _msi_d.pyd so the incorrect file is created. This leads to a crash if python.exe tries to import _msi and _msi.pyd is the debug version. The fix is to add a _d to the output file field for the debug target. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534738&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1534738 ] Win32 debug version of _msi creates _msi.pyd, not _msi_d.pyd
Bugs item #1534738, was opened at 2006-08-04 21:11 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534738&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: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Win32 debug version of _msi creates _msi.pyd, not _msi_d.pyd Initial Comment: The .vcproj file has the the output file set to _msi.pyd for the debug target instead of _msi_d.pyd so the incorrect file is created. This leads to a crash if python.exe tries to import _msi and _msi.pyd is the debug version. The fix is to add a _d to the output file field for the debug target. -- >Comment By: Thomas Heller (theller) Date: 2006-08-04 21:54 Message: Logged In: YES user_id=11105 I made the change to the PCBuild/_msi.vcproj file in SVN r51114, someone with Visual Studio 2005 should probably fix PCBuild8/_msi.vcproj as well and close this bug. Thanks for the heads up, John. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534738&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1534764 ] sys.path gets munged with certain directory structures
Bugs item #1534764, was opened at 2006-08-04 14: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=1534764&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: 5 Submitted By: Gustavo Tabares (gustavotabares) Assigned to: Nobody/Anonymous (nobody) Summary: sys.path gets munged with certain directory structures Initial Comment: Platform: Windows XP SP2 Python Version: 2.4.2 final First off, I'm not sure if this is the same bug as 947380 . Comments say it was fixed in Python 2.4, but I'm running Python 2.4.2 and it looks like I'm hitting the same issue. If this is the same issue and has been fixed in a later version, I apologize. To reproduce: 1. Create a new directory (e.g., 'foo'). 2. Inside foo, create a __init__.py along with a directory called 'stat' which also has an empty __init__.py inside of it. 3. 'cd' to this directory via the command line and start the Python interpreter. Observe the 'import site' failed error. A quick check at sys.path reveals that sys.path is munged and doesn't contain all that it should. WORKAROUND: Rename 'stat' directory to 'stats' or something else. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534764&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1534765 ] logging's fileConfig causes KeyError on shutdown
Bugs item #1534765, was opened at 2006-08-04 15:58 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=1534765&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: mdbeachy (mdbeachy) Assigned to: Nobody/Anonymous (nobody) Summary: logging's fileConfig causes KeyError on shutdown Initial Comment: If logging.config.fileConfig() is called after logging handlers already exist, a KeyError is thrown in the atexit call to logging.shutdown(). This looks like it's fixed in the 2.5 branch but since I've bothered to figure out what was going on I'm sending this in anyway. There still might be a 2.4.4, right? (Also, my fix looks better than what was done for 2.5, but I suppose the flush/close I added may not be necessary.) Attached is a demo and a patch against 2.4.3. Thanks, Mike -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534765&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1433886 ] pointer aliasing causes core dump, with workaround
Bugs item #1433886, was opened at 2006-02-17 16:56 Message generated for change (Comment added) made by qbarnes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Quentin Barnes (qbarnes) Assigned to: Nobody/Anonymous (nobody) Summary: pointer aliasing causes core dump, with workaround Initial Comment: When building 2.3.3 on Solaris using Studio 11 and "-xalias_level=std" to enable ISO C99 pointer aliasing rules, the interpreter would core dump when running test_descr2.py. From examining the source, I believe this problem exists in 2.4.2 as well, but did not verify it. I was able to simplify the code to invoke the problem down to: class C1(object): def __new__(cls): return super(C1, cls).__new__(cls) a = C1() I tracked the problem to super_init() in Objects/typeobject.c. The local variable "obj" is of type "PyObject *" and "type" is of type "PyTypeObject *". In this function, both variables can be pointing to the same object in memory. Since the pointers are not of compatible types, the compiler ends up optimizing out a memory load between Py_INCREF(obj) and Py_INCREF(type) caching a previously read value. This causes the object reference counter to only be incremented once instead of twice. When the object is deallocated, the interpreter blows up. A workaround is to cast one of the pointers to the others type so that the compiler can see the pointer aliasing potential. This is what I did in the patch. What I suspect needs to be done as a more global fix is to discontinue use of the PyObject_VAR_HEAD macro hack. Casting between structures containing this macro creates ISO C99 pointer aliasing violations. The contents of the macro needs to be in its own structure which is referenced so a compliant compiler can know of possible aliasing. -- >Comment By: Quentin Barnes (qbarnes) Date: 2006-08-04 15:04 Message: Logged In: YES user_id=288734 It doesn't matter which standard is used, C99 or C89, the aliasing violation is the same. An object is being accessed through two different aggregate type aliases. The language in C99 section 6.5 is the same in this regards as C89 section 3.3. (Actually, C99 is slightly looser than C89 since it allows effective type aliasing which C89 does not have.) -- Comment By: Tim Peters (tim_one) Date: 2006-08-03 21:47 Message: Logged In: YES user_id=31435 Yes, Python must be compiled with -fno-strict-aliasing (or moral equivalent). No, that's not going to change before Python 3000 (if even then). All Python object structs conceptually extend the PyObject struct, including (but not limited to) object structs conceptually extending the PyVarObject struct (which in turn conceptually extends the PyObject struct). This is uniquitous in the core source code, and in all 3rd-party extension modules defining new Python objects in C. Note that Python doesn't much care about C99. It was written against K&R C, and went nearly a decade before requiring C89 (it took that long for C89-conforming compilers to show up on all interesting Python platforms). Best guess is that it will never require C99 (because best guess is that C99-conforming compilers will never show up on all interesting Python platforms). That said, I don't see anything to object to in adding fiddly casting patches to make sure compilers don't try to exploit the trivial optimization opportunities that assuming no aliasing in the Python source may allow. -- Comment By: Quentin Barnes (qbarnes) Date: 2006-08-03 21:24 Message: Logged In: YES user_id=288734 There is no reason why the source code for Python cannot conform to ISO C99 pointer aliasing rules. If pointers are being improperly aliased violating the C standard, it's just bad programming practice. The only reason to use a switch like GCC's -fno-strict-aliasing or Solaris' -xalias_level=any is for old legacy code, not well-programmed, actively maintained code. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 16:24 Message: Logged In: YES user_id=11375 I have the vague impression that Python's code doesn't conform to strict aliasing, and it therefore must always be compiled with GCC's -fno-strict-aliasing option or the equivalent. Your fix might avoid that one problem, but there might be other subtle bugs. Assigning to Tim Peters, who will know if the -fno-strict-aliasing statement is correct. -
[ python-Bugs-1534769 ] Identical floats print inconsistently
Bugs item #1534769, was opened at 2006-08-04 20:07 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=1534769&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: Open Resolution: None Priority: 5 Submitted By: Marc W. Abel (gihon) Assigned to: Nobody/Anonymous (nobody) Summary: Identical floats print inconsistently Initial Comment: Hi, and thank you. Many bugs relating to this have been submitted by others over a period of years, and these have generally been closed with "not a bug" responses. I'll do my best to explain the problem clearly enough. The following session prints a single variable three ways, with two different results: --- [EMAIL PROTECTED] current]$ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = round(1./7, 3) >>> print a 0.143 >>> print (a,) (0.14299,) >>> print (a,)[0] 0.143 >>> --- I'm fully informed about IEEE floating point representations in binary, but the limitations of data type are not causing the difference in output. The interpreter is using different rules to print this float, depending on whether it's a straight float or part of some other structure (in this example, a tuple). Once the interpreter recurses to a depth where it's clearly going to print a float, whatever rule is selected needs to be consistently applied. This means calling the same string formatting code with the same inputs. Marc -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534769&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1534769 ] Identical floats print inconsistently
Bugs item #1534769, was opened at 2006-08-04 20:07 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534769&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: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Marc W. Abel (gihon) Assigned to: Nobody/Anonymous (nobody) Summary: Identical floats print inconsistently Initial Comment: Hi, and thank you. Many bugs relating to this have been submitted by others over a period of years, and these have generally been closed with "not a bug" responses. I'll do my best to explain the problem clearly enough. The following session prints a single variable three ways, with two different results: --- [EMAIL PROTECTED] current]$ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = round(1./7, 3) >>> print a 0.143 >>> print (a,) (0.14299,) >>> print (a,)[0] 0.143 >>> --- I'm fully informed about IEEE floating point representations in binary, but the limitations of data type are not causing the difference in output. The interpreter is using different rules to print this float, depending on whether it's a straight float or part of some other structure (in this example, a tuple). Once the interpreter recurses to a depth where it's clearly going to print a float, whatever rule is selected needs to be consistently applied. This means calling the same string formatting code with the same inputs. Marc -- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-04 20:14 Message: Logged In: YES user_id=849994 Sorry, but this is another "not a bug". "print tuple" invokes tuple.__repr__() (because there is no separate __str__) which invokes repr(item) on each tuple item, while "print item" invokes str(item). For floats, this distinction results in a different rounding precision. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534769&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1534765 ] logging's fileConfig causes KeyError on shutdown
Bugs item #1534765, was opened at 2006-08-04 19:58 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534765&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: mdbeachy (mdbeachy) >Assigned to: Vinay Sajip (vsajip) Summary: logging's fileConfig causes KeyError on shutdown Initial Comment: If logging.config.fileConfig() is called after logging handlers already exist, a KeyError is thrown in the atexit call to logging.shutdown(). This looks like it's fixed in the 2.5 branch but since I've bothered to figure out what was going on I'm sending this in anyway. There still might be a 2.4.4, right? (Also, my fix looks better than what was done for 2.5, but I suppose the flush/close I added may not be necessary.) Attached is a demo and a patch against 2.4.3. Thanks, Mike -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534765&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1522046 ] RPM build fails for Py2.5b2
Bugs item #1522046, was opened at 2006-07-13 13:55
Message generated for change (Comment added) made by breadman
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522046&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: Stefan Behnel (scoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: RPM build fails for Py2.5b2
Initial Comment:
Using Misc/RPM/python-2.5.spec, Python 2.5b2 fails to
compile into an RPM on my machine (SuSE 10.1, AMD64,
gcc 4.1). Unlike with b1, I get loads of errors saying:
"ld: cannot find -lpython2.5"
The funny thing is that it continues to build and only
fails at the end when collecting the files for the RPM.
I use
configure --enable-shared --enable-unicode=ucs4 \
--enable-ipv6 --with-pymalloc --prefix=/usr \
--libdir=/usr/lib64
The shared library is correctly built before these
errors come up. The error appear on the "sharedmods"
target. I also tried setting LD_LIBRARY_PATH by hand,
although the build script sets it before starting to
build the modules - no help.
What *does* help is adding "-L." to the LDFLAGS in
Makefile.pre.in:
sed -e '/DIR=.*lib$/ s|/lib$|/%{libdirname}| ; \
/LDFLAGS/ s|LDFLAGS=|LDFLAGS= -L. |'\
./Makefile.pre.in.old >Makefile.pre.in
The "DIR=" is for an x86_64 bug that installs Python to
the wrong directory (/usr/lib instead of /usr/lib64).
I tried building Py2.5 by hand (configure/make) and
that also works nicely.
I attached a patch that fixes the problems I encountered.
--
Comment By: Eric Wald (breadman)
Date: 2006-08-04 14:22
Message:
Logged In: YES
user_id=324500
Seems to be fixed in 2.5b3.
--
Comment By: Eric Wald (breadman)
Date: 2006-08-03 14:12
Message:
Logged In: YES
user_id=324500
There is a deeper issue here: Dynamic extensions fail to
link until after libpython2.5.so.1.0 is installed. The
'-L.' flag is the better approach to fixing this bug, but
perhaps it should use the full path name, like the
LD_LIBRARY_PATH environment variable used when running
setup.py. Unfortunately, this bug is hidden from people
compiling on top of an earlier 2.5 installation, where the
link step will find and use the old library; for others, it
is resolved in installation, where make will happily link
the extensions if they failed to link earlier, right after
installing the library.
However, it means that the dynamic libraries are unavailable
between the build and install steps. One major result is
that the test suite refuses to run at that time. It also
means that 'make install' can cause the linker to be called,
which is generally discouraged.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522046&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1433886 ] pointer aliasing causes core dump, with workaround
Bugs item #1433886, was opened at 2006-02-17 17:56 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Quentin Barnes (qbarnes) Assigned to: Nobody/Anonymous (nobody) Summary: pointer aliasing causes core dump, with workaround Initial Comment: When building 2.3.3 on Solaris using Studio 11 and "-xalias_level=std" to enable ISO C99 pointer aliasing rules, the interpreter would core dump when running test_descr2.py. From examining the source, I believe this problem exists in 2.4.2 as well, but did not verify it. I was able to simplify the code to invoke the problem down to: class C1(object): def __new__(cls): return super(C1, cls).__new__(cls) a = C1() I tracked the problem to super_init() in Objects/typeobject.c. The local variable "obj" is of type "PyObject *" and "type" is of type "PyTypeObject *". In this function, both variables can be pointing to the same object in memory. Since the pointers are not of compatible types, the compiler ends up optimizing out a memory load between Py_INCREF(obj) and Py_INCREF(type) caching a previously read value. This causes the object reference counter to only be incremented once instead of twice. When the object is deallocated, the interpreter blows up. A workaround is to cast one of the pointers to the others type so that the compiler can see the pointer aliasing potential. This is what I did in the patch. What I suspect needs to be done as a more global fix is to discontinue use of the PyObject_VAR_HEAD macro hack. Casting between structures containing this macro creates ISO C99 pointer aliasing violations. The contents of the macro needs to be in its own structure which is referenced so a compliant compiler can know of possible aliasing. -- >Comment By: Tim Peters (tim_one) Date: 2006-08-04 17:10 Message: Logged In: YES user_id=31435 Sorry, but it still doesn't really matter what any version of the C standard says here: the /conceptual/ extension of the PyObject struct by all Python object structs is the source of the problem, and is ubiquitous both within the core and throughout countless 3rd-party extension modules. This isn't realistically fixable before Python 3000. In the meantime, use of the platform equivalent to gcc's -fno-strict-aliasing option is necessary. -- Comment By: Quentin Barnes (qbarnes) Date: 2006-08-04 16:04 Message: Logged In: YES user_id=288734 It doesn't matter which standard is used, C99 or C89, the aliasing violation is the same. An object is being accessed through two different aggregate type aliases. The language in C99 section 6.5 is the same in this regards as C89 section 3.3. (Actually, C99 is slightly looser than C89 since it allows effective type aliasing which C89 does not have.) -- Comment By: Tim Peters (tim_one) Date: 2006-08-03 22:47 Message: Logged In: YES user_id=31435 Yes, Python must be compiled with -fno-strict-aliasing (or moral equivalent). No, that's not going to change before Python 3000 (if even then). All Python object structs conceptually extend the PyObject struct, including (but not limited to) object structs conceptually extending the PyVarObject struct (which in turn conceptually extends the PyObject struct). This is uniquitous in the core source code, and in all 3rd-party extension modules defining new Python objects in C. Note that Python doesn't much care about C99. It was written against K&R C, and went nearly a decade before requiring C89 (it took that long for C89-conforming compilers to show up on all interesting Python platforms). Best guess is that it will never require C99 (because best guess is that C99-conforming compilers will never show up on all interesting Python platforms). That said, I don't see anything to object to in adding fiddly casting patches to make sure compilers don't try to exploit the trivial optimization opportunities that assuming no aliasing in the Python source may allow. -- Comment By: Quentin Barnes (qbarnes) Date: 2006-08-03 22:24 Message: Logged In: YES user_id=288734 There is no reason why the source code for Python cannot conform to ISO C99 pointer aliasing rules. If pointers are being improperly aliased violating the C standard, it's just bad programming practice. The only reason to use a switch like GCC's -fno-strict-aliasing or Solaris' -xalias_lev
[ python-Bugs-1534769 ] Identical floats print inconsistently
Bugs item #1534769, was opened at 2006-08-04 16:07
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534769&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: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Marc W. Abel (gihon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Identical floats print inconsistently
Initial Comment:
Hi, and thank you.
Many bugs relating to this have been submitted by
others over a period of years, and these have generally
been closed with "not a bug" responses. I'll do my
best to explain the problem clearly enough.
The following session prints a single variable three
ways, with two different results:
---
[EMAIL PROTECTED] current]$ python
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> a = round(1./7, 3)
>>> print a
0.143
>>> print (a,)
(0.14299,)
>>> print (a,)[0]
0.143
>>>
---
I'm fully informed about IEEE floating point
representations in binary, but the limitations of data
type are not causing the difference in output. The
interpreter is using different rules to print this
float, depending on whether it's a straight float or
part of some other structure (in this example, a tuple).
Once the interpreter recurses to a depth where it's
clearly going to print a float, whatever rule is
selected needs to be consistently applied. This means
calling the same string formatting code with the same
inputs.
Marc
--
>Comment By: Tim Peters (tim_one)
Date: 2006-08-04 17:24
Message:
Logged In: YES
user_id=31435
gbrandl is correct that the differences here are entirely
due to the difference between float's __repr__ and __str__
methods. The reasons they /are/ different for floats are
explained in the Tutorial's appendix on floating-point issues.
It may be considered unfortunate that tuple.__repr__ is the
same as tuple.__str__, and that both "pass repr down" to
containees, but the reason for that has to do with the
difference between str.__repr__ and str.__str__. If
str(tuple) "passed str down" to containees, then, e.g.,
print ("a, bc", "de f,", "gh), i")
would display the incomprehensibly confused:
(a, bc, de f,, gh), i)
IOW, it's actually the difference in what string types do
that /drives/ the general decision that c.__str__ is the
same as c.__repr__ for all objects `c` of container types,
and that both "pass repr down" to containees.
Alas, that's not always what people using strings want
either :-)
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-04 16:14
Message:
Logged In: YES
user_id=849994
Sorry, but this is another "not a bug".
"print tuple" invokes tuple.__repr__() (because there is no
separate __str__) which invokes repr(item) on each tuple
item, while "print item" invokes str(item). For floats, this
distinction results in a different rounding precision.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534769&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1433886 ] pointer aliasing causes core dump, with workaround
Bugs item #1433886, was opened at 2006-02-17 16:56 Message generated for change (Comment added) made by qbarnes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Quentin Barnes (qbarnes) Assigned to: Nobody/Anonymous (nobody) Summary: pointer aliasing causes core dump, with workaround Initial Comment: When building 2.3.3 on Solaris using Studio 11 and "-xalias_level=std" to enable ISO C99 pointer aliasing rules, the interpreter would core dump when running test_descr2.py. From examining the source, I believe this problem exists in 2.4.2 as well, but did not verify it. I was able to simplify the code to invoke the problem down to: class C1(object): def __new__(cls): return super(C1, cls).__new__(cls) a = C1() I tracked the problem to super_init() in Objects/typeobject.c. The local variable "obj" is of type "PyObject *" and "type" is of type "PyTypeObject *". In this function, both variables can be pointing to the same object in memory. Since the pointers are not of compatible types, the compiler ends up optimizing out a memory load between Py_INCREF(obj) and Py_INCREF(type) caching a previously read value. This causes the object reference counter to only be incremented once instead of twice. When the object is deallocated, the interpreter blows up. A workaround is to cast one of the pointers to the others type so that the compiler can see the pointer aliasing potential. This is what I did in the patch. What I suspect needs to be done as a more global fix is to discontinue use of the PyObject_VAR_HEAD macro hack. Casting between structures containing this macro creates ISO C99 pointer aliasing violations. The contents of the macro needs to be in its own structure which is referenced so a compliant compiler can know of possible aliasing. -- >Comment By: Quentin Barnes (qbarnes) Date: 2006-08-04 16:30 Message: Logged In: YES user_id=288734 I wasn't demanding the bug be fixed in the present source base. I understand that's impractical due to the invasive nature of the PyObject_VAR_HEAD macro trick. I was just trying to clarify that the trick is an invalid coding practice even under C89. I didn't want people assuming it was ok because of them thinking it was only a problem under C99 and later standards while safe under C89. -- Comment By: Tim Peters (tim_one) Date: 2006-08-04 16:10 Message: Logged In: YES user_id=31435 Sorry, but it still doesn't really matter what any version of the C standard says here: the /conceptual/ extension of the PyObject struct by all Python object structs is the source of the problem, and is ubiquitous both within the core and throughout countless 3rd-party extension modules. This isn't realistically fixable before Python 3000. In the meantime, use of the platform equivalent to gcc's -fno-strict-aliasing option is necessary. -- Comment By: Quentin Barnes (qbarnes) Date: 2006-08-04 15:04 Message: Logged In: YES user_id=288734 It doesn't matter which standard is used, C99 or C89, the aliasing violation is the same. An object is being accessed through two different aggregate type aliases. The language in C99 section 6.5 is the same in this regards as C89 section 3.3. (Actually, C99 is slightly looser than C89 since it allows effective type aliasing which C89 does not have.) -- Comment By: Tim Peters (tim_one) Date: 2006-08-03 21:47 Message: Logged In: YES user_id=31435 Yes, Python must be compiled with -fno-strict-aliasing (or moral equivalent). No, that's not going to change before Python 3000 (if even then). All Python object structs conceptually extend the PyObject struct, including (but not limited to) object structs conceptually extending the PyVarObject struct (which in turn conceptually extends the PyObject struct). This is uniquitous in the core source code, and in all 3rd-party extension modules defining new Python objects in C. Note that Python doesn't much care about C99. It was written against K&R C, and went nearly a decade before requiring C89 (it took that long for C89-conforming compilers to show up on all interesting Python platforms). Best guess is that it will never require C99 (because best guess is that C99-conforming compilers will never show up on all interesting Python platforms). That said, I don't see anything to object to in adding fiddly casting patches to make sure compilers don't try to expl
[ python-Bugs-1433886 ] pointer aliasing causes core dump, with workaround
Bugs item #1433886, was opened at 2006-02-17 17:56 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Quentin Barnes (qbarnes) Assigned to: Nobody/Anonymous (nobody) Summary: pointer aliasing causes core dump, with workaround Initial Comment: When building 2.3.3 on Solaris using Studio 11 and "-xalias_level=std" to enable ISO C99 pointer aliasing rules, the interpreter would core dump when running test_descr2.py. From examining the source, I believe this problem exists in 2.4.2 as well, but did not verify it. I was able to simplify the code to invoke the problem down to: class C1(object): def __new__(cls): return super(C1, cls).__new__(cls) a = C1() I tracked the problem to super_init() in Objects/typeobject.c. The local variable "obj" is of type "PyObject *" and "type" is of type "PyTypeObject *". In this function, both variables can be pointing to the same object in memory. Since the pointers are not of compatible types, the compiler ends up optimizing out a memory load between Py_INCREF(obj) and Py_INCREF(type) caching a previously read value. This causes the object reference counter to only be incremented once instead of twice. When the object is deallocated, the interpreter blows up. A workaround is to cast one of the pointers to the others type so that the compiler can see the pointer aliasing potential. This is what I did in the patch. What I suspect needs to be done as a more global fix is to discontinue use of the PyObject_VAR_HEAD macro hack. Casting between structures containing this macro creates ISO C99 pointer aliasing violations. The contents of the macro needs to be in its own structure which is referenced so a compliant compiler can know of possible aliasing. -- >Comment By: Tim Peters (tim_one) Date: 2006-08-04 17:41 Message: Logged In: YES user_id=31435 Ah, OK, and I have no argument with that. Well ;-), I'd state it more strongly: there are > 150 places in the core that stick PyObject_HEAD at the start of a struct declaration, and so, e.g., there are potential aliasing problems even between PyObject* and PyIntObject* pointers. IOW, PyObject_VAR_HEAD isn't the whole story here (or even most of it). -- Comment By: Quentin Barnes (qbarnes) Date: 2006-08-04 17:30 Message: Logged In: YES user_id=288734 I wasn't demanding the bug be fixed in the present source base. I understand that's impractical due to the invasive nature of the PyObject_VAR_HEAD macro trick. I was just trying to clarify that the trick is an invalid coding practice even under C89. I didn't want people assuming it was ok because of them thinking it was only a problem under C99 and later standards while safe under C89. -- Comment By: Tim Peters (tim_one) Date: 2006-08-04 17:10 Message: Logged In: YES user_id=31435 Sorry, but it still doesn't really matter what any version of the C standard says here: the /conceptual/ extension of the PyObject struct by all Python object structs is the source of the problem, and is ubiquitous both within the core and throughout countless 3rd-party extension modules. This isn't realistically fixable before Python 3000. In the meantime, use of the platform equivalent to gcc's -fno-strict-aliasing option is necessary. -- Comment By: Quentin Barnes (qbarnes) Date: 2006-08-04 16:04 Message: Logged In: YES user_id=288734 It doesn't matter which standard is used, C99 or C89, the aliasing violation is the same. An object is being accessed through two different aggregate type aliases. The language in C99 section 6.5 is the same in this regards as C89 section 3.3. (Actually, C99 is slightly looser than C89 since it allows effective type aliasing which C89 does not have.) -- Comment By: Tim Peters (tim_one) Date: 2006-08-03 22:47 Message: Logged In: YES user_id=31435 Yes, Python must be compiled with -fno-strict-aliasing (or moral equivalent). No, that's not going to change before Python 3000 (if even then). All Python object structs conceptually extend the PyObject struct, including (but not limited to) object structs conceptually extending the PyVarObject struct (which in turn conceptually extends the PyObject struct). This is uniquitous in the core source code, and in all 3rd-party extension modules defin
[ python-Feature Requests-1474577 ] feature requests for logging lib
Feature Requests item #1474577, was opened at 2006-04-22 02:50
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&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: Invalid
Priority: 5
Submitted By: blaize rhodes (blaize)
Assigned to: Vinay Sajip (vsajip)
Summary: feature requests for logging lib
Initial Comment:
The logger module interface is a bit broken, I reckon.
My problems specifically are:
i) It's hard to get access to the LogRecord classes
for customization.
ii) the semantics of the debug, log, info, etc calls
is a bit strange/confusing...
Here are my proposed fixes:
a) Add a method
Logger.setLogRecordClass( myLogRecordSubClass )
which sets the class that is instantiated in the
makeRecord() fn/method (yes there are two of them).
This would make customizing the LogRecord easier...
Otherwise (I believe) in order to subclass the
LogRecord you also have to overload the Logger and
possibly the root makeRecord() function as well? This
bloke's writen up his approach to this (it's doable but
not as nice as it should be).
http://qix.it/~ludoo/archive/2004/05/python_logging_customization.html
Another problem is that LogRecords are instantiated in
Logger._log so it's difficult to customize __init__
behaviour for the LogRecord (and I argue that this is a
useful thing)..
b) A second problem is that the semantics of the log,
info, debug, etc fns is a bit broken. Currently the
defn looks like this:
def debug(self, msg, *args, **kwargs):
this suggests to me that a call like this is OK...
logger.debug("here we go %(foo)s", foo = 'bar')
but it's not. This is discussed further here...
http://groups.google.com.au/group/comp.lang.python/browse_thread/thread/322919fcac0113ec/98ceaf6fc0c56881?lnk=st&q=python+logging+keywords&rnum=1#98ceaf6fc0c56881
Instead kwargs are used for customizing the behaviour
of the debug method (e.g. exc_info, and extra). This
seems i) a bit incongrous with its definition and
therefore confusing, and ii) a bit of a hack (it's not
completely insane though when you think about what's
happening under the hood). Instead I propose using a
couple of calls along the lines of printf/fprintf. In
my world we'd have a simple printf-style function...
def debug(self, msg, *args):
and a more complex, more easily customizable
fprintf-style one
def x_debug(self, log_record, msg, *args):
In these calls *args is a valid argument for the string
formatting operator %, either a tuple of the right
length or a dictionary. Any customization of the
behaviour of the system can be done (using keyword args
if you wish) in the log_record initializer (an example
will follow).
(Having said that perhaps we can check whether the
first arg to the new simple debug() is a logrecord and
if it is call the (hidden) extended version - that's
more pythonic I imagine)
c) This is not so much a feature request but a
motivating mode of operation that I'd like to be able
to use...
Currently you can set up log filters. What you can
filter is largely based on what information appears in
the log record. It'd be nice to filter messages based
on metadata that you add at log time (i.e. in the
logger.debug(...) method). Currently it's quite
painfull to set this up. This is because we can't
customize the initialization of the log_record. The
call structure in ii) above allows us to setup nice
filtering mechanisms
eg..
class GUIFilter:
"A filter that only lets messges with gui tags
through."""
def filter(self, log_record):
return hasattr(log_record, 'gui')
# set up a log, and a handler...
log = logging.getLogger(..)
file_handler = FileHandler(..)
log.addHandler(file_handler)
gui_msg_bar_handler = StreamHandler(..)
log.addHandler(gui_msg_bar_handler)
gui_msg_bar_handler.addFilter(GUIFilter())
# msg only goes to the file_handler
log.debug("here we go %s", "here's an arg")
# msg goes to the file_handler and to the gui_handler.
log.x_debug(LogRecord(gui=True), "what you just tried
to do didn't work %s", "fool")
Change a) could be made with no backward compatability
problems (I can see), change b) could be made without
probs if you didn't overload the existing logging
methods with the new ones, and then deprecate the
existing ones (though what you'd call the new fns I
don't know).
That said I quite like the logger lib and I use it.
It's a lot better than anything I would have thought up.
cheers
blaize
--
>Comment By: SourceForge Robot (sf-robot)
Date: 2006-08-04 19:20
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system.
[ python-Feature Requests-1534942 ] Print identical floats consistently
Feature Requests item #1534942, was opened at 2006-08-05 06:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1534942&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Marc W. Abel (gihon) Assigned to: Nobody/Anonymous (nobody) Summary: Print identical floats consistently Initial Comment: Hello again and thank you, This is a rewrite of now-closed bug #1534769. As you know, >>> print .1 >>> print (.1,) give different results because the __str__ call from print becomes a __repr__ call on the tuple, and it stays a __repr__ beneath that point in any recursion. >From the previous discussion, we need behavior like this so that strings are quoted inside tuples. I suggest that print use a third builtin that is neither __str__ nor __repr__. The name isn't important, but suppose we call it __strep__ in this feature request. __strep__ would pass __strep__ down in the recursion, printing floats with __str__ and everything else with __repr__. This would then >>> print .1and >>> print (.1,) with the same precision. Marc -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1534942&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1534769 ] Identical floats print inconsistently
Bugs item #1534769, was opened at 2006-08-04 20:07
Message generated for change (Comment added) made by gihon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534769&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: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Marc W. Abel (gihon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Identical floats print inconsistently
Initial Comment:
Hi, and thank you.
Many bugs relating to this have been submitted by
others over a period of years, and these have generally
been closed with "not a bug" responses. I'll do my
best to explain the problem clearly enough.
The following session prints a single variable three
ways, with two different results:
---
[EMAIL PROTECTED] current]$ python
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> a = round(1./7, 3)
>>> print a
0.143
>>> print (a,)
(0.14299,)
>>> print (a,)[0]
0.143
>>>
---
I'm fully informed about IEEE floating point
representations in binary, but the limitations of data
type are not causing the difference in output. The
interpreter is using different rules to print this
float, depending on whether it's a straight float or
part of some other structure (in this example, a tuple).
Once the interpreter recurses to a depth where it's
clearly going to print a float, whatever rule is
selected needs to be consistently applied. This means
calling the same string formatting code with the same
inputs.
Marc
--
>Comment By: Marc W. Abel (gihon)
Date: 2006-08-05 06:24
Message:
Logged In: YES
user_id=789149
Hi Tim and Georg,
Thanks for your kind replies. I've followed up with feature
request 1534942, suggesting that print pass down __strep__,
which passes itself down. __strep__ prints floats with
__str__ and everything else with __rep__.
Enjoy the weekend! I'll be writing a ray tracer
Marc
--
Comment By: Tim Peters (tim_one)
Date: 2006-08-04 21:24
Message:
Logged In: YES
user_id=31435
gbrandl is correct that the differences here are entirely
due to the difference between float's __repr__ and __str__
methods. The reasons they /are/ different for floats are
explained in the Tutorial's appendix on floating-point issues.
It may be considered unfortunate that tuple.__repr__ is the
same as tuple.__str__, and that both "pass repr down" to
containees, but the reason for that has to do with the
difference between str.__repr__ and str.__str__. If
str(tuple) "passed str down" to containees, then, e.g.,
print ("a, bc", "de f,", "gh), i")
would display the incomprehensibly confused:
(a, bc, de f,, gh), i)
IOW, it's actually the difference in what string types do
that /drives/ the general decision that c.__str__ is the
same as c.__repr__ for all objects `c` of container types,
and that both "pass repr down" to containees.
Alas, that's not always what people using strings want
either :-)
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-04 20:14
Message:
Logged In: YES
user_id=849994
Sorry, but this is another "not a bug".
"print tuple" invokes tuple.__repr__() (because there is no
separate __str__) which invokes repr(item) on each tuple
item, while "print item" invokes str(item). For floats, this
distinction results in a different rounding precision.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534769&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
