[ python-Feature Requests-1003935 ] xrange overflows
Feature Requests item #1003935, was opened at 2004-08-05 15:16 Message generated for change (Comment added) made by hfuru You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1003935&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Raymond Hettinger (rhettinger) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" formore information. >>> from sys import maxint >>> "%x" % maxint '7fff' -- >Comment By: Hallvard B Furuseth (hfuru) Date: 2005-07-11 12:16 Message: Logged In: YES user_id=726647 What is "cute" about using maxint as an xrange() limit, and why would it impact its performance to return its 2nd parameter as endvalue +/- 1 (an int) instead of trying to return endvalue + step (which can be long)? -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-11 01:11 Message: Logged In: YES user_id=80475 Will look at it to see if there is something simple that can be done. These were design decisions -- xrange() and count() are supposed to be simple and fast -- with other tools being preferred if you are pushing beyond the limit of normal use cases. IOW, it is not worth crippling their performance just because someone has discovered cute ways of using sys.maxint. -- Comment By: Tim Peters (tim_one) Date: 2005-07-10 23:19 Message: Logged In: YES user_id=31435 Unassigned myself, since I don't plan to do anything else here. -- Comment By: Connelly (connelly) Date: 2004-12-06 08:04 Message: Logged In: YES user_id=1039782 Yes, I run into this bug all the time. For example, I may want to generate all strings of length n: BINARY_CHARSET = ''.join([chr(i) for i in range(256)]) def all_strs(n, charset=BINARY_CHARSET): m = len(charset) for i in xrange(m**n): yield ''.join([charset[i//m**j%m] for j in range(n)]) This is correct algorithmically, but fails due to the buggy Python xrange() function. So I end up writing my own irange () function. Other cases where I've run into this problem: Sieving for primes starting at a given large prime, checking for integer solutions to an equation starting with a large integer, and searching very large integer sets. itertools.count and itertools.repeat are similarly annoying. Often I want to search the list of all positive integers starting with 1, and have to use an awkward while loop to do this, or write my own replacement for itertools.count. There should be little performance hit for apps which use xrange(n), where n fits in the system's integer size. xrange () can just return an iterator which returns system ints, and the only performance penalty is an extra if statement in the call to xrange (and there is no performance penalty in the iterator's next() method). Finally, this move appears consistent with Python's values, ie simplicity, long ints supported with no extra effort, avoid gotchas for newbies, no special cases, etc. -- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-08 20:09 Message: Logged In: YES user_id=726647 Here is why repr() is relevant - though the error message was certainly weird. With the latest CVS version: >>> xrange(maxint-1, maxint, 2) xrange(2147483646, -2147483648, 2) Which is why I suggested to return last+step/abs(step) as the 2nd argument. -- Comment By: Tim Peters (tim_one) Date: 2004-08-08 09:20 Message: Logged In: YES user_id=31435 Changed range_new() to stop u
[ python-Bugs-1236090 ] crashes in bgen wrappers
Bugs item #1236090, was opened at 2005-07-11 15:12
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=1236090&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: Platform-specific
Status: Open
Resolution: None
Priority: 8
Submitted By: Michael Hudson (mwh)
Assigned to: Jack Jansen (jackjansen)
Summary: crashes in bgen wrappers
Initial Comment:
There's something peculiar in the land of bgen-ed wrappers:
$ ./python.exe
Python 2.5a0 (#1, Jul 11 2005, 13:21:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Carbon.File
[45313 refs]
>>> Carbon.File.FSSpec(os.curdir).as_pathname()
Segmentation fault
("make test" also crashes).
This is on 10.3.9.
My first investigations with gdb didn't reveal anything that made
much sense, so it *might* be a compiler bug. At any rate, it didn't
do this a few weeks ago...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236090&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1234850 ] Admin privs required for Windows?
Bugs item #1234850, was opened at 2005-07-08 17:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&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: Distutils Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Admin privs required for Windows? Initial Comment: Over in ZopeLand, there's a complaint that the ZODB Windows installer requires admin privileges (or something like that): http://www.zope.org/Collectors/Zope/1838 The installer was produced using Python 2.3.5, via python setup.py bdist_wininst from the root of a ZODB checkout. Anyone have a guess as to what privs it needs that it might not have? The user says they do have permission to write into their Python installation directory, so that's not it. The message they get is "You do not seem to have sufficient access rights on this machine to install this software". Status under Python 2.4.1 is unknown. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-07-11 18:55 Message: Logged In: YES user_id=21627 The message comes from PC\bdist_wininst\install.c:OpenLogFile, when attempting to write to Software\Microsoft\CurrentVersion\Uninstall. Whether this goes to HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE apparently depends on whether Python was installed per-user or per-machine. In the 2.4.1 version, in CheckRootKey, there is a HasLocalMachinePrivs function. Mark Hammond added this in install.c 1.6 in response to #555812 and #555810, so I'm declaring this bug fixed. -- Comment By: Tim Peters (tim_one) Date: 2005-07-08 20:59 Message: Logged In: YES user_id=31435 Bug 1232947 is about installing Python itself. This one is about installing a 3rd-party package that happens to use Python (a pre-existing Python), using a Windows installer created by Python's distutils package. It's unlikely the bugs have anything in common. -- Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-07-08 20:48 Message: Logged In: YES user_id=1307917 Did you see bug # 1232947? It provides documentation of another failing non-admin install. (2.4.1). -- Comment By: Tim Peters (tim_one) Date: 2005-07-08 19:11 Message: Logged In: YES user_id=31435 You should be able to try 2.4. The Python installer includes msvcr71.dll, and should install it into the Python directory (instead of into a system directory) is you do a "install just for me" (as opposed to "all users") install. -- Comment By: Alex (hairypalm) Date: 2005-07-08 18:36 Message: Logged In: YES user_id=1309592 I am the original "complainant". I cannot try python 2.4 install package because it requires MSVCR71.dll. I am "locked down" at work and cannot write files except to my own user area. I am also prevented from writing to some areas of the registry. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234850&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1235569 ] Inconsistent singleton constructor messages
Bugs item #1235569, was opened at 2005-07-10 05:18 Message generated for change (Comment added) made by ppergame You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent singleton constructor messages Initial Comment: Inconsistent TypeError strings: >>> types.NoneType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'NoneType' instances >>> types.EllipsisType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'ellipsis' instances -- >Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 11:30 Message: Logged In: YES user_id=595126 You wouldn't tolerate "TypeError: yuor fanction takes too mny arguements lol". The inconsistency looks unprofessional in the same way, if not magnitude. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-10 06:28 Message: Logged In: YES user_id=1188172 Where's your problem? If this doesn't cause any misbehaviour, I recommend closing this as Won't Fix. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-893549 ] skipitem() in getargs.c missing some types
Bugs item #893549, was opened at 2004-02-09 18:30 Message generated for change (Comment added) made by subik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893549&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.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirill A Kryloff (hacocuk) Assigned to: Nobody/Anonymous (nobody) Summary: skipitem() in getargs.c missing some types Initial Comment: python 2.2.3 looks like skipitem in getargs.c is missing some types 'k' for example -- Comment By: Petr Vaněk (subik) Date: 2005-07-11 21:06 Message: Logged In: YES user_id=784012 this bug is still presented in later versions 2.3, 2.4. We have real problem with it (see. http://bugs.scribus.net/view.php?id=2018). Broken PyArg_ParseTupleAndKeywords in skipitem() (getargs.c) causes "impossible" exception by missing case conditions. I would like to please developers for fixing (or we will be forced to provide a patch (which will force us to know Python guts (etc.))). -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 14:10 Message: Logged In: YES user_id=1188172 The missing types are u, u#, es, es#, et, et#, k, K, I, U, t#, w, w# and maybe (...) I don't know whether this is of any significance though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893549&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-893549 ] skipitem() in getargs.c missing some types
Bugs item #893549, was opened at 2004-02-10 01:30 Message generated for change (Comment added) made by ringerc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893549&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.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirill A Kryloff (hacocuk) Assigned to: Nobody/Anonymous (nobody) Summary: skipitem() in getargs.c missing some types Initial Comment: python 2.2.3 looks like skipitem in getargs.c is missing some types 'k' for example -- Comment By: Craig Ringer (ringerc) Date: 2005-07-12 03:08 Message: Logged In: YES user_id=639504 It matters all right. Just wasted a bunch of time tracking this down into the Python sources and confirming it was a Python bug. It's really nasty for 'es'. This will cause bizarre errors for PyArg_ParseTupleAndKeywords(...) calls using the unsupported format strings after the | optional argument barrier. The errors will always contain the string: impossible The error will, of course, only turn up if the user omits one or more of the arguments with unsupported formats. -- Comment By: Petr Vaněk (subik) Date: 2005-07-12 03:06 Message: Logged In: YES user_id=784012 this bug is still presented in later versions 2.3, 2.4. We have real problem with it (see. http://bugs.scribus.net/view.php?id=2018). Broken PyArg_ParseTupleAndKeywords in skipitem() (getargs.c) causes "impossible" exception by missing case conditions. I would like to please developers for fixing (or we will be forced to provide a patch (which will force us to know Python guts (etc.))). -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 20:10 Message: Logged In: YES user_id=1188172 The missing types are u, u#, es, es#, et, et#, k, K, I, U, t#, w, w# and maybe (...) I don't know whether this is of any significance though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893549&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-893549 ] skipitem() in getargs.c missing some types
Bugs item #893549, was opened at 2004-02-09 18:30 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893549&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.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirill A Kryloff (hacocuk) Assigned to: Nobody/Anonymous (nobody) Summary: skipitem() in getargs.c missing some types Initial Comment: python 2.2.3 looks like skipitem in getargs.c is missing some types 'k' for example -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-11 21:11 Message: Logged In: YES user_id=1188172 I submitted a patch (#1212928) which fixes that. -- Comment By: Craig Ringer (ringerc) Date: 2005-07-11 21:08 Message: Logged In: YES user_id=639504 It matters all right. Just wasted a bunch of time tracking this down into the Python sources and confirming it was a Python bug. It's really nasty for 'es'. This will cause bizarre errors for PyArg_ParseTupleAndKeywords(...) calls using the unsupported format strings after the | optional argument barrier. The errors will always contain the string: impossible The error will, of course, only turn up if the user omits one or more of the arguments with unsupported formats. -- Comment By: Petr Vaněk (subik) Date: 2005-07-11 21:06 Message: Logged In: YES user_id=784012 this bug is still presented in later versions 2.3, 2.4. We have real problem with it (see. http://bugs.scribus.net/view.php?id=2018). Broken PyArg_ParseTupleAndKeywords in skipitem() (getargs.c) causes "impossible" exception by missing case conditions. I would like to please developers for fixing (or we will be forced to provide a patch (which will force us to know Python guts (etc.))). -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 14:10 Message: Logged In: YES user_id=1188172 The missing types are u, u#, es, es#, et, et#, k, K, I, U, t#, w, w# and maybe (...) I don't know whether this is of any significance though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893549&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1235569 ] Inconsistent singleton constructor messages
Bugs item #1235569, was opened at 2005-07-10 08:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent singleton constructor messages Initial Comment: Inconsistent TypeError strings: >>> types.NoneType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'NoneType' instances >>> types.EllipsisType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'ellipsis' instances -- >Comment By: Tim Peters (tim_one) Date: 2005-07-11 16:17 Message: Logged In: YES user_id=31435 ppergame, could you please be explicit about what your complaint is here? I don't know what's bothering you either. For example, spell out the text for error messages you think would be OK. Your example: "fanction takes too mny arguements lol" seems meaningless here, since it appears to suggest you dislike spelling errors. That's fine, but there are no spelling errors in the messages you're complaining about. -- Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 14:30 Message: Logged In: YES user_id=595126 You wouldn't tolerate "TypeError: yuor fanction takes too mny arguements lol". The inconsistency looks unprofessional in the same way, if not magnitude. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-10 09:28 Message: Logged In: YES user_id=1188172 Where's your problem? If this doesn't cause any misbehaviour, I recommend closing this as Won't Fix. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1235569 ] Inconsistent singleton constructor messages
Bugs item #1235569, was opened at 2005-07-10 05:18 Message generated for change (Comment added) made by ppergame You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent singleton constructor messages Initial Comment: Inconsistent TypeError strings: >>> types.NoneType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'NoneType' instances >>> types.EllipsisType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'ellipsis' instances -- >Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 13:22 Message: Logged In: YES user_id=595126 Either the first error message should be changed to "TypeError: cannot create 'none' instances" or the second one should be "TypeError: cannot create 'EllipsisType' instances". I apologize for being unclear. -- Comment By: Tim Peters (tim_one) Date: 2005-07-11 13:17 Message: Logged In: YES user_id=31435 ppergame, could you please be explicit about what your complaint is here? I don't know what's bothering you either. For example, spell out the text for error messages you think would be OK. Your example: "fanction takes too mny arguements lol" seems meaningless here, since it appears to suggest you dislike spelling errors. That's fine, but there are no spelling errors in the messages you're complaining about. -- Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 11:30 Message: Logged In: YES user_id=595126 You wouldn't tolerate "TypeError: yuor fanction takes too mny arguements lol". The inconsistency looks unprofessional in the same way, if not magnitude. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-10 06:28 Message: Logged In: YES user_id=1188172 Where's your problem? If this doesn't cause any misbehaviour, I recommend closing this as Won't Fix. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1235569 ] Inconsistent singleton constructor messages
Bugs item #1235569, was opened at 2005-07-10 08:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent singleton constructor messages Initial Comment: Inconsistent TypeError strings: >>> types.NoneType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'NoneType' instances >>> types.EllipsisType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'ellipsis' instances -- >Comment By: Tim Peters (tim_one) Date: 2005-07-11 16:43 Message: Logged In: YES user_id=31435 Ah! Well, we shouldn't do that -- the messages currently give the correct names for the types: >>> type(None) >>> type(Ellipsis) The names types are exported under by types.py are pretty much arbitrary, but shouldn't be changed either because doing so would create backward compatibility headaches. -- Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 16:22 Message: Logged In: YES user_id=595126 Either the first error message should be changed to "TypeError: cannot create 'none' instances" or the second one should be "TypeError: cannot create 'EllipsisType' instances". I apologize for being unclear. -- Comment By: Tim Peters (tim_one) Date: 2005-07-11 16:17 Message: Logged In: YES user_id=31435 ppergame, could you please be explicit about what your complaint is here? I don't know what's bothering you either. For example, spell out the text for error messages you think would be OK. Your example: "fanction takes too mny arguements lol" seems meaningless here, since it appears to suggest you dislike spelling errors. That's fine, but there are no spelling errors in the messages you're complaining about. -- Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 14:30 Message: Logged In: YES user_id=595126 You wouldn't tolerate "TypeError: yuor fanction takes too mny arguements lol". The inconsistency looks unprofessional in the same way, if not magnitude. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-10 09:28 Message: Logged In: YES user_id=1188172 Where's your problem? If this doesn't cause any misbehaviour, I recommend closing this as Won't Fix. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&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-1003935 ] xrange overflows
Feature Requests item #1003935, was opened at 2004-08-05 15:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1003935&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Raymond Hettinger (rhettinger) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" formore information. >>> from sys import maxint >>> "%x" % maxint '7fff' -- >Comment By: Martin v. Löwis (loewis) Date: 2005-07-12 00:24 Message: Logged In: YES user_id=21627 Using xrange for an infinite loop qualifies as "cute" = "obviously straining for effect". The most natural way of an infinite loop is "while True". There are certainly other ways to express an infinite loop (like reading from /dev/zero, or writing an unbounded recursion), but arguing that xrange is "much faster" is obviously straining for effect: If the loop is infinite, how can it be much faster? And why does it matter if it is? (in my measurements, it is 30% faster, counting the time for a given number of iterations). -- Comment By: Hallvard B Furuseth (hfuru) Date: 2005-07-11 12:16 Message: Logged In: YES user_id=726647 What is "cute" about using maxint as an xrange() limit, and why would it impact its performance to return its 2nd parameter as endvalue +/- 1 (an int) instead of trying to return endvalue + step (which can be long)? -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-11 01:11 Message: Logged In: YES user_id=80475 Will look at it to see if there is something simple that can be done. These were design decisions -- xrange() and count() are supposed to be simple and fast -- with other tools being preferred if you are pushing beyond the limit of normal use cases. IOW, it is not worth crippling their performance just because someone has discovered cute ways of using sys.maxint. -- Comment By: Tim Peters (tim_one) Date: 2005-07-10 23:19 Message: Logged In: YES user_id=31435 Unassigned myself, since I don't plan to do anything else here. -- Comment By: Connelly (connelly) Date: 2004-12-06 08:04 Message: Logged In: YES user_id=1039782 Yes, I run into this bug all the time. For example, I may want to generate all strings of length n: BINARY_CHARSET = ''.join([chr(i) for i in range(256)]) def all_strs(n, charset=BINARY_CHARSET): m = len(charset) for i in xrange(m**n): yield ''.join([charset[i//m**j%m] for j in range(n)]) This is correct algorithmically, but fails due to the buggy Python xrange() function. So I end up writing my own irange () function. Other cases where I've run into this problem: Sieving for primes starting at a given large prime, checking for integer solutions to an equation starting with a large integer, and searching very large integer sets. itertools.count and itertools.repeat are similarly annoying. Often I want to search the list of all positive integers starting with 1, and have to use an awkward while loop to do this, or write my own replacement for itertools.count. There should be little performance hit for apps which use xrange(n), where n fits in the system's integer size. xrange () can just return an iterator which returns system ints, and the only performance penalty is an extra if statement in the call to xrange (and there is no performance penalty in the iterator's next() method). Finally, this move appears consistent with Python's values, ie simplicity, long ints supported with no
[ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix
Bugs item #1233785, was opened at 2005-07-07 09:36
Message generated for change (Comment added) made by esrever_otua
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Darryl Dixon (esrever_otua)
Assigned to: Nobody/Anonymous (nobody)
Summary: getpass.getpass() performs differently on Windows vs *nix
Initial Comment:
getpass.getpass() on *nix platforms allows users to
input unicode characters and other NLS input.
getpass.getpass() on Windows only allows ASCII input in
the 0-127 codepage range. This means that getpass can
not be used cross-platform for complex passwords.
--
>Comment By: Darryl Dixon (esrever_otua)
Date: 2005-07-12 12:56
Message:
Logged In: YES
user_id=567623
Following on from earlier code; the code below implements a
complete C module for Python that provides a 'getpass'
implementation for windows that behaves similarly to
existing getpass (accepts a prompt, returns a string without
newlines). I'm not a fantastic C coder, so this is really
just to provide ideas.
/*
* This file is part of 'win32console'
* Copyright 2005 Darryl A. Dixon
<[EMAIL PROTECTED]>
*/
#include
#include
#include "Python.h"
#define LINE_BUF 1024 * sizeof(TCHAR)
#define CHAR_BUF 6 * sizeof(TCHAR)
/* Module globals */
static PyObject *getpass_error = NULL;
static PyObject *getpass(self, args)
PyObject *self, *args;
{
char *prompt = "Password: ";
char *newline = "\r\n";
if (PyArg_ParseTuple(args, "|s", &prompt)){
HANDLE hstdin, hstdout;
DWORD read_chars, mode, written_chars;
char inchars[LINE_BUF];
hstdout = GetStdHandle(STD_OUTPUT_HANDLE);
WriteConsole(hstdout,
prompt,
strlen(prompt),
&written_chars,
NULL);
hstdin = GetStdHandle(STD_INPUT_HANDLE);
GetConsoleMode(hstdin,
&mode);
SetConsoleMode(hstdin,
ENABLE_LINE_INPUT |
ENABLE_PROCESSED_INPUT);
/* Hmm, is allowing threads to run while we're
playing with the flags on
* STDIN such a good idea? ...Who knows... */
Py_BEGIN_ALLOW_THREADS
ReadConsole(hstdin,
inchars,
LINE_BUF,
&read_chars,
NULL);
Py_END_ALLOW_THREADS
SetConsoleMode(hstdin,
mode);
WriteConsole(hstdout,
newline,
strlen(newline),
&written_chars,
NULL);
/* -2 to strip the \015\012 from the end
-v */
return PyString_FromStringAndSize(inchars,
read_chars-2);
}else{
return NULL;
}
}
static PyObject *getch(self, args)
PyObject *self, *args;
{
if (PyArg_ParseTuple(args, "")){
HANDLE hstdin;
DWORD read_chars, mode;
char inchars[CHAR_BUF];
hstdin = GetStdHandle(STD_INPUT_HANDLE);
GetConsoleMode(hstdin,
&mode);
SetConsoleMode(hstdin,
ENABLE_PROCESSED_INPUT);
Py_BEGIN_ALLOW_THREADS
ReadConsole(hstdin,
inchars,
CHAR_BUF,
&read_chars,
NULL);
Py_END_ALLOW_THREADS
SetConsoleMode(hstdin,
mode);
/* this should generally always be 1 --v */
return PyString_FromStringAndSize(inchars, read_chars);
}else{
return NULL;
}
}
static PyMethodDef methods[] = {
{"getpass", getpass, METH_VARARGS},
{"getch", getch, METH_VARARGS},
{NULL, NULL},
};
void init_win32console(){
PyObject *mod, *dict;
mod = Py_InitModule("_win32console", methods);
dict = PyModule_GetDict(mod);
#if PYTHON_API_VERSION >= 1007
getpass_error = PyErr_NewException("getpass.error",
NULL, NULL);
#else
getpass_error = Py_BuildValue("s", "getpass.error");
#endif
PyDict_SetItemString(dict, "error", getpass_error);
}
--
Comment By: Darryl Dixon (esrever_otua)
Date: 2005-07-07 22:42
Message:
Logged In: YES
user_id=567623
I am not an expert C coder (no surprise) however this simple
code I wrote will accept a line of input (including the \r\n
on the end) without echoing it back to the user:
#include
#define LINE_BUF 65536
char *getstr(){
/*
* OK, basically, we get a handle to STDIN, take a copy
of the
* flags currently in force, set our own to prevent
screen echo,
* do a read of the console that ret
[ python-Bugs-1235569 ] Inconsistent singleton constructor messages
Bugs item #1235569, was opened at 2005-07-10 07:18 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&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.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent singleton constructor messages Initial Comment: Inconsistent TypeError strings: >>> types.NoneType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'NoneType' instances >>> types.EllipsisType() Traceback (most recent call last): File "", line 1, in ? TypeError: cannot create 'ellipsis' instances -- Comment By: Tim Peters (tim_one) Date: 2005-07-11 15:43 Message: Logged In: YES user_id=31435 Ah! Well, we shouldn't do that -- the messages currently give the correct names for the types: >>> type(None) >>> type(Ellipsis) The names types are exported under by types.py are pretty much arbitrary, but shouldn't be changed either because doing so would create backward compatibility headaches. -- Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 15:22 Message: Logged In: YES user_id=595126 Either the first error message should be changed to "TypeError: cannot create 'none' instances" or the second one should be "TypeError: cannot create 'EllipsisType' instances". I apologize for being unclear. -- Comment By: Tim Peters (tim_one) Date: 2005-07-11 15:17 Message: Logged In: YES user_id=31435 ppergame, could you please be explicit about what your complaint is here? I don't know what's bothering you either. For example, spell out the text for error messages you think would be OK. Your example: "fanction takes too mny arguements lol" seems meaningless here, since it appears to suggest you dislike spelling errors. That's fine, but there are no spelling errors in the messages you're complaining about. -- Comment By: Pavel Pergamenshchik (ppergame) Date: 2005-07-11 13:30 Message: Logged In: YES user_id=595126 You wouldn't tolerate "TypeError: yuor fanction takes too mny arguements lol". The inconsistency looks unprofessional in the same way, if not magnitude. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-10 08:28 Message: Logged In: YES user_id=1188172 Where's your problem? If this doesn't cause any misbehaviour, I recommend closing this as Won't Fix. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235569&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent
Bugs item #1235266, was opened at 2005-07-09 11:24 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&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.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: debug info file descriptor of tarfile is inconsistent Initial Comment: "7.19.1 TarFile Objects" says The messages are written to sys.stdout. but they are actually written to sys.stderr :: def _dbg(self, level, msg): """Write debugging output to sys.stderr. """ if level <= self.debug: print >> sys.stderr, msg There are 2 options: (a) change document from stdout to stderr. (b) rewrite the code to use stdout. Given this is debug messages and most other modules use stdout for debug printing(gc is one of the few exceptions?), I'm +1 on (b). [*] http://docs.python.org/lib/tarfile-objects.html -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-11 22:06 Message: Logged In: YES user_id=80475 Just change the docs to match the actual behavior. Let's leave the implementation alone. There is no great need to have tarfile's implementation match zipfile. Someday, all of the modules will generate messages via the logging module and you'll trivially be able to mask them or redirect them in a consistent manner. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-11 01:19 Message: Logged In: YES user_id=1188172 Attaching patches for both tarfile and zipfile. For tarfile, the docs are changed to stderr, for zipfile, both docs and implementation are changed to stderr. Since I don't assume that someone actually uses the debug info in some automated way, I think we can correct this in 2.5. Raymond, please review. -- Comment By: George Yoshida (quiver) Date: 2005-07-10 11:26 Message: Logged In: YES user_id=671362 OK. I tested some GNU compression/decompression tools and comfirmed that they write debugging messages (displayed in verbose mode(-v)) to stderr. Now I'm leaning toward Reinhold's idea. > What about zipfile? > Should we print debug info to stderr there, too? Maybe yes. I'd be happy to volunteer for that patch. -- Comment By: Lars Gustäbel (gustaebel) Date: 2005-07-10 03:00 Message: Logged In: YES user_id=642936 This is a documentation error. Debug messages must go to stderr because that's what stderr is for. Think of a script that writes a tar archive to stdout for use in a unix shell pipeline. If debug messages went to stdout, too, it would produce unusable output, because archive data and debug messages would be mixed. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-09 12:04 Message: Logged In: YES user_id=1188172 The documentation seems to be borrowed from zipfile, where the statement is true: debug info is written to stdout. I'm in favour of changing the docs to stderr for tarfile. What about zipfile? Should we print debug info to stderr there, too? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1229429 ] missing Py_DECREF in PyObject_CallMethod
Bugs item #1229429, was opened at 2005-06-28 21:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Gary (gdray-1) >Assigned to: Michael Hudson (mwh) Summary: missing Py_DECREF in PyObject_CallMethod Initial Comment: Once PyObject *func has been successfully returned by PyObject_GetAttrString(), the ref count is not decremented by any of the error exit cases from PyObject_CallMethod(). After the check that func is not NULL, there are four error case exits that do not decrement the ref count on func. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-11 22:08 Message: Logged In: YES user_id=80475 Assigning to the god of leak fixes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229429&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
