[ python-Bugs-1636950 ] Newline skipped in "for line in file"
Bugs item #1636950, was opened at 2007-01-16 17:56 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1636950&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: Andy Monthei (amonthei) Assigned to: Nobody/Anonymous (nobody) Summary: Newline skipped in "for line in file" Initial Comment: When processing huge fixed block files of about 7000 bytes wide and several hundred thousand lines long some pairs of lines get read as one long line with no line break when using "for line in file:". The problem is even worse when using the fileinput module and reading in five or six huge files consisting of 4.8 million records causes several hundred pairs of lines to be read as single lines. When a newline is skipped it is usually followed by several more in the next few hundred lines. I have not noticed any other characters being skipped, only the line break. O.S. Windows (5, 1, 2600, 2, 'Service Pack 2') Python 2.5 -- >Comment By: Walter Dörwald (doerwalter) Date: 2007-01-18 10:23 Message: Logged In: YES user_id=89016 Originator: NO Are you using any of the unicode reading features (i.e. codecs.EncodedFile etc.) or are you using plain open() for reading the file? -- Comment By: Mark Roberts (mark-roberts) Date: 2007-01-18 08:12 Message: Logged In: YES user_id=1591633 Originator: NO I don't know if this helps: I spent the last little while creating / reading random files that all (seemingly) matched the description you gave us. None of these files failed to read properly. (e.g., have the right amount of rows with a line length that seemingly was the right line. Definitely no doubling lines). Perusing the file source code found a detailed discussion of fgets vs fgetc for finding the next line in the file. Have you tried reading the file with fp.read(8192) or similar? Hopefully you're able to reproduce the bug with scrubbed data (because I couldn't construct random data to do so). Good luck. -- Comment By: Mark Roberts (mark-roberts) Date: 2007-01-18 06:24 Message: Logged In: YES user_id=1591633 Originator: NO How wide are the min and max widths of the lines? This problem is of particular interest to me. -- Comment By: Andy Monthei (amonthei) Date: 2007-01-17 22:58 Message: Logged In: YES user_id=1693612 Originator: YES I can not upload the files that trigger this because of the data that is in them but I am working on getting around that. In my data line 617391 in a fixed block file of 6990 bytes wide gets read in with the next line after it. The line break is 0d0a (same as the others) where the bug happens so I am wondering if it is a buffer issue where the linebreak falls at the edge, however no other characters are ever missed. The total file is 888420 lines and this happens in four spots. I will hopefully have a file to send soon. -- Comment By: Brett Cannon (bcannon) Date: 2007-01-16 23:33 Message: Logged In: YES user_id=357491 Originator: NO Do you happen to have a sample you could upload that triggers the bug? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1636950&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1638627 ] Incorrect documentation for random.betavariate()
Bugs item #1638627, was opened at 2007-01-18 15:18 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=1638627&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: Troels Walsted Hansen (troels) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect documentation for random.betavariate() Initial Comment: Both the documentation at http://docs.python.org/lib/module-random.html and the docstring have the same erroneous input conditions. They claim input must be >-1 when it must in fact be >0. Note also the freak "}" that has snuck into the docstring (copied and pasted from the documentation perhaps?). >>> import random >>> print random.betavariate.__doc__ Beta distribution. Conditions on the parameters are alpha > -1 and beta} > -1. Returned values range between 0 and 1. >>> random.betavariate(0, 0) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/random.py", line 594, in betavariate y = self.gammavariate(alpha, 1.) File "/usr/lib/python2.3/random.py", line 457, in gammavariate raise ValueError, 'gammavariate: alpha and beta must be > 0.0' ValueError: gammavariate: alpha and beta must be > 0.0 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1638627&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1638627 ] Incorrect documentation for random.betavariate()
Bugs item #1638627, was opened at 2007-01-18 14:18 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1638627&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: Troels Walsted Hansen (troels) >Assigned to: Raymond Hettinger (rhettinger) Summary: Incorrect documentation for random.betavariate() Initial Comment: Both the documentation at http://docs.python.org/lib/module-random.html and the docstring have the same erroneous input conditions. They claim input must be >-1 when it must in fact be >0. Note also the freak "}" that has snuck into the docstring (copied and pasted from the documentation perhaps?). >>> import random >>> print random.betavariate.__doc__ Beta distribution. Conditions on the parameters are alpha > -1 and beta} > -1. Returned values range between 0 and 1. >>> random.betavariate(0, 0) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/random.py", line 594, in betavariate y = self.gammavariate(alpha, 1.) File "/usr/lib/python2.3/random.py", line 457, in gammavariate raise ValueError, 'gammavariate: alpha and beta must be > 0.0' ValueError: gammavariate: alpha and beta must be > 0.0 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1638627&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1636950 ] Newline skipped in "for line in file"
Bugs item #1636950, was opened at 2007-01-16 10:56 Message generated for change (Comment added) made by amonthei You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1636950&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: Andy Monthei (amonthei) Assigned to: Nobody/Anonymous (nobody) Summary: Newline skipped in "for line in file" Initial Comment: When processing huge fixed block files of about 7000 bytes wide and several hundred thousand lines long some pairs of lines get read as one long line with no line break when using "for line in file:". The problem is even worse when using the fileinput module and reading in five or six huge files consisting of 4.8 million records causes several hundred pairs of lines to be read as single lines. When a newline is skipped it is usually followed by several more in the next few hundred lines. I have not noticed any other characters being skipped, only the line break. O.S. Windows (5, 1, 2600, 2, 'Service Pack 2') Python 2.5 -- >Comment By: Andy Monthei (amonthei) Date: 2007-01-18 09:34 Message: Logged In: YES user_id=1693612 Originator: YES I am using open() for reading the file, no other features. I have also had fileinput.input(fileList) compound the problem. Each file that this has happened to is a fixed block file of either 6990 or 7700 bytes wide but this I think is insignificant. When looking at the file in a hex editor everything looks fine and a small Java program using a buffered reader will give me the correct line count when Python does not. Using something like fp.read(8192) I'm sure might temporarily solve my problem but I will keep working on getting a file I can upload. -- Comment By: Walter Dörwald (doerwalter) Date: 2007-01-18 03:23 Message: Logged In: YES user_id=89016 Originator: NO Are you using any of the unicode reading features (i.e. codecs.EncodedFile etc.) or are you using plain open() for reading the file? -- Comment By: Mark Roberts (mark-roberts) Date: 2007-01-18 01:12 Message: Logged In: YES user_id=1591633 Originator: NO I don't know if this helps: I spent the last little while creating / reading random files that all (seemingly) matched the description you gave us. None of these files failed to read properly. (e.g., have the right amount of rows with a line length that seemingly was the right line. Definitely no doubling lines). Perusing the file source code found a detailed discussion of fgets vs fgetc for finding the next line in the file. Have you tried reading the file with fp.read(8192) or similar? Hopefully you're able to reproduce the bug with scrubbed data (because I couldn't construct random data to do so). Good luck. -- Comment By: Mark Roberts (mark-roberts) Date: 2007-01-17 23:24 Message: Logged In: YES user_id=1591633 Originator: NO How wide are the min and max widths of the lines? This problem is of particular interest to me. -- Comment By: Andy Monthei (amonthei) Date: 2007-01-17 15:58 Message: Logged In: YES user_id=1693612 Originator: YES I can not upload the files that trigger this because of the data that is in them but I am working on getting around that. In my data line 617391 in a fixed block file of 6990 bytes wide gets read in with the next line after it. The line break is 0d0a (same as the others) where the bug happens so I am wondering if it is a buffer issue where the linebreak falls at the edge, however no other characters are ever missed. The total file is 888420 lines and this happens in four spots. I will hopefully have a file to send soon. -- Comment By: Brett Cannon (bcannon) Date: 2007-01-16 16:33 Message: Logged In: YES user_id=357491 Originator: NO Do you happen to have a sample you could upload that triggers the bug? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1636950&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 16:03 Message generated for change (Comment added) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: 9 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: David Watson (baikie) Date: 2007-01-18 18:14 Message: Logged In: YES user_id=1504904 Originator: YES Unfortunately, there is a problem with clearing _toc: it's basically the one I alluded to in my comment of 2006-12-16. Back then I thought it could be caught by the test you issue the warning for, but the application may instead do its second remove() *after* the lock() (so that self._pending is not set at lock() time), using the key carried over from before it called unlock(). As before, this would result in the wrong message being deleted. I've added a test case for this (diff attached), and a bug I found in the process whereby flush() wasn't updating the length, which could cause subsequent flushes to fail (I've got a fix for this). These seem to have turned up a third bug in the MH class, but I haven't looked at that yet. File Added: mailbox-unified2-test.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-17 21:06 Message: Logged In: YES user_id=11375 Originator: NO Add mailbox-unified-patch. File Added: mailbox-unified-patch.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-17 21:05 Message: Logged In: YES user_id=11375 Originator: NO mailbox-pending-lock is the difference between David's copy-back-new + fcntl-warning and my -unified patch, uploaded so that he can comment on the changes. The only change is to make _singleFileMailbox.lock() clear self._toc, forcing a re-read of the mailbox file. If _pending is true, the ToC isn't cleared and a warning is logged. I think this lets existing code run (albeit possibly with a warning if the mailbox is modified before .lock() is called), but fixes the risk of missing changes written by another process. Triggering a new warning is sort of an API change, but IMHO it's still worth backporting; code that triggers this warning is at risk of losing messages or corrupting the mailbox. Clearing the _toc on .lock() is also sort of an API change, but it's necessary to avoid the potential data loss. It may lead to some redundant scanning of mailbox files, but this price is worth paying, I think; people probably don't have 2Gb mbox files (I hope not, anyway!) and no extra read is done if you create the mailbox and immediately lock it before looking anything up. Neal: if you want to discuss this patch or want an explanation of something, feel free to chat with me about it. I'll wait a day or two and see if David spots any problems. If nothing turns up, I'll commit it to both trunk and release25-maint. File Added: mailbox-pending-lock.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-17 20:53 Message: Logged In: YES user_id=11375 Originator: NO mailbox-unified-patch contains David's copy-back-new and
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 16:03 Message generated for change (Comment added) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: 9 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: David Watson (baikie) Date: 2007-01-18 18:15 Message: Logged In: YES user_id=1504904 Originator: YES This version passes the new tests (it fixes the length checking bug, and no longer clears self._toc), but goes back to failing test_concurrent_add. File Added: mailbox-unified2-module.diff -- Comment By: David Watson (baikie) Date: 2007-01-18 18:14 Message: Logged In: YES user_id=1504904 Originator: YES Unfortunately, there is a problem with clearing _toc: it's basically the one I alluded to in my comment of 2006-12-16. Back then I thought it could be caught by the test you issue the warning for, but the application may instead do its second remove() *after* the lock() (so that self._pending is not set at lock() time), using the key carried over from before it called unlock(). As before, this would result in the wrong message being deleted. I've added a test case for this (diff attached), and a bug I found in the process whereby flush() wasn't updating the length, which could cause subsequent flushes to fail (I've got a fix for this). These seem to have turned up a third bug in the MH class, but I haven't looked at that yet. File Added: mailbox-unified2-test.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-17 21:06 Message: Logged In: YES user_id=11375 Originator: NO Add mailbox-unified-patch. File Added: mailbox-unified-patch.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-17 21:05 Message: Logged In: YES user_id=11375 Originator: NO mailbox-pending-lock is the difference between David's copy-back-new + fcntl-warning and my -unified patch, uploaded so that he can comment on the changes. The only change is to make _singleFileMailbox.lock() clear self._toc, forcing a re-read of the mailbox file. If _pending is true, the ToC isn't cleared and a warning is logged. I think this lets existing code run (albeit possibly with a warning if the mailbox is modified before .lock() is called), but fixes the risk of missing changes written by another process. Triggering a new warning is sort of an API change, but IMHO it's still worth backporting; code that triggers this warning is at risk of losing messages or corrupting the mailbox. Clearing the _toc on .lock() is also sort of an API change, but it's necessary to avoid the potential data loss. It may lead to some redundant scanning of mailbox files, but this price is worth paying, I think; people probably don't have 2Gb mbox files (I hope not, anyway!) and no extra read is done if you create the mailbox and immediately lock it before looking anything up. Neal: if you want to discuss this patch or want an explanation of something, feel free to chat with me about it. I'll wait a day or two and see if David
[ python-Bugs-1637120 ] Python 2.5 fails to build on AIX 5.3 (xlc_r compiler)
Bugs item #1637120, was opened at 2007-01-16 22:06
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637120&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: Orlando Irrazabal (oirraza)
>Assigned to: Thomas Heller (theller)
Summary: Python 2.5 fails to build on AIX 5.3 (xlc_r compiler)
Initial Comment:
Initial Comment:
Build of Python 2.5 on AIX 5.3 with xlc_r fails with the below error message.
The configure line is:
./configure --with-gcc="xlc_r -q64" --with-cxx="xlC_r -q64" --disable-ipv6
AR="ar -X64"
[...]
building '_ctypes' extension
xlc_r -q64 -DNDEBUG -O -I. -I/sw_install/python-2.5/./Include
-Ibuild/temp.aix-5.3-2.5/libffi/include -Ibuild/temp.aix-5.3-2.5/libffi
-I/sw_install/python-2.5/Modules/_ctypes/libffi/src -I./Include -I.
-I/sw_install/python-2.5/Include -I/sw_install/python-2.5 -c
/sw_install/python-2.5/Modules/_ctypes/_ctypes.c -o
build/temp.aix-5.3-2.5/sw_install/python-2.5/Modules/_ctypes/_ctypes.o
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 221.3: 1506-166 (S)
Definition of function ffi_closure requires parentheses.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 221.15: 1506-276 (S) Syntax
error: possible missing '{'?
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 248.3: 1506-273 (E) Missing
type in declaration of ffi_raw_closure.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 251.38: 1506-275 (S)
Unexpected text '*' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 252.23: 1506-276 (S) Syntax
error: possible missing identifier?
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 251.1: 1506-033 (S)
Function ffi_prep_raw_closure is not valid. Function cannot return a function.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 251.1: 1506-282 (S) The
type of the parameters must be specified in a prototype.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 254.23: 1506-275 (S)
Unexpected text 'void' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 254.38: 1506-275 (S)
Unexpected text ')' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 257.43: 1506-275 (S)
Unexpected text '*' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 258.28: 1506-276 (S) Syntax
error: possible missing identifier?
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 257.1: 1506-033 (S)
Function ffi_prep_java_raw_closure is not valid. Function cannot return a
function.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 257.1: 1506-282 (S) The
type of the parameters must be specified in a prototype.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 260.28: 1506-275 (S)
Unexpected text 'void' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 260.43: 1506-275 (S)
Unexpected text ')' encountered.
"/sw_install/python-2.5/Modules/_ctypes/ctypes.h", line 71.9: 1506-046 (S)
Syntax error.
"/sw_install/python-2.5/Modules/_ctypes/ctypes.h", line 77.26: 1506-195 (S)
Integral constant expression with a value greater than zero is required.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 2804.31: 1506-068 (E)
Operation between types "void*" and "int(*)(void)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 3357.28: 1506-280 (E)
Function argument assignment between types "int(*)(void)" and "void*" is not
allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 3417.42: 1506-022 (S)
"pcl" is not a member of "struct {...}".
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4749.67: 1506-280 (E)
Function argument assignment between types "void*" and "void*(*)(void*,const
void*,unsigned long)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4750.66: 1506-280 (E)
Function argument assignment between types "void*" and
"void*(*)(void*,int,unsigned long)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4751.69: 1506-280 (E)
Function argument assignment between types "void*" and "struct
_object*(*)(const char*,long)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4752.64: 1506-280 (E)
Function argument assignment between types "void*" and "struct
_object*(*)(void*,struct _object*,struct _object*)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4754.70: 1506-280 (E)
Function argument assignment between types "void*" and "struct
_object*(*)(const unsigned int*,int)" is not allowed.
building '_ctypes_test' extension
xlc_r -q64 -DNDEBUG -O -I. -I/sw_install/python-2.5/./Include -I./Include -I.
-I/sw_install/python-2.5/Include -I/sw_install/python-2.5 -c
/sw_install/python-2.5/Modules/_ctypes/_ctypes_test.c -o
build/temp.a
[ python-Bugs-1638627 ] Incorrect documentation for random.betavariate()
Bugs item #1638627, was opened at 2007-01-18 15:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1638627&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: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Troels Walsted Hansen (troels) Assigned to: Raymond Hettinger (rhettinger) Summary: Incorrect documentation for random.betavariate() Initial Comment: Both the documentation at http://docs.python.org/lib/module-random.html and the docstring have the same erroneous input conditions. They claim input must be >-1 when it must in fact be >0. Note also the freak "}" that has snuck into the docstring (copied and pasted from the documentation perhaps?). >>> import random >>> print random.betavariate.__doc__ Beta distribution. Conditions on the parameters are alpha > -1 and beta} > -1. Returned values range between 0 and 1. >>> random.betavariate(0, 0) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/random.py", line 594, in betavariate y = self.gammavariate(alpha, 1.) File "/usr/lib/python2.3/random.py", line 457, in gammavariate raise ValueError, 'gammavariate: alpha and beta must be > 0.0' ValueError: gammavariate: alpha and beta must be > 0.0 -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-18 21:03 Message: Logged In: YES user_id=21627 Originator: NO This seems to be a duplicate of 1635892 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1638627&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1634774 ] locale 1251 does not convert to upper case properly
Bugs item #1634774, was opened at 2007-01-13 18:30
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1634774&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: Ivan Dobrokotov (dobrokot)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale 1251 does not convert to upper case properly
Initial Comment:
# -*- coding: 1251 -*-
import locale
locale.setlocale(locale.LC_ALL, ".1251") #locale name may be Windows specific?
#---
print chr(184), chr(168)
assert chr(255).upper() == chr(223) #OK
assert chr(184).upper() == chr(168) #fail
#---
assert 'q'.upper() == 'Q' #OK
assert 'ж'.upper() == 'Ж' #OK
assert 'Ж'.upper() == 'Ж' #OK
assert 'я'.upper() == 'Я' #OK
assert u'ё'.upper() == u'Ё' #OK (locale independent)
assert 'ё'.upper() == 'Ё' #fail
I suppose incorrect realization of uppercase like
if ('a' <= c && c <= 'я')
return c+'Я'-'я'
symbol 'ё' (184 in cp1251) is not in range 'a'-'я'
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-01-18 21:08
Message:
Logged In: YES
user_id=21627
Originator: NO
You can see the implementation of .upper in
http://svn.python.org/projects/python/tags/r25/Objects/stringobject.c
(function string_upper)
Off-hand, I cannot see anything wrong in that code. It definitely does
*not* use c+'Я'-'я'.
--
Comment By: Ivan Dobrokotov (dobrokot)
Date: 2007-01-13 22:08
Message:
Logged In: YES
user_id=1538986
Originator: YES
forgot to mention used python version -
http://www.python.org/ftp/python/2.5/python-2.5.msi
--
Comment By: Ivan Dobrokotov (dobrokot)
Date: 2007-01-13 18:51
Message:
Logged In: YES
user_id=1538986
Originator: YES
sorry, I mean
toupper((int)(unsigned char)'ё')
not just toupper('ё')
--
Comment By: Ivan Dobrokotov (dobrokot)
Date: 2007-01-13 18:49
Message:
Logged In: YES
user_id=1538986
Originator: YES
C-CRT library fucntion toupper('ё') works properly, if I set
setlocale(LC_ALL, ".1251")
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1634774&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1634774 ] locale 1251 does not convert to upper case properly
Bugs item #1634774, was opened at 2007-01-13 18:30
Message generated for change (Comment added) made by dobrokot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1634774&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: Ivan Dobrokotov (dobrokot)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale 1251 does not convert to upper case properly
Initial Comment:
# -*- coding: 1251 -*-
import locale
locale.setlocale(locale.LC_ALL, ".1251") #locale name may be Windows specific?
#---
print chr(184), chr(168)
assert chr(255).upper() == chr(223) #OK
assert chr(184).upper() == chr(168) #fail
#---
assert 'q'.upper() == 'Q' #OK
assert 'ж'.upper() == 'Ж' #OK
assert 'Ж'.upper() == 'Ж' #OK
assert 'я'.upper() == 'Я' #OK
assert u'ё'.upper() == u'Ё' #OK (locale independent)
assert 'ё'.upper() == 'Ё' #fail
I suppose incorrect realization of uppercase like
if ('a' <= c && c <= 'я')
return c+'Я'-'я'
symbol 'ё' (184 in cp1251) is not in range 'a'-'я'
--
>Comment By: Ivan Dobrokotov (dobrokot)
Date: 2007-01-18 22:18
Message:
Logged In: YES
user_id=1538986
Originator: YES
well, C:
#include
#include
#include
int main()
{
int i = 184;
char *old = setlocale(LC_CTYPE, ".1251");
assert(old);
printf("%d -> %d\n", i, _toupper(i));
printf("%d -> %d\n", i, toupper(i));
}
C ouput:
184 -> 152
184 -> 168
so, _toupper and upper are different functions. MSDN does not mention
nothing about difference, except that 'toupper' is "ANSI compatible" :(
File Added: toupper.zip
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-01-18 21:08
Message:
Logged In: YES
user_id=21627
Originator: NO
You can see the implementation of .upper in
http://svn.python.org/projects/python/tags/r25/Objects/stringobject.c
(function string_upper)
Off-hand, I cannot see anything wrong in that code. It definitely does
*not* use c+'Я'-'я'.
--
Comment By: Ivan Dobrokotov (dobrokot)
Date: 2007-01-13 22:08
Message:
Logged In: YES
user_id=1538986
Originator: YES
forgot to mention used python version -
http://www.python.org/ftp/python/2.5/python-2.5.msi
--
Comment By: Ivan Dobrokotov (dobrokot)
Date: 2007-01-13 18:51
Message:
Logged In: YES
user_id=1538986
Originator: YES
sorry, I mean
toupper((int)(unsigned char)'ё')
not just toupper('ё')
--
Comment By: Ivan Dobrokotov (dobrokot)
Date: 2007-01-13 18:49
Message:
Logged In: YES
user_id=1538986
Originator: YES
C-CRT library fucntion toupper('ё') works properly, if I set
setlocale(LC_ALL, ".1251")
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1634774&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1639002 ] add type defintion support
Feature Requests item #1639002, was opened at 2007-01-18 22:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1639002&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: djnet (djnet) Assigned to: Nobody/Anonymous (nobody) Summary: add type defintion support Initial Comment: Hi, I'm used to java language. When i use a good java ide, the autocompletion is very effective (python cannot be such effective). ex, if i enter following text: Date lDate=new Date(); lDate.[TAB_KEY] then the editor can display all the methods available for my 'lDate' object; it can because it knows the object's type. This is very convenient and allows to use a new API without browsing the API documentation ! I think such autocompletion could be achieved in python simply: it only need a "type definition" syntax. Of course, the type definition should NOT be MANDATORY ! So, is this a good idea ? David -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1639002&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1634774 ] locale 1251 does not convert to upper case properly
Bugs item #1634774, was opened at 2007-01-13 18:30
Message generated for change (Comment added) made by dobrokot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1634774&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: Ivan Dobrokotov (dobrokot)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale 1251 does not convert to upper case properly
Initial Comment:
# -*- coding: 1251 -*-
import locale
locale.setlocale(locale.LC_ALL, ".1251") #locale name may be Windows specific?
#---
print chr(184), chr(168)
assert chr(255).upper() == chr(223) #OK
assert chr(184).upper() == chr(168) #fail
#---
assert 'q'.upper() == 'Q' #OK
assert 'ж'.upper() == 'Ж' #OK
assert 'Ж'.upper() == 'Ж' #OK
assert 'я'.upper() == 'Я' #OK
assert u'ё'.upper() == u'Ё' #OK (locale independent)
assert 'ё'.upper() == 'Ё' #fail
I suppose incorrect realization of uppercase like
if ('a' <= c && c <= 'я')
return c+'Я'-'я'
symbol 'ё' (184 in cp1251) is not in range 'a'-'я'
--
>Comment By: Ivan Dobrokotov (dobrokot)
Date: 2007-01-18 22:59
Message:
Logged In: YES
user_id=1538986
Originator: YES
--
standard header ctype.h:
#define _toupper(_c)( (_c)-'a'+'A' )
--
CRT file toupper.c:
/* define function-like macro equivalent to _toupper()
*/
#define mkupper(c) ( (c)-'a'+'A' )
int __cdecl _toupper (
int c
)
{
return(mkupper(c));
}
( http://www.everfall.com/paste/id.php?j13ernl40i9e )
suggestion: replace _toupper with toupper. Performance may degrade ( a lot
thread locks/MultiByteToWideChar/other code for every non-ASCII lowercase
symbol). Sugestion for optimization: setup "int toupper_table[256]" (and
other tables) in everycall to setlocale.
--
Comment By: Ivan Dobrokotov (dobrokot)
Date: 2007-01-18 22:18
Message:
Logged In: YES
user_id=1538986
Originator: YES
well, C:
#include
#include
#include
int main()
{
int i = 184;
char *old = setlocale(LC_CTYPE, ".1251");
assert(old);
printf("%d -> %d\n", i, _toupper(i));
printf("%d -> %d\n", i, toupper(i));
}
C ouput:
184 -> 152
184 -> 168
so, _toupper and upper are different functions. MSDN does not mention
nothing about difference, except that 'toupper' is "ANSI compatible" :(
File Added: toupper.zip
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-01-18 21:08
Message:
Logged In: YES
user_id=21627
Originator: NO
You can see the implementation of .upper in
http://svn.python.org/projects/python/tags/r25/Objects/stringobject.c
(function string_upper)
Off-hand, I cannot see anything wrong in that code. It definitely does
*not* use c+'Я'-'я'.
--
Comment By: Ivan Dobrokotov (dobrokot)
Date: 2007-01-13 22:08
Message:
Logged In: YES
user_id=1538986
Originator: YES
forgot to mention used python version -
http://www.python.org/ftp/python/2.5/python-2.5.msi
--
Comment By: Ivan Dobrokotov (dobrokot)
Date: 2007-01-13 18:51
Message:
Logged In: YES
user_id=1538986
Originator: YES
sorry, I mean
toupper((int)(unsigned char)'ё')
not just toupper('ё')
--
Comment By: Ivan Dobrokotov (dobrokot)
Date: 2007-01-13 18:49
Message:
Logged In: YES
user_id=1538986
Originator: YES
C-CRT library fucntion toupper('ё') works properly, if I set
setlocale(LC_ALL, ".1251")
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1634774&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630894 ] Garbage output to file of specific size
Bugs item #1630894, was opened at 2007-01-08 15:40
Message generated for change (Comment added) made by mculbert
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630894&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
>Status: Deleted
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Culbertson (mculbert)
Assigned to: Nobody/Anonymous (nobody)
Summary: Garbage output to file of specific size
Initial Comment:
The attached script inexplicably fills the output file with garbage using the
input file available at:
http://cs.wheaton.edu/~mculbert/StdDetVol_Scaled_SMDS.dat (4.6Mb)
If the string outputed in line 26 is changed to f.write("bla "), the output
file is legible. If the expression is changed from f.write("%g " % k) to
f.write("%f " % k) or f.write("%e " % k), the file is legible. If, however,
the expression is changed to f.write('x'*len(str(k))+" "), the file remains
illegible. Adding a print statement:
print "%g " % k
before line 26 indicates that k is assuming the correct values and that the
string interpolation is functioning properly. This suggests that the problem
causing the garbage may be related to the specific file size created with this
particular set of data.
The problem occurs with Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310
32 bit (Intel)] under Windows XP. The problem doesn't occur with the same
script and input file using Python 2.3.5 on Mac OS 10.4.8.
--
>Comment By: Michael Culbertson (mculbert)
Date: 2007-01-18 19:41
Message:
Logged In: YES
user_id=1686784
Originator: YES
After some more observation, I've decided this is probably a Windows XP
issue, not a Python one. I transfered the illegible file to a unix machine
and was able to read it appropriately, so the python output itself seems to
be fine. Sorry for the trouble.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-01-09 13:31
Message:
Logged In: YES
user_id=21627
Originator: NO
Can you please report what the expected output is? Mine (created on Linux)
starts with
40 40 32 64
followed by many "0.0 " values.
Also, can you please report what the actual output is that you get? In
what way is it
"illegible"?
What version of Numeric are you using?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630894&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633863 ] AIX: configure ignores $CC; problems with C++ style comments
Bugs item #1633863, was opened at 2007-01-12 00:46 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633863&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: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: AIX: configure ignores $CC; problems with C++ style comments Initial Comment: CC=xlc_r ./configure does not work on AIX-5.1, because configure unconditionally sets $CC to "cc_r": case $ac_sys_system in AIX*) CC=cc_r without_gcc=;; It would be better to leave $CC and just add "-qthreaded" to $CFLAGS. Furthermore, much of the C source code of Python uses C++ /C99 comments. This is an error with the standard AIX compiler. Please add the compiler flag "-qcpluscmt". An alternative would be to use a default of "xlc_r" for CC on AIX. This calls the compiler in a mode that both accepts C++ comments and generates reentrant code. Regards, Johannes -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-18 21:47 Message: Logged In: YES user_id=33168 Originator: NO There shouldn't be any C++ comments in the Python code. If there are, it is a mistake. I did see some get removed recently. Could you let me know where you see the C++ comments? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633863&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1635217 ] Little mistake in docs
Bugs item #1635217, was opened at 2007-01-14 07:09 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1635217&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: anatoly techtonik (techtonik) Assigned to: Nobody/Anonymous (nobody) Summary: Little mistake in docs Initial Comment: It would be nice to see example of setup() call on the page with "requires" keywords argument description http://docs.python.org/dist/node10.html Like: setup(..., requires=["somepackage (>1.0, !=1.5)"], provides=["mypkg (1.1)"] ) There seems to be mistake in table with examples for "provides" keyword on the same page - it looks like: mypkg (1.1 shouldn't this be mypkg (1.1)? -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-18 21:54 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report. I fixed the unbalanced paren. I'll leave this open in case someone is ambitious to add more doc. Committed revision 53487. (2.5) Committed revision 53488. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1635217&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1635353 ] expanduser tests in test_posixpath fail if $HOME ends in a /
Bugs item #1635353, was opened at 2007-01-14 12:28
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1635353&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: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: expanduser tests in test_posixpath fail if $HOME ends in a /
Initial Comment:
test_expanduser in test_posixpath checks if expanduser('~/') equals
expanduser('~') + '/'. expanduser checks if the home dir location ends in a /
and skips the first character of the appended path if it does (so
expanduser('~/foo') with HOME=/spork/ becomes /spork/foo, not /spork//foo).
This means that if you run test_posixpath with HOME=/spork/ expanduser('~') and
expanduser('~/') both return '/spork/' and the test fails because '/spork//' !=
'/spork/'.
Possible fixes I can think of: either have expanduser strip the trailing slash
from the home directory instead of skipping the first slash from the appended
path (so still with HOME=/spork/ expanduser('~') would be '/spork'), or have
the test check if expanduser('~') ends in a backslash and check if
expanduser('~') is equal to expanduser('~/') in that case.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-18 22:00
Message:
Logged In: YES
user_id=33168
Originator: NO
What version of Python and what platform (Windows? Unix? etc)?
I tried this on Linux with Python 2.5 and test_posixpath passed.
[EMAIL PROTECTED] ~/build/python/svn/r25 $ HOME=~/ ./python -tt
./Lib/test/regrtest.py test_posixpath
test_posixpath
1 test OK.
[EMAIL PROTECTED] ~/build/python/svn/r25 $ HOME=/home/neal ./python -tt
./Lib/test/regrtest.py test_posixpath
test_posixpath
1 test OK.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1635353&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1637022 ] Python-2.5 segfault with tktreectrl
Bugs item #1637022, was opened at 2007-01-16 19:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637022&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: AST >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: klappnase (klappnase) Assigned to: Nobody/Anonymous (nobody) Summary: Python-2.5 segfault with tktreectrl Initial Comment: Python-2.5 segfaults when using the tktreectrl widget. As Anton Hartl pointed out (see http://groups.google.com/group/comp.lang.python/browse_thread/thread/37536988c8499708/aed1d725d8e84ed8?lnk=raot#aed1d725d8e84ed8) this is because both Python-2.5 and tktreectrl use a global symbol "Ellipsis". Changing "Ellipsis" in ast.c and Python-ast.c into something like "PyAst_Ellipsis" fixes this. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-19 07:43 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the report. Fixed in 53489 and 53490. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637022&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
