[ python-Bugs-1675967 ] Python2.5 can't read a (complex) pickle build by python2.4
Bugs item #1675967, was opened at 2007-03-07 19:16 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1675967group_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 Private: No Submitted By: Michael Vogt (mvo) Assigned to: Nobody/Anonymous (nobody) Summary: Python2.5 can't read a (complex) pickle build by python2.4 Initial Comment: Part of gnome-app-install in ubuntu is a pickle data structure cache. If I create this pickle with python 2.4 and read it later with 2.5. I get the following error: $ python2.5 -c 'import pickle; pickle.load(open(/var/cache/app-install/menu.p))' /usr/lib/python2.5/pickle.py:1124: DeprecationWarning: The sre module is deprecated, please import re. __import__(module) Traceback (most recent call last): File string, line 1, in module File /usr/lib/python2.5/pickle.py, line 1370, in load return Unpickler(file).load() File /usr/lib/python2.5/pickle.py, line 858, in load dispatch[key](self) File /usr/lib/python2.5/pickle.py, line 1090, in load_global klass = self.find_class(module, name) File /usr/lib/python2.5/pickle.py, line 1126, in find_class klass = getattr(mod, name) AttributeError: 'module' object has no attribute '_compile' With: $ python2.4 -c 'import pickle; pickle.load(open(/var/cache/app-install/menu.p))' [EMAIL PROTECTED] ~ $ It loads just fine. The test pickle can be found here: http://people.ubuntu.com/~mvo/gnome-app-install/menu.p.gz Cheers, Michael -- Comment By: Žiga Seilnacht (zseil) Date: 2007-03-11 16:40 Message: Logged In: YES user_id=1326842 Originator: NO Attaching the patch with a test here. Unpickling old patterns with this patch works, but it still issues a DeprecationWarning. The test itself is a bit obscure, but the other option is to add a binary file to the test suite. File Added: sre_pickle_compatibility.diff -- Comment By: Žiga Seilnacht (zseil) Date: 2007-03-07 20:43 Message: Logged In: YES user_id=1326842 Originator: NO This happens because of SRE_Pattern objects in jour pickle. The sre module was renamed to re in Python 2.5, but the old pickles still expect the _compile function in sre module. I posted the patch here: http://freeweb.siol.net/chollus/ Could you try if it fixes the problem for you and in that case, attach it to this report? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1675967group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results
Bugs item #1678380, was opened at 2007-03-11 17:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678380group_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 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type help, copyright, credits or license for more information. from math import atan2; x = -0. y = 0. print atan2(y, -1.) 3.14159265359 But: exec(from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)) -3.14159265359 A simpler example: x, y = -0., 0. x, y (-0.0, -0.0) id(x) == id(y) True But: x = -0. y = 0. x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678380group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678411 ] StringIO / cStringIO inconsistency with unicode
Bugs item #1678411, was opened at 2007-03-11 18:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678411group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO / cStringIO inconsistency with unicode Initial Comment: When trying to write unicode strings into a StringIO.StringIO() or a cStringIO.StringIO() file, different things occur. (This causes a failing test in the mako project if cStringIO is not available.) Compare the following with StringIO or with cStringIO: f = StringIO() f.write(\xC0) f.write(uhello) print f.getvalue() With cStringIO, unicode strings are immediately encoded as ascii and the getvalue() returns '\xC0hello'. With StringIO, on the other hand, the getvalue() crashes in a ''.join() trying to convert 'xC0' to unicode. Normal file() objects follow the same behavior as cStringIO, so my guess is that StringIO.py is wrong here. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678411group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678411 ] StringIO / cStringIO inconsistency with unicode
Bugs item #1678411, was opened at 2007-03-11 19:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678411group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO / cStringIO inconsistency with unicode Initial Comment: When trying to write unicode strings into a StringIO.StringIO() or a cStringIO.StringIO() file, different things occur. (This causes a failing test in the mako project if cStringIO is not available.) Compare the following with StringIO or with cStringIO: f = StringIO() f.write(\xC0) f.write(uhello) print f.getvalue() With cStringIO, unicode strings are immediately encoded as ascii and the getvalue() returns '\xC0hello'. With StringIO, on the other hand, the getvalue() crashes in a ''.join() trying to convert 'xC0' to unicode. Normal file() objects follow the same behavior as cStringIO, so my guess is that StringIO.py is wrong here. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-11 19:31 Message: Logged In: YES user_id=21627 Originator: NO It's intentional that they behave differently. StringIO supports Unicode strings, cStringIO doesn't. This means that you can build up a large Unicode string with StringIO, but not with cStringIO. What should happen when you mix them is debatable. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678411group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results
Bugs item #1678380, was opened at 2007-03-11 18:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678380group_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: Pending Resolution: Wont Fix Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type help, copyright, credits or license for more information. from math import atan2; x = -0. y = 0. print atan2(y, -1.) 3.14159265359 But: exec(from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)) -3.14159265359 A simpler example: x, y = -0., 0. x, y (-0.0, -0.0) id(x) == id(y) True But: x = -0. y = 0. x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-11 19:35 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug, at least not one that will be fixed. Details of the floating-point can vary across platforms, and they may behave in suprising ways in various contexts. Users shouldn't rely on Python differentiating between -0 and +0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678380group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1516995 ] test_logging fails with reference count-checking enabled
Bugs item #1516995, was opened at 2006-07-04 14:34 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1516995group_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: Fixed Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Vinay Sajip (vsajip) Summary: test_logging fails with reference count-checking enabled Initial Comment: When running from the following, test_logging fails: ./python Lib/test/regrtest.py -R :: test_logging. Here's the traceback: test test_logging crashed -- type 'exceptions.KeyError': logging.StreamHandler instance at 0xb7aaebcc Traceback (most recent call last): File Lib/test/regrtest.py, line 554, in runtest_inner dash_R(the_module, test, indirect_test, huntrleaks) File Lib/test/regrtest.py, line 673, in dash_R run_the_test() File Lib/test/regrtest.py, line 660, in run_the_test indirect_test() File /home/collin/src/python/Lib/test/test_support.py, line 299, in inner return func(*args, **kwds) File /home/collin/src/python/Lib/test/test_logging.py, line 677, in test_main test_main_inner() File /home/collin/src/python/Lib/test/test_logging.py, line 640, in test_main_inner globals()['test%d' % t]() File /home/collin/src/python/Lib/test/test_logging.py, line 347, in test2 sh.close() File /home/collin/src/python/Lib/logging/__init__.py, line 687, in close del _handlers[self] KeyError: logging.StreamHandler instance at 0xb7aaebcc This problem does not occur when run without reference count-checking. System info: Python SVN r47224 Linux 2.6.13 x86 -- Comment By: Vinay Sajip (vsajip) Date: 2007-03-11 18:39 Message: Logged In: YES user_id=308438 Originator: NO Fix checked into trunk and release25-maint, so closing this item. -- Comment By: Collin Winter (collinwinter) Date: 2007-03-11 05:53 Message: Logged In: YES user_id=1344176 Originator: YES Adding those lines does indeed suppress the exception. I'm not convinced it eliminates the problem, though, since adding t = 2 after for t in range(1,6): in test_main_inner() will still cause test2() to raise KeyError() (with the same traceback as before), even with your patch. I've tried this same approach for all tests (0-5) and test2() is the only one to exhibit this behaviour. That said, I'm very happy to have test_logging not fail under regrtest -R anymore : ) I would apply your solution to both trunk/ and release25-maint/, if only to keep the number of buildbot false alarms to a minimum. Thanks, Vinay! -- Comment By: Vinay Sajip (vsajip) Date: 2007-03-11 00:58 Message: Logged In: YES user_id=308438 Originator: NO Thanks for the info. test2() is a little sensitive because it makes assumptions about the state of handlers attached to the root logger. test4() and test5() do some slightly dodgy manipulation of the internal handler list maintained by the module. I played around with the assumption that test5() is the culprit (as it's the last test run), and found that adding the lines hdlr = logging.getLogger().handlers[0] logging.getLogger().handlers.remove(hdlr) in test5(), just after the line os.remove(fn) causes the error not to occur, and the test passes successfully. Please try this on your system and re-run the tests, and if you can confirm that this change works for you, I can check it in. (I propose to only check it into trunk, and not into release25-maint or other branches - what do you think?) -- Comment By: Collin Winter (collinwinter) Date: 2007-03-10 20:36 Message: Logged In: YES user_id=1344176 Originator: YES Vinay: I've been able to gather a little more information. The problem occurs during the second run-through of the test suite; that is, it runs once, then -R :: kicks in and starts to run the test again, which is when the exception occurs. From what I can tell from poking around test2(), something is removing the sh handler from logging._handlers prematurely (its id() matches that displayed in the KeyError traceback). More poking around: -R :: doesn't really enter into it. Modifying test_main_inner() to run test2() more than once (in isolation or after other tests) will trigger this, too. On the second run, sh.close() raises a KeyError. -- Comment By: Vinay Sajip (vsajip) Date: 2007-03-10 17:25 Message: Logged In: YES user_id=308438 Originator: NO Hi Collin, I'm sorry to be
[ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc
Bugs item #780354, was opened at 2003-07-30 12:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=780354group_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.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David M. Grimes (dmgrime) Assigned to: Facundo Batista (facundobatista) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return quot;realquot; file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: quot;quot;quot; The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. quot;quot;quot; I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? -- Comment By: Skip Montanaro (montanaro) Date: 2007-03-11 13:45 Message: Logged In: YES user_id=44345 Originator: NO I'm not going to get to this. It may well be obsolete now anyway. Facundo, I'm assigning to you simply because you are diving into the timeout code right now. Maybe you can make a more informed decision. --Skip -- Comment By: David M. Grimes (dmgrime) Date: 2003-08-04 09:34 Message: Logged In: YES user_id=699265 Thanks Skip. I see that the ripple effect here is enormous (not surprising, given that socket is used by many standard modules). As for #3 - I understand you can use marshal.dumps() and then sock.sendall() to achieve the write side of a socket-based marshalling transaction, but for a long- lived connection, marshal.load() on the .makefile()'d file of the read-side provided a very nice message-boundary mechanism, i.e. - marshal was the quot;protocolquot; on the wire... Obviously (I've already done this in my application) I can just use a thin length header on the wire, but it was just very nice that marshal accomplished this by itself. I can also (since my platform scope is known, controlled, and limited) create a socket.py local to my application which is simply (I don't use getfqdn()): from _socket import * And leave everything else as-is. Again, I appreciate the attention and effort - I think the ramifications of eliminating the quot;native Cquot; implementation which previously backed .makefile() (where supported) are more than just the impact on marshal - I see potential performance loss for things which rely on it. In any event, generic object support for marshal.load() and .dump() would be great! Thanks again, Dave. -- Comment By: Skip Montanaro (montanaro) Date: 2003-08-04 08:53 Message: Logged In: YES user_id=44345 The original socket.makefile dup()s the socket to create a new file descriptor. If you have a timeout set on the original socket the new file descriptor loses this property. This was a big problem for the various modules which sit atop socket (httplib, etc) because they generally all just call s.makefile() and then treat the connected socket as a file. These are precisely the modules/classes which benefit most from socket timeouts. Note also that the current Unix implementation is what Windows (and any other platforms without a dup() system call) use to emulate makefile(). In the long run, I see a few other possibilities. Note that I haven't considered the first two in any detail. I'm in the midst of working on the third. 1. Add timeout functionality to the various higher-level modules such as httplib. Once they call s.makefile() they could propagate their current timeout to the new file object. Of course, this means file objects need to be able to timeout
[ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc
Bugs item #780354, was opened at 2003-07-30 12:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=780354group_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.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David M. Grimes (dmgrime) Assigned to: Nobody/Anonymous (nobody) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return quot;realquot; file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: quot;quot;quot; The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. quot;quot;quot; I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? -- Comment By: Skip Montanaro (montanaro) Date: 2007-03-11 13:45 Message: Logged In: YES user_id=44345 Originator: NO Crap. Wrong socket.makefile bug report. -- Comment By: Skip Montanaro (montanaro) Date: 2007-03-11 13:45 Message: Logged In: YES user_id=44345 Originator: NO I'm not going to get to this. It may well be obsolete now anyway. Facundo, I'm assigning to you simply because you are diving into the timeout code right now. Maybe you can make a more informed decision. --Skip -- Comment By: David M. Grimes (dmgrime) Date: 2003-08-04 09:34 Message: Logged In: YES user_id=699265 Thanks Skip. I see that the ripple effect here is enormous (not surprising, given that socket is used by many standard modules). As for #3 - I understand you can use marshal.dumps() and then sock.sendall() to achieve the write side of a socket-based marshalling transaction, but for a long- lived connection, marshal.load() on the .makefile()'d file of the read-side provided a very nice message-boundary mechanism, i.e. - marshal was the quot;protocolquot; on the wire... Obviously (I've already done this in my application) I can just use a thin length header on the wire, but it was just very nice that marshal accomplished this by itself. I can also (since my platform scope is known, controlled, and limited) create a socket.py local to my application which is simply (I don't use getfqdn()): from _socket import * And leave everything else as-is. Again, I appreciate the attention and effort - I think the ramifications of eliminating the quot;native Cquot; implementation which previously backed .makefile() (where supported) are more than just the impact on marshal - I see potential performance loss for things which rely on it. In any event, generic object support for marshal.load() and .dump() would be great! Thanks again, Dave. -- Comment By: Skip Montanaro (montanaro) Date: 2003-08-04 08:53 Message: Logged In: YES user_id=44345 The original socket.makefile dup()s the socket to create a new file descriptor. If you have a timeout set on the original socket the new file descriptor loses this property. This was a big problem for the various modules which sit atop socket (httplib, etc) because they generally all just call s.makefile() and then treat the connected socket as a file. These are precisely the modules/classes which benefit most from socket timeouts. Note also that the current Unix implementation is what Windows (and any other platforms without a dup() system call) use to emulate makefile(). In the long run, I see a few other possibilities. Note that I haven't considered the first two in any detail. I'm in the midst of working on the third. 1. Add timeout
[ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results
Bugs item #1678380, was opened at 2007-03-11 17:16 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678380group_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: Wont Fix Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type help, copyright, credits or license for more information. from math import atan2; x = -0. y = 0. print atan2(y, -1.) 3.14159265359 But: exec(from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)) -3.14159265359 A simpler example: x, y = -0., 0. x, y (-0.0, -0.0) id(x) == id(y) True But: x = -0. y = 0. x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. -- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 19:21 Message: Logged In: YES user_id=703403 Originator: YES May I beg for reconsideration. Is the following really considered acceptable? x = -0.; atan2(0., -1) -3.1415926535897931 x = -(0.); atan2(0., -1) 3.1415926535897931 atan2(0., -1) 3.1415926535897931 A single x = -0. at the start of a script can have side effects several hundred lines later, even when the variable x is never referred to again. I guess the advice should be: To avoid surprises, -0. should never appear in any script. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-11 18:35 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug, at least not one that will be fixed. Details of the floating-point can vary across platforms, and they may behave in suprising ways in various contexts. Users shouldn't rely on Python differentiating between -0 and +0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678380group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results
Bugs item #1678380, was opened at 2007-03-11 14:16 Message generated for change (Comment added) made by gagenellina You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678380group_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: Wont Fix Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type help, copyright, credits or license for more information. from math import atan2; x = -0. y = 0. print atan2(y, -1.) 3.14159265359 But: exec(from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)) -3.14159265359 A simpler example: x, y = -0., 0. x, y (-0.0, -0.0) id(x) == id(y) True But: x = -0. y = 0. x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-03-11 17:10 Message: Logged In: YES user_id=479790 Originator: NO It appears to be a problem in the way compile.c handles literals. See http://mail.python.org/pipermail/python-list/2007-March/430302.html -- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 16:21 Message: Logged In: YES user_id=703403 Originator: YES May I beg for reconsideration. Is the following really considered acceptable? x = -0.; atan2(0., -1) -3.1415926535897931 x = -(0.); atan2(0., -1) 3.1415926535897931 atan2(0., -1) 3.1415926535897931 A single x = -0. at the start of a script can have side effects several hundred lines later, even when the variable x is never referred to again. I guess the advice should be: To avoid surprises, -0. should never appear in any script. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-11 15:35 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug, at least not one that will be fixed. Details of the floating-point can vary across platforms, and they may behave in suprising ways in various contexts. Users shouldn't rely on Python differentiating between -0 and +0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678380group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1245224 ] Time module is missing inverse of gmtime()
Bugs item #1245224, was opened at 2005-07-26 15:04 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1245224group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Time module is missing inverse of gmtime() Initial Comment: The time module has the inverse function of localtime() in its mktime () function, but is missing the inverse of gmtime(). After a bit of searching, I found the calendar module function timegm (), which claims to be the inverse of gmtime(). Is there any reason the time module shouldn't provide the inverse of gmtime()? It's obviously needed, as the calendar module has a version for its own use since the time module doesn't provide one. -- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 22:13 Message: Logged In: YES user_id=226443 Originator: NO See patch #1667546 for an implementation of timegm. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1245224group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1645148 ] MIME renderer: wrong header line break with long subject?
Bugs item #1645148, was opened at 2007-01-26 05:04
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1645148group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: MIME renderer: wrong header line break with long subject?
Initial Comment:
from email.MIMEText import MIMEText
o=MIMEText('hello')
o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4
5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 '
o.as_string()
'Content-Type: text/plain; charset=us-ascii\nMIME-Version: 1.0\nContent-Transf
er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8
9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\
nhello'
The '6 7 8\n\t9 1 2 3' clashes together to 6 7 89 1 2 3
without space between 89 in usual mail readers.
Is this an error and should be :
'6 7 8 \n\t9 1 2 3'
?
as there is also the space preserved in
'6 7 8 9 \n\nhello'
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-11 17:16
Message:
Logged In: YES
user_id=12800
Originator: NO
Tokio, I'm not so sure about adding that extra space. I tested all the
mail readers at my disposal on Linux and OSX. I don't have any Windows
machines available so I couldn't test Outlook or OE. (If you have them,
please indicate what they do in a comment here!) Here's what I found:
OSX:
Mail.app 2.1.1 -- the extra space produces an extra space between the 8
and 9 both in the message summary and in the Subject header in the preview
pane. The no extra space message looks fine.
Thunderbird 1.5.0.10 -- The extra space message produces an extra space
in the message summary, while the no extra space message looks fine here.
But the weird thing is that in both the extra space and non-extra space
cases, the Subject header in the preview pane both have extra spaces. It
looks to me like the leading tab is being inserted into the Subject header
view.
Entourage 11.3.3 -- The extra space shows up in both the summary and
preview panes but only in the message with the extra space
Linux
Thunderbird 1.5.0.10 -- both messages get a tab between the 8 and 9 in
both the summary and preview pane. This is for both the extra space
message and the no-extra space message; afaict, there's no difference
between the two and this is definitely a difference between the Linux
version and the OSX version of the same mail reader.
Evolution 2.9.92 -- the extra space message produces an extra space
between the 8 and 9 in both the summary and preview panes. The no-extra
space message looks fine.
Sylpheed Claws 2.6.0 -- the extra space message produces an extra space
between the 8 and 9 in both the summary and preview panes. The no-extra
space message looks file.
So anyway, afaict, the extra space is not appropriate for any of the
non-Windows mail readers.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1645148group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1645148 ] MIME renderer: wrong header line break with long subject?
Bugs item #1645148, was opened at 2007-01-26 05:04
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1645148group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: MIME renderer: wrong header line break with long subject?
Initial Comment:
from email.MIMEText import MIMEText
o=MIMEText('hello')
o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4
5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 '
o.as_string()
'Content-Type: text/plain; charset=us-ascii\nMIME-Version: 1.0\nContent-Transf
er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8
9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\
nhello'
The '6 7 8\n\t9 1 2 3' clashes together to 6 7 89 1 2 3
without space between 89 in usual mail readers.
Is this an error and should be :
'6 7 8 \n\t9 1 2 3'
?
as there is also the space preserved in
'6 7 8 9 \n\nhello'
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-11 17:17
Message:
Logged In: YES
user_id=12800
Originator: NO
Whoops, this wasn't supposed to be a response to Tokio, but instead the
OP.
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-11 17:16
Message:
Logged In: YES
user_id=12800
Originator: NO
Tokio, I'm not so sure about adding that extra space. I tested all the
mail readers at my disposal on Linux and OSX. I don't have any Windows
machines available so I couldn't test Outlook or OE. (If you have them,
please indicate what they do in a comment here!) Here's what I found:
OSX:
Mail.app 2.1.1 -- the extra space produces an extra space between the 8
and 9 both in the message summary and in the Subject header in the preview
pane. The no extra space message looks fine.
Thunderbird 1.5.0.10 -- The extra space message produces an extra space
in the message summary, while the no extra space message looks fine here.
But the weird thing is that in both the extra space and non-extra space
cases, the Subject header in the preview pane both have extra spaces. It
looks to me like the leading tab is being inserted into the Subject header
view.
Entourage 11.3.3 -- The extra space shows up in both the summary and
preview panes but only in the message with the extra space
Linux
Thunderbird 1.5.0.10 -- both messages get a tab between the 8 and 9 in
both the summary and preview pane. This is for both the extra space
message and the no-extra space message; afaict, there's no difference
between the two and this is definitely a difference between the Linux
version and the OSX version of the same mail reader.
Evolution 2.9.92 -- the extra space message produces an extra space
between the 8 and 9 in both the summary and preview panes. The no-extra
space message looks fine.
Sylpheed Claws 2.6.0 -- the extra space message produces an extra space
between the 8 and 9 in both the summary and preview panes. The no-extra
space message looks file.
So anyway, afaict, the extra space is not appropriate for any of the
non-Windows mail readers.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1645148group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-971965 ] urllib2 raises exception with non-200 success codes.
Bugs item #971965, was opened at 2004-06-13 13:00
Message generated for change (Comment added) made by jbelmonte
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=971965group_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.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ed Watkeys (edw)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 raises exception with non-200 success codes.
Initial Comment:
If a server returns a code other than 200, specifically 201
(Created), urllib2.urlopen will raise an HTTPError exception. I ran
into this while implementing an Atom API client, which solicits 201
responses from the server when submitting a blog post.
File /usr/local/lib/python2.3/urllib2.py, line 129, in urlopen
return _opener.open(url, data)
File /usr/local/lib/python2.3/urllib2.py, line 326, in open
'_open', req)
File /usr/local/lib/python2.3/urllib2.py, line 306, in _call_chain
result = func(*args)
File /usr/local/lib/python2.3/urllib2.py, line 901, in http_open
return self.do_open(httplib.HTTP, req)
File /usr/local/lib/python2.3/urllib2.py, line 895, in do_open
return self.parent.error('http', req, fp, code, msg, hdrs)
File /usr/local/lib/python2.3/urllib2.py, line 352, in error
return self._call_chain(*args)
File /usr/local/lib/python2.3/urllib2.py, line 306, in _call_chain
result = func(*args)
File /usr/local/lib/python2.3/urllib2.py, line 412, in
http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 201: Created
--
Comment By: John Belmonte (jbelmonte)
Date: 2007-03-12 06:23
Message:
Logged In: YES
user_id=282299
Originator: NO
Fixing this issue is not maybe OK, it's the correct thing to do.
Having an HTTP success response raise an exception is faulty behavior, and
urllib2 users should not have to do silly things to work around it. It
really seems like the authors of urllib2 only understood about 10% of the
HTTP protocol.
--
Comment By: John J Lee (jjlee)
Date: 2005-05-20 05:05
Message:
Logged In: YES
user_id=261020
Before bug 912845 (CVS rev 1.69) added 206 to the list of
response codes considered successful by urllib2, I'd
assumed this would never be altered, for
backwards-compatibility reasons.
Note that this behaviour can be configured by module users,
since HTTPError exceptions support the urllib2 response
interface. This can be done by replacing
HTTPErrorProcessor, or by replacing HTTPDefaultErrorHandler,
or catching the exception manually.
But maybe since the 206 issue was considered a valid bug
fix, this is OK too.
If so, it would be best if the other 20x responses were also
considered at the same time.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=971965group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results
Bugs item #1678380, was opened at 2007-03-11 18:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678380group_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: Wont Fix Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type help, copyright, credits or license for more information. from math import atan2; x = -0. y = 0. print atan2(y, -1.) 3.14159265359 But: exec(from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)) -3.14159265359 A simpler example: x, y = -0., 0. x, y (-0.0, -0.0) id(x) == id(y) True But: x = -0. y = 0. x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-11 23:27 Message: Logged In: YES user_id=21627 Originator: NO marketdickinson, you should ask this question (is this really acceptable) on python-dev. I find it perfectly acceptable. No program should rely on -0 and +0 being two different things (and thus also not relying on atan2 giving two different results). -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-03-11 21:10 Message: Logged In: YES user_id=479790 Originator: NO It appears to be a problem in the way compile.c handles literals. See http://mail.python.org/pipermail/python-list/2007-March/430302.html -- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 20:21 Message: Logged In: YES user_id=703403 Originator: YES May I beg for reconsideration. Is the following really considered acceptable? x = -0.; atan2(0., -1) -3.1415926535897931 x = -(0.); atan2(0., -1) 3.1415926535897931 atan2(0., -1) 3.1415926535897931 A single x = -0. at the start of a script can have side effects several hundred lines later, even when the variable x is never referred to again. I guess the advice should be: To avoid surprises, -0. should never appear in any script. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-11 19:35 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug, at least not one that will be fixed. Details of the floating-point can vary across platforms, and they may behave in suprising ways in various contexts. Users shouldn't rely on Python differentiating between -0 and +0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678380group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678411 ] StringIO / cStringIO inconsistency with unicode
Bugs item #1678411, was opened at 2007-03-11 18:07 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678411group_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 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO / cStringIO inconsistency with unicode Initial Comment: When trying to write unicode strings into a StringIO.StringIO() or a cStringIO.StringIO() file, different things occur. (This causes a failing test in the mako project if cStringIO is not available.) Compare the following with StringIO or with cStringIO: f = StringIO() f.write(\xC0) f.write(uhello) print f.getvalue() With cStringIO, unicode strings are immediately encoded as ascii and the getvalue() returns '\xC0hello'. With StringIO, on the other hand, the getvalue() crashes in a ''.join() trying to convert 'xC0' to unicode. Normal file() objects follow the same behavior as cStringIO, so my guess is that StringIO.py is wrong here. -- Comment By: Armin Rigo (arigo) Date: 2007-03-12 00:04 Message: Logged In: YES user_id=4771 Originator: YES I missed the documentation, which already desribes this difference. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-11 18:31 Message: Logged In: YES user_id=21627 Originator: NO It's intentional that they behave differently. StringIO supports Unicode strings, cStringIO doesn't. This means that you can build up a large Unicode string with StringIO, but not with cStringIO. What should happen when you mix them is debatable. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678411group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-971965 ] urllib2 raises exception with non-200 success codes.
Bugs item #971965, was opened at 2004-06-13 05:00
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=971965group_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.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ed Watkeys (edw)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 raises exception with non-200 success codes.
Initial Comment:
If a server returns a code other than 200, specifically 201
(Created), urllib2.urlopen will raise an HTTPError exception. I ran
into this while implementing an Atom API client, which solicits 201
responses from the server when submitting a blog post.
File /usr/local/lib/python2.3/urllib2.py, line 129, in urlopen
return _opener.open(url, data)
File /usr/local/lib/python2.3/urllib2.py, line 326, in open
'_open', req)
File /usr/local/lib/python2.3/urllib2.py, line 306, in _call_chain
result = func(*args)
File /usr/local/lib/python2.3/urllib2.py, line 901, in http_open
return self.do_open(httplib.HTTP, req)
File /usr/local/lib/python2.3/urllib2.py, line 895, in do_open
return self.parent.error('http', req, fp, code, msg, hdrs)
File /usr/local/lib/python2.3/urllib2.py, line 352, in error
return self._call_chain(*args)
File /usr/local/lib/python2.3/urllib2.py, line 306, in _call_chain
result = func(*args)
File /usr/local/lib/python2.3/urllib2.py, line 412, in
http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 201: Created
--
Comment By: John J Lee (jjlee)
Date: 2007-03-12 00:11
Message:
Logged In: YES
user_id=261020
Originator: NO
Whether 206 and 201 are HTTP success responses is not the question at
hand. Given that the 206 behaviour was changed, I agree that other success
responses should also be considered (certainly seems a mistake that e.g.
203 was not added at the same time as 206), and indeed nobody has done
that. But I think backwards compatibility, the semantics of the various
response codes and of urllib2, and ease of understanding, are more
important than you seem to assume.
I don't see a patch. In what way exactly do you propose urllib2 should be
changed? Note that it's not completely obvious: e.g. a 201 received by a
plain-urllib2 client would be an erroneous server response, because urllib2
is designed only for retrieving URLs, and is not intended to be a generic
HTTP client. Also note that clients based on urllib2 that do support PUT,
such as the Atom client you refer to, can easily implement the modified 201
handling themselves. So on the face of it, the particular issue you raise
is a bug in that code, and not in urllib2.
Of course, your derogatory remarks about authors / bug-fixers won't
persuade anybody of anything, or get any work done.
--
Comment By: John Belmonte (jbelmonte)
Date: 2007-03-11 21:23
Message:
Logged In: YES
user_id=282299
Originator: NO
Fixing this issue is not maybe OK, it's the correct thing to do.
Having an HTTP success response raise an exception is faulty behavior, and
urllib2 users should not have to do silly things to work around it. It
really seems like the authors of urllib2 only understood about 10% of the
HTTP protocol.
--
Comment By: John J Lee (jjlee)
Date: 2005-05-19 21:05
Message:
Logged In: YES
user_id=261020
Before bug 912845 (CVS rev 1.69) added 206 to the list of
response codes considered successful by urllib2, I'd
assumed this would never be altered, for
backwards-compatibility reasons.
Note that this behaviour can be configured by module users,
since HTTPError exceptions support the urllib2 response
interface. This can be done by replacing
HTTPErrorProcessor, or by replacing HTTPDefaultErrorHandler,
or catching the exception manually.
But maybe since the 206 issue was considered a valid bug
fix, this is OK too.
If so, it would be best if the other 20x responses were also
considered at the same time.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=971965group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678647 ] Weird behavior Exception with unicode string
Bugs item #1678647, was opened at 2007-03-11 21:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678647group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Leandro Lucarella (llucax) Assigned to: M.-A. Lemburg (lemburg) Summary: Weird behavior Exception with unicode string Initial Comment: This simple python program: --- raise Exception(u'Muri\u00f3') --- prints: --- Traceback (most recent call last): File pylog.py, line 1, in ? raise Exception(u'Muri\u00f3') Exception --- While not using an unicode character, seems to work fine (even if using an unicode parameter): -- raise Exception(u'Murio') -- prints: --- Traceback (most recent call last): File pylog.py, line 1, in ? raise Exception(u'Murio') Exception: Murio --- This seems to break the logging module when calling logging.exception(u'Muri\u00f3'), for example. Tested in Python 2.4.4 and 2.5 (debian). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678647group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results
Bugs item #1678380, was opened at 2007-03-11 10:16 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678380group_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: Wont Fix Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 identified, with surprising results Initial Comment: The identification of -0.0 and 0.0 in scripts leads to some surprising results. In particular, code that behaves one way in the interpreter can behave differently in a script. For example: Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type help, copyright, credits or license for more information. from math import atan2; x = -0. y = 0. print atan2(y, -1.) 3.14159265359 But: exec(from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)) -3.14159265359 A simpler example: x, y = -0., 0. x, y (-0.0, -0.0) id(x) == id(y) True But: x = -0. y = 0. x, y (-0.0, 0.0) This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC. -- Comment By: Alex Martelli (aleax) Date: 2007-03-11 18:51 Message: Logged In: YES user_id=60314 Originator: NO Also see my patch 1678380 which fixes this bug (and checks for it in a new unittest). -- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 18:15 Message: Logged In: YES user_id=703403 Originator: YES I expressed myself badly. I apologise. This really isn't about +0. and -0. being different, or not. I'm perfectly comfortable with the idea that +0. and -0. may or may not be distinguishable on any given platform. The surprise is the other way around: two *identical* calls to atan(0., -1.) (or to repr(0.) for that matter) give *different* results, depending solely on whether a -0. literal has appeared earlier on in the code unit being compiled. So if the first float zero literal encountered in a source file just happens to be a -0. rather than a 0., the meaning of str(0.) later on suddenly becomes -0.0 rather than 0.0. I'd like to be able to rely on str(0.) meaning 0.0 without having to worry about whether there might be a -0. literal appearing in some faraway and otherwise completely irrelevant portion of the file. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-11 15:27 Message: Logged In: YES user_id=21627 Originator: NO marketdickinson, you should ask this question (is this really acceptable) on python-dev. I find it perfectly acceptable. No program should rely on -0 and +0 being two different things (and thus also not relying on atan2 giving two different results). -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-03-11 13:10 Message: Logged In: YES user_id=479790 Originator: NO It appears to be a problem in the way compile.c handles literals. See http://mail.python.org/pipermail/python-list/2007-March/430302.html -- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-11 12:21 Message: Logged In: YES user_id=703403 Originator: YES May I beg for reconsideration. Is the following really considered acceptable? x = -0.; atan2(0., -1) -3.1415926535897931 x = -(0.); atan2(0., -1) 3.1415926535897931 atan2(0., -1) 3.1415926535897931 A single x = -0. at the start of a script can have side effects several hundred lines later, even when the variable x is never referred to again. I guess the advice should be: To avoid surprises, -0. should never appear in any script. -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-11 11:35 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug, at least not one that will be fixed. Details of the floating-point can vary across platforms, and they may behave in suprising ways in various contexts. Users shouldn't rely on Python differentiating between -0 and +0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678380group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678710 ] dead link in tkinter documentation
Bugs item #1678710, was opened at 2007-03-11 20:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678710group_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: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Collver (bencollver) Assigned to: Nobody/Anonymous (nobody) Summary: dead link in tkinter documentation Initial Comment: On the following page, there is a dead link. http://www.python.org/doc/2.3.5/lib/node642.html The dead link is to the following URL. http://www.python.org/doc/2.3.5/lib/classes/ClassPacker.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678710group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678647 ] Weird behavior Exception with unicode string
Bugs item #1678647, was opened at 2007-03-12 09:20 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678647group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Leandro Lucarella (llucax) Assigned to: M.-A. Lemburg (lemburg) Summary: Weird behavior Exception with unicode string Initial Comment: This simple python program: --- raise Exception(u'Muri\u00f3') --- prints: --- Traceback (most recent call last): File pylog.py, line 1, in ? raise Exception(u'Muri\u00f3') Exception --- While not using an unicode character, seems to work fine (even if using an unicode parameter): -- raise Exception(u'Murio') -- prints: --- Traceback (most recent call last): File pylog.py, line 1, in ? raise Exception(u'Murio') Exception: Murio --- This seems to break the logging module when calling logging.exception(u'Muri\u00f3'), for example. Tested in Python 2.4.4 and 2.5 (debian). -- Comment By: Hye-Shik Chang (perky) Date: 2007-03-12 13:43 Message: Logged In: YES user_id=55188 Originator: NO That's from line 1216-1230 of Python/pythonrun.c as in trunk. It tries PyObject_Str(exception) and skips printing line terminator when it failed. And the behavior came from r8084 (http://svn.python.org/view/python/trunk/Python/pythonrun.c?rev=8084r1=8070r2=8084). Hmm. I think it should put a LF even if the conversion failed. (encoding the unicode with ignore or replace would make some confusion and putting it in PyObject_Repr() makes inconsistency.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1678647group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
