[ python-Bugs-1681671 ] Python and Indeterminate Forms (Math)
Bugs item #1681671, was opened at 2007-03-15 12:28
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681671&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: jehahn (jehahn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python and Indeterminate Forms (Math)
Initial Comment:
Primary example:
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 0 ** 0
1
Per http://mathworld.wolfram.com/Indeterminate.html, 0 ** 0 is an indeterminate
form. 0 ** 0 should probably return NaN and NOT 1.
Other examples include:
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> inf = float("infinity")
>>> inf ** 0
1.0
>>> 1 ** inf
1.0
For a few others, Python provides an arguably correct answer of NaN. Examples:
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> inf = float("infinity")
>>> inf * 0
nan
>>> inf / inf
nan
>>> inf - inf
nan
And, of course, for the most obvious indeterminate form (0/0) Python does
precisely the right thing:
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 0/0
Traceback (most recent call last):
File "", line 1, in ?
ZeroDivisionError: integer division or modulo by zero
It could be argued that the correct thing to do here is to throw an exception -
mathematically speaking these forms are about as meaningful as division by zero
which Python handles by throwing an exception. (unlike Java and IEEE 754,
which do arguably evil things here by returning +/- infinity for the quantity
k/0 for all k != 0)
Unfortunately, some people doing numerical work may have gotten used to the
current Python behavior so the change isn't without risk. And some of the
current values are common "conventions" used to simplify certain common issues.
(e.g. 0 ** 0 == 1) Moreover, I don't know if this is dependent on platform
(having only tried it on a couple of the boxes I have handy.)
However, from a mathematical purist's standpoint, Python is doing the wrong
thing on these counts.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-03-17 01:20
Message:
Logged In: YES
user_id=341410
Originator: NO
Python's behavior with respect to floating point arithmetic is left to the
platform's C floating point libraries. For example, on my Windows machine
running Python 2.3.5, float("infinity") raises a ValueError. I would also
point out that 0/0 is integer division in Python 2.3.5 .
For other examples of platform-specific behavior:
Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> inf*0
-1.#IND
>>> inf**0
1.0
>>> 1**inf
Traceback (most recent call last):
File "", line 1, in ?
ValueError: (33, 'Domain error')
>>> inf*0
-1.#IND
>>> inf/inf
-1.#IND
>>> inf-inf
-1.#IND
>>>
So yeah. If you don't like how Python does math, complain to your vendor
(Apple) or compile a version of Python with a C floating point library that
works the way you want it to.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681671&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1682729 ] Documentation error (section 3.4.1)
Bugs item #1682729, was opened at 2007-03-17 15:03 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=1682729&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: emlyn (emlyncorrin) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation error (section 3.4.1) Initial Comment: In the documentation section 3.4.1 Basic customization (url: http://docs.python.org/ref/customization.html) it states: There are no reflected (swapped-argument) versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __gt__() are each other's reflection, __le__() and __ge__() are each other's reflection, and __eq__() and __ne__() are their own reflection. Surely that should be __lt__() and __ge__() are each other's reflection, and __le__() and __gt__(). I assume this is just a typo, but I haven't checked that Python itself gets it right. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682729&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1682749 ] next method assignment is ignored in new-style classes
Bugs item #1682749, was opened at 2007-03-17 15:06 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=1682749&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Albert Weichselbraun (albert2611) Assigned to: Nobody/Anonymous (nobody) Summary: next method assignment is ignored in new-style classes Initial Comment: in old-style classes the next method of an iterator-superclass can be "overwritten" using self.next = self.new_next_method when new-style classes are used the assignment is ignored and instead of new_next_method the next method of the superclass is called when the class is used as iterator (tested for python2.3-2.5 under debian/linux). - if the next() method is called directly, the assigned method is used (see attached code example). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1682729 ] Documentation error (section 3.4.1)
Bugs item #1682729, was opened at 2007-03-17 15:03 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682729&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: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: emlyn (emlyncorrin) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation error (section 3.4.1) Initial Comment: In the documentation section 3.4.1 Basic customization (url: http://docs.python.org/ref/customization.html) it states: There are no reflected (swapped-argument) versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __gt__() are each other's reflection, __le__() and __ge__() are each other's reflection, and __eq__() and __ne__() are their own reflection. Surely that should be __lt__() and __ge__() are each other's reflection, and __le__() and __gt__(). I assume this is just a typo, but I haven't checked that Python itself gets it right. -- >Comment By: Žiga Seilnacht (zseil) Date: 2007-03-17 16:40 Message: Logged In: YES user_id=1326842 Originator: NO No, the documentation is correct (as well as Python's behaviour). For example, you have a left_five and right_five, which are int like objects with value 5, and left_five is missing a __lt__ method. If you do a left_five < right_five comparison, you want right_five's __gt__ method called, because right_five's __ge__ method would return True, since their values are equal. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682729&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1682749 ] next method assignment is ignored in new-style classes
Bugs item #1682749, was opened at 2007-03-17 15:06 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Albert Weichselbraun (albert2611) >Assigned to: Neal Norwitz (nnorwitz) Summary: next method assignment is ignored in new-style classes Initial Comment: in old-style classes the next method of an iterator-superclass can be "overwritten" using self.next = self.new_next_method when new-style classes are used the assignment is ignored and instead of new_next_method the next method of the superclass is called when the class is used as iterator (tested for python2.3-2.5 under debian/linux). - if the next() method is called directly, the assigned method is used (see attached code example). -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 15:52 Message: Logged In: YES user_id=849994 Originator: NO This is another incarnation of __methods__ being looked up on the type, not the instance, except that next() is not a __method__ yet. For new-style classes, this behavior is considered correct. Neal? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1682749 ] next method assignment is ignored in new-style classes
Bugs item #1682749, was opened at 2007-03-17 15:06 Message generated for change (Comment added) made by albert2611 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Albert Weichselbraun (albert2611) Assigned to: Neal Norwitz (nnorwitz) Summary: next method assignment is ignored in new-style classes Initial Comment: in old-style classes the next method of an iterator-superclass can be "overwritten" using self.next = self.new_next_method when new-style classes are used the assignment is ignored and instead of new_next_method the next method of the superclass is called when the class is used as iterator (tested for python2.3-2.5 under debian/linux). - if the next() method is called directly, the assigned method is used (see attached code example). -- >Comment By: Albert Weichselbraun (albert2611) Date: 2007-03-17 16:27 Message: Logged In: YES user_id=806170 Originator: YES i only experienced this behavior for the next method in iterator classes. overwriting methods with other names using an assignment works as expected. -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 15:52 Message: Logged In: YES user_id=849994 Originator: NO This is another incarnation of __methods__ being looked up on the type, not the instance, except that next() is not a __method__ yet. For new-style classes, this behavior is considered correct. Neal? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1682940 ] os.walk should traverse outward symlinks
Bugs item #1682940, was opened at 2007-03-18 02:42 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=1682940&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: Tasci Synx (synx13) Assigned to: Nobody/Anonymous (nobody) Summary: os.walk should traverse outward symlinks Initial Comment: To my dismay, I discovered that os.walk will ignore all symlinks, even symlinks that link to somewhere outside of the directory being walked. So I made a little patch to os.py, I hope you apply it, or some figment thereof. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682940&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1679498 ] Lib/io.py open uses unset "bs"
Bugs item #1679498, was opened at 2007-03-12 22:28 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679498&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 3000 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) >Assigned to: Guido van Rossum (gvanrossum) Summary: Lib/io.py open uses unset "bs" Initial Comment: Within the open function, it says """ try: bs = os.fstat(raw.fileno()).st_blksize except (os.error, AttributeError): if bs > 1: buffering = bs """ Since this is the first use of name "bs", I wouldn't expect it to have any value after an Exception. If this is actually correct, it at least deserves a comment. - (second issue) _PyFileIO sets self._writable but doesn't use it (even in writable()) -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-17 23:42 Message: Logged In: YES user_id=6380 Originator: NO Thanks for reporting this! First issue: Committed revision 54424. Second issue: Committed revision 54425. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679498&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1679498 ] Lib/io.py open uses unset "bs"
Bugs item #1679498, was opened at 2007-03-12 22:28 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679498&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 3000 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Guido van Rossum (gvanrossum) Summary: Lib/io.py open uses unset "bs" Initial Comment: Within the open function, it says """ try: bs = os.fstat(raw.fileno()).st_blksize except (os.error, AttributeError): if bs > 1: buffering = bs """ Since this is the first use of name "bs", I wouldn't expect it to have any value after an Exception. If this is actually correct, it at least deserves a comment. - (second issue) _PyFileIO sets self._writable but doesn't use it (even in writable()) -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-17 23:42 Message: Logged In: YES user_id=6380 Originator: NO Thanks for reporting this! First issue: Committed revision 54424. Second issue: Committed revision 54425. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1679498&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1628906 ] clarify 80-char limit
Bugs item #1628906, was opened at 2007-01-05 11:45 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628906&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 3000 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) >Assigned to: Guido van Rossum (gvanrossum) Summary: clarify 80-char limit Initial Comment: PEP 3099 says: """ Coding style * The (recommended) maximum line width will remain 80 characters, for both C and Python code. Thread: "C style guide", http://mail.python.org/pipermail/python-3000/2006-March/000131.html """ It should be clarified that this really means 72-79 characters, perhaps by adding the following sentence: Note that according to PEP 8, this actually means no more than 79 characters in a line, and no more than about 72 in docstrings or comments. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-17 23:50 Message: Logged In: YES user_id=6380 Originator: NO IMO it's excessive to explain this. If you really want the words changed, just email me a patch directly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1628906&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1650903 ] PyFloat_FromString deprecated form
Bugs item #1650903, was opened at 2007-02-02 14:41 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: PyFloat_FromString deprecated form Initial Comment: PyFloat_FromString takes two arguments, and the only purpose of the second is to avoid changing the API. Extracts from Tim's 2000 comment: Since we can't change the interface of a public API function, pend is still supported but now *officially* useless: if pend is not NULL, *pend is set to NULL. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-17 23:55 Message: Logged In: YES user_id=6380 Originator: NO I think I should relax that statement a bit. IMO it's OK to change the signature (for Py3k) since the compiler will report an error if you call it with the old signature. What's *not* OK is to keep the signature (or to keep it compatible anyway) but change the *behavior*, as that would cause bugs that are only caught (if at all) at runtime, and will hence be hard to debug. Examples of bad changes would be changing the reference count behavior of an API, changing the type of object returned (if a specific type was previously documented) or making it possible to return NULL where this was previous not possible. -- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-06 19:06 Message: Logged In: YES user_id=764593 Originator: YES I didn't realize that a decision had been made about the C API stability. I would indeed propose changing it, but probably not if it the rest of the API (even for strings and unicode?) is supposed to stay stable. -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:54 Message: Logged In: YES user_id=849994 Originator: NO (cont'd) C API functions shouldn't even change signature in Py 3000. Therefore, a new name would be needed... -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:53 Message: Logged In: YES user_id=849994 Originator: NO What do you propose to do? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G"
Bugs item #1673757, was opened at 2007-03-04 21:34 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-17 23:58 Message: Logged In: YES user_id=6380 Originator: NO Changing the group to 2.5; see the patch (http://python.org/sf/1673759) for an explanation. -- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 06:10 Message: Logged In: YES user_id=411198 Originator: YES The patch was corrected, and tests added. -- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 05:57 Message: Logged In: YES user_id=411198 Originator: YES Yes, my bad on not having tests and the diff being fubar. I've already started writing the tests, I should be done in the next 30 minutes. Expect a new patch. -- Comment By: Nick Coghlan (ncoghlan) Date: 2007-03-06 05:55 Message: Logged In: YES user_id=1038590 Originator: NO Behaviour is definitely present in the current 2.6 trunk, so I expect it to be present in the 2.5 maintenance branch too. On platforms which provide a correct implementation of vsnprintf, this won't cause a buffer overflow (but can give an incorrect result). As far as I can tell, the limited precision of C doubles saves you on platforms without vsnprintf (then again, I may not be abusing it correctly after forcing my dev tree to use the vsnprintf emulation, or else the behaviour of the emulation may vary with platform vagaries in vsprintf implementations). The patch doesn't currently apply cleanly - it needs to be regenerated using svn diff from the main python directory so that the filenames are correct. We also need a test case to make sure the problem never comes back (the string tests are a little confusing though, since the same tests are used for str, unicode & UserString). -- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:47 Message: Logged In: YES user_id=411198 Originator: YES Patch for 3.0 is at http://python.org/sf/1673759 This should be checked in 2.5 and 2.6, but I don't have an environment to compile those. -- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:42 Message: Logged In: YES user_id=411198 Originator: YES This is the correct behavior: >>> '%200.200g' % 1.0 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) But 'G' is handled differently: >>> '%200.200G' % 1.0 ' 1' 'G' should give the same OverflowError as 'g'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
