[ python-Bugs-1528074 ] difflib.SequenceMatcher.find_longest_match() wrong result
Bugs item #1528074, was opened at 2006-07-25 03:59 Message generated for change (Comment added) made by rtvd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Machin (sjmachin) Assigned to: Tim Peters (tim_one) Summary: difflib.SequenceMatcher.find_longest_match() wrong result Initial Comment: A short example script is attached. Two strings, each 500 bytes long. Longest match is the first 32 bytes of each string. Result produced is a 10-byte match later in the string. If one byte is chopped off the end of each string (len now 499 each), the correct result is produced. Other observations, none of which may be relevant: 1. Problem may be in the heuristic for "popular" elements in the __chain_b method. In this particular example, the character '0' (which has frequency of 6 in the "b" string) is not "popular" with a len of 500 but is "popular" with a len of 499. 2. '0' is the last byte of the correct longest match. 3. The correct longest match is at the start of the each of the strings. 4. Disabling the "popular" heuristic (like below) appears to make the problem go away: if 0: # if n >= 200 and len(indices) * 100 > n: populardict[elt] = 1 del indices[:] else: indices.append(i) 5. The callable self.isbpopular is created but appears to be unused. 6. The determination of "popular" doesn't accord with the comments, which say 1%. However with len==500, takes 6 to be popular. -- Comment By: Denys Rtveliashvili (rtvd) Date: 2007-03-11 18:29 Message: Logged In: YES user_id=1416496 Originator: NO I have sent a testcase for this bug into the SourceForge. The ID is #1678339. Also I have submitted a fix for this bug (ID #1678345), but the fix reduces the performance significantly. -- Comment By: Denys Rtveliashvili (rtvd) Date: 2007-03-10 20:24 Message: Logged In: YES user_id=1416496 Originator: NO The quick test for this bug is: for i in xrange(190, 200): text1 = "a" + "b"*i text2 = "b"*i + "c" m = difflib.SequenceMatcher(None, text1, text2) (aptr,bptr,l) = m.find_longest_match(0, len(text1), 0, len(text2)) print "i:", i, " l:", l, " aptr:", aptr, " bptr:", bptr assert l == i The assertion will fail when i==199 (the length of the texts will be 200). And yes, the bug is clearly "populardict"-related. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528074&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ 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=detail&atid=105470&aid=1675967&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
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 "", line 1, in
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=detail&atid=105470&aid=1675967&group_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=detail&atid=105470&aid=1678380&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
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=detail&atid=105470&aid=1678380&group_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=detail&atid=105470&aid=1678411&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
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(u"hello")
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=detail&atid=105470&aid=1678411&group_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=detail&atid=105470&aid=1678411&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
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(u"hello")
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=detail&atid=105470&aid=1678411&group_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=detail&atid=105470&aid=1678380&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: 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=detail&atid=105470&aid=1678380&group_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=detail&atid=105470&aid=1516995&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: 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 -- : 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: 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 so slow on this. For various reasons, I don't have a debug build of Python 2.5 :-
[ 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=detail&atid=105470&aid=780354&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.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 "real" 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: """ 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. """ 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 "protocol" 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 "native C" 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 (not obvious that this is generally possible
[ 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=detail&atid=105470&aid=780354&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.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 "real" 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: """ 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. """ 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 "protocol" 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 "native C" 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 mo
[ python-Bugs-882297 ] socket's makefile file object doesn't work with timeouts.
Bugs item #882297, was opened at 2004-01-22 12:36
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&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
Private: No
Submitted By: Jeremy Fincher (jemfinch)
>Assigned to: Facundo Batista (facundobatista)
Summary: socket's makefile file object doesn't work with timeouts.
Initial Comment:
Ok, here's what I did:
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.bind(('', 9009))
>>> s.listen(5)
>>> s.accept()
Now, I opened a second Python interpreter in which I
typed this:
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.connect(('localhost', 9009))
In the first interpreter I did this:
>>> s.accept()
(,
('127.0.0.1', 33059))
>>> s1 = _[0]
>>> s1.settimeout(3)
>>> fd = s1.makefile()
Then I tested that the timeout worked correctly. Still
in the first interpreter:
>>> fd.readline()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()
Now, while that was blocking, I did this in the second
interpreter:
>>> s.send('foo')
3
Which caused this in the first interpreter (as
expected, since I didn't send a newline):
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()
While that was blocking, I did this in the second
interpreter:
>>> s.send('bar\n')
4
Finally sending a newline. But lo and behold! In the
first interpreter I got this:
>>> fd.readline()
'bar\n'
Alas, my 'foo' has been lost!
Anyway, the documentation does explicitly state that
the socket should be in blocking mode, *implying* that
it does no buffering, but it doesn't say anything about
timeouts. Ideally, the file object would buffer enough
data until the readline could return meaningfully, but
failing that, the documentation should probably be
updated to mention that timeouts shouldn't be used with
readline on the returned file object.
--
>Comment By: Skip Montanaro (montanaro)
Date: 2007-03-11 13:46
Message:
Logged In: YES
user_id=44345
Originator: NO
Okay, this is the socket.makefile/timeout bug report. Sorry about the
previous blip.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 06:10
Message:
Logged In: YES
user_id=1188172
If this is a bug, it hasn't been fixed. I reproduced it here.
Assigning to Skip since he worked on "makefile" as it seems.
--
Comment By: John J Lee (jjlee)
Date: 2006-02-01 13:38
Message:
Logged In: YES
user_id=261020
I believe this was fixed in socket.py in rev 32056, closing
bug 707074.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&group_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 (Comment added) made by marketdickinson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&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: 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=detail&atid=105470&aid=1678380&group_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=detail&atid=105470&aid=1678380&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: 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=detail&atid=105470&aid=1678380&group_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=detail&atid=105470&aid=1245224&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 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=detail&atid=105470&aid=1245224&group_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=detail&atid=105470&aid=1645148&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
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=detail&atid=105470&aid=1645148&group_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=detail&atid=105470&aid=1645148&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
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=detail&atid=105470&aid=1645148&group_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=detail&atid=105470&aid=971965&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.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=detail&atid=105470&aid=971965&group_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=detail&atid=105470&aid=1678380&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: 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=detail&atid=105470&aid=1678380&group_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=detail&atid=105470&aid=1678411&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
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(u"hello")
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=detail&atid=105470&aid=1678411&group_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=detail&atid=105470&aid=971965&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.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=detail&atid=105470&aid=971965&group_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=detail&atid=105470&aid=1678647&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: 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=detail&atid=105470&aid=1678647&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-798274 ] absolute import patch breaks external users of test.regrtest
Bugs item #798274, was opened at 2003-08-31 17:39 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798274&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nicholas Riley (nriley) Assigned to: Nobody/Anonymous (nobody) Summary: absolute import patch breaks external users of test.regrtest Initial Comment: I've built a test system using Python's test.regrtest mechanism, and it worked very well under Python 2.2. In Python 2.3, the output looks like this: test_inttypes test_inttypes skipped -- No module named test_inttypes test_string test_unittest test_unittest skipped -- No module named test_unittest [...] I've tracked the problem down to a change made about a year ago. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ python/dist/src/Lib/test/regrtest.py.diff?r1=1.91&r2=1.92 test.regrtest is finding the modules, but is failing to import them because it is prepending 'test.' to the module names, in a mistaken assumption that all tests will be in a package named test. As it happened, I had my test modules inside a directory named 'test', and I tried making the directory a module and futzing with sys.path to get it to work, but now test.regrtest can't find the system implementation of test.test_support. I've also now got the problem of namespace pollution - the "test_string" above is Python's version, not my version with the same name. So, it appears non-Python users of test.regrtest are broken by this change in Python 2.3. I was pretty careful to make sure that I was doing something supported - the docstring for test.regrtest.main explicitly refers to non-Python test suite users - and ran into some weird cases like test.* not being installed on Mac OS X by default, but it worked very well otherwise. One potential solution would be that if 'testdir' is specified, test.regrtest.main() does not attempt to prepend 'test.' to the module names. This seems to match pretty well with the spirit of the documentation for that method. -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-11 21:10 Message: Logged In: YES user_id=1344176 Originator: NO regrtest's purpose is to test Python; third-party projects wishing to use regrtest in their own test suites would do well to customize it for their particular needs. -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:47 Message: Logged In: YES user_id=12800 I'm relinquishing assignment of this issue and moving it to Python 2.4. -- Comment By: Nicholas Riley (nriley) Date: 2003-09-17 18:53 Message: Logged In: YES user_id=34933 Thanks for the helpful response. Sorry I didn't get around to writing any documentation, but a patch is here: http://sourceforge.net/tracker/index.php? func=detail&aid=808210&group_id=5470&atid=305470 -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-09-01 23:54 Message: Logged In: YES user_id=12800 IIRC, this patch was necessary because some tests required absolute imports and we cannot mix relative and absolute imports in the test suite. IMO, regrtest's primary mission in life is to support Python's test suite and any other use is secondary (for example, it isn't documented in the standard library manual). OTOH, you might think about contributing a patch that allows regrtest to be used outside the Python test suite, but doesn't break the absolute import requirement while in the test suite. (You might also consider adding some standard lib documentation to your patch). The other problems you mention are inherent in Python's import machinery. If you have two packages named "test" on your sys.path, Python will not by default search them both for submodules. -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 12:51 Message: Logged In: YES user_id=80475 Barry, this was your change. Would you take a look at this bug report? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798274&group_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 (Comment added) made by marketdickinson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&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: 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-12 01: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 22: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 20: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 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=detail&atid=105470&aid=1678380&group_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=detail&atid=105470&aid=1678380&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: 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=detail&atid=105470&aid=1678380&group_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=detail&atid=105470&aid=1678380&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: 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:54
Message:
Logged In: YES
user_id=60314
Originator: NO
Oops,sorry, I meant patch 1678668 (copy-and-pasted the wrong ID:-).
Alex
--
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=detail&atid
[ python-Bugs-1629369 ] email._parseaddr AddrlistClass bug
Bugs item #1629369, was opened at 2007-01-06 07:31
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629369&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: Accepted
Priority: 5
Private: No
Submitted By: Tokio Kikuchi (tkikuchi)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email._parseaddr AddrlistClass bug
Initial Comment:
email._parseaddr AddrlistClass incorrectly parse multilined comment (display
name).
According to RFC2822, folding white space is allowed in display name. Thus
following header should be parsed as a single address "[EMAIL PROTECTED]"
having multilined display name.
To: Foo
Bar <[EMAIL PROTECTED]>
On the other hand, following program results in:
from email.Utils import getaddresses
s = """Foo
Bar <[EMAIL PROTECTED]>
"""
print getaddresses([s])
[('', 'Foo'), ('Bar', '[EMAIL PROTECTED]')]
Note that the first address is not valid one.
Looks like the bug is in _parseaddr.py. Please check the patch.
--
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-11 23:21
Message:
Logged In: YES
user_id=12800
Originator: NO
r54280 in Python 2.6 svn trunk
r54281 in Python 2.5
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1629369&group_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=detail&atid=105470&aid=1678710&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: 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=detail&atid=105470&aid=1678710&group_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=detail&atid=105470&aid=1678647&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: 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=8084&r1=8070&r2=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=detail&atid=105470&aid=1678647&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86
Bugs item #1675511, was opened at 2007-03-07 15:54 Message generated for change (Comment added) made by jlick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&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 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- Comment By: James Lick (jlick) Date: 2007-03-12 15:37 Message: Logged In: YES user_id=673069 Originator: NO I've made a patch for configure.in to fix this bug. There are two notes to explain why it was written the way it is: The first problem is to determine which processor type we are using. 'uname -p' was chosen because it returns the most generic response on both SPARC (sparc) and x86/x64 (i386) systems. There is some controversy about why it returns 'i386' even on Pentium or AMD64 systems, but Sun points to the isainfo, isalist, or psrinfo commands to get more specific processor information, so it appears they don't intend to change the behavior. The second choice is how to handle the default case if the result of the above is neither sparc or i386. I chose to use '-xcode=pic32' for sparc only, and '-Kpic' for all other responses. My reasoning is that since -Kpic existed before -xcode=pic32 was implemented that it is the more generic option, even though it and -KPIC are deprecated on sparc. I am therefore making the assumption that any possible new platforms supported by Studio 11 would in some fashion support -Kpic. This patch is a diff against Python 2.5's configure.in file. I've tested it against a Solaris 10 32-bit x86 system and a Solaris 10 64-bit sparc system both with Studio 11 installed. I don't have a 64-bit x86 system to test against. The build is mostly successful on both though there is a problem with the _ctypes module which causes test_ctypes to fail. This is a known problem covered by other bug reports which I believe is unrelated to this patch. I couldn't find the option to upload a file, so here is the patch inline: ---snip--- *** configure.in.old2007-03-11 23:01:16.879612000 -0700 --- configure.in2007-03-11 23:31:48.098734000 -0700 *** *** 1543,1551 then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! else CCSHARED="-xcode=pic32"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; --- 1543,1553 then case $ac_sys_system/$ac_sys_release in SunOS*) if test "$GCC" = yes; ! then CCSHARED="-fPIC"; ! elif test `uname -p` = sparc; ! then CCSHARED="-xcode=pic32"; ! else CCSHARED="-Kpic"; ! fi;; hp*|HP*) if test "$GCC" = yes; then CCSHARED="-fPIC"; else CCSHARED="+z"; ---snip--- -- Comment By: Martin v. Löwis (loewis) Date: 2007-03-11 03:06 Message: Logged In: YES user_id=21627 Originator: NO The manual claims (in "Supported Platforms") that "x86" refers to both 32-bit and 64-bit systems, and promises to use "32-bit x86" for 32-bit specific information, so I guess -Kpic works on AMD64 as well. -- Comment By: James Lick (jlick) Date: 2007-03-11 02:35 Message: Logged In: YES user_id=673069 Originator: NO According the the Studio 11 man page for cc '-KPIC' is an alias for '-Kpic' on x86, though it doesn't explicitly say whether this applies to x86 meaning 32 bit only or x86 meaning both 32 and 64 bit. In any case, since -KPIC is definitely equivalent to -Kpic on 32 bit x86, and -KPIC is known to work on x64, should we just use -KPIC for both? --
