[ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1
Bugs item #1178484, was opened at 2005-04-07 14:33 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Timo Linna (tilinna) Assigned to: Martin v. Löwis (loewis) Summary: Erroneous line number error in Py2.4.1 Initial Comment: For some reason Python 2.3.5 reports the error in the following program correctly: File "C:\Temp\problem.py", line 7 SyntaxError: unknown decode error ..whereas Python 2.4.1 reports an invalid line number: File "C:\Temp\problem.py", line 2 SyntaxError: unknown decode error - problem.py starts - # -*- coding: ascii -*- """ Foo bar """ # Ä is not allowed in ascii coding - problem.py ends - Without the encoding declaration both Python versions report the usual deprecation warning (just like they should be doing). My environment: Windows 2000 + SP3. -- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-18 11:31 Message: Logged In: YES user_id=38388 Walter, as I've said before: I know that you need buffering for the UTF-x readline support, but I don't see a requirement for it in most of the other codecs. E.g. an ascii codec or latin-1 codec will only ever see standard line ends (not Unicode ones), so the streams .readline() method can be used directly - just like we did before the buffering code was added. Your argument about applications making implications on the file position after having used .readline() is true, but still many applications rely on this behavior which is not as far fetched as it may seem given that they normally only expect 8-bit data. Wouldn't it make things a lot safer if we only use buffering per default in the UTF-x codecs and revert back to the old non-buffered behavior for the other codecs which has worked well in the past ?! About your patch: * Please explain what firstline is supposed to do (preferably in the doc-string). * Why is firstline always set in .readline() ? * Please remove the print repr() * You cannot always be sure that exc has a .start attribute, so you need to accomocate for this situation as well -- Comment By: Walter Dörwald (doerwalter) Date: 2005-05-17 18:50 Message: Logged In: YES user_id=89016 It isn't the buffering support per se that breaks the tokenizer. This problem exists even in Python 2.3.x (Simply try the test scripts from http://www.python.org/sf/1089395 with Python 2.3.5 and you'll get a segfault). Applications that rely on len(readline(x)) == x or anything similar are broken anyway. Supporting buffered and unbuffered reading would mean keeping the 2.3 mode of doing things around indefinitely, and we'd loose readline() support for UTF-16 again. BTW, applying Greg Chapman's patch (http://www.python.org/sf/1101726, which fixes the tokenizer) together with this one seems to fix the problem from my previous post. So if you could give http://www.python.org/sf/1101726 a third look, so we can get it into 2.4.2, this would be great. -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-05-17 11:13 Message: Logged In: YES user_id=38388 Walter, I think that instead of trying to get the tokenizer to work with the buffer support in the codecs, you should add a flag that allows to switch off the buffer support in the codecs altogether and then use the unbuffered mode codecs in the tokenizer. I expect that other applications will run into the same kind of problem, so it should be possible to switch off buffering if needed (maybe we should make this the default ?!). -- Comment By: Walter Dörwald (doerwalter) Date: 2005-05-16 10:35 Message: Logged In: YES user_id=89016 OK, here is a patch. It adds an additional argument firstline to read(). If this argument is true (i.e. if called from readline()) and a decoding error happens, this error will only be reported if it is in the first line. Otherwise read() will decode up to the error position and put the rest in the bytebuffer. Unfortunately with this patch, I get a segfault with the following stacktrace if I run the test. I don't know if this is related to bug #1089395/patch #1101726. Martin, can you take a look? #0 0x08057ad1 in tok_nextc (tok=0x81ca7b0) at tokenizer.c:719 #1 0x08058558 in tok_get (tok=0x81ca7b0, p_start=0xb3d4, p_end=0xb3d0) at tokenizer.c:1075 #2 0x08059331 in PyTokenizer_Get (tok=0x81ca7b0, p_start=0xb3d4, p_end=0xb3d0) at tokenizer.c:1466 #3 0x080561b1 in parsetok (tok=0x81ca7b0, g=0x8167980, start=257, err_ret=0xb440, flags=0) at parsetok.c:125 #4 0x0805613c in PyParser_ParseFileFlags (fp=0
[ python-Bugs-1202946 ] Problem with abs function
Bugs item #1202946, was opened at 2005-05-17 02:32 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ric-b (ric-b) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with abs function Initial Comment: On windows version I get : >>> abs(-999) Traceback (most recent call last): File "", line 1, in -toplevel- abs(-999) OverflowError: long too big to convert does not handle new longs. I am using the following work around: t = a - b # calc t = abs(a - b) if t < 0 : t *= -1 -- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-18 21:53 Message: Logged In: YES user_id=1038590 I tried the OP's example in wxPython's PyShell as well as in the standard interpreter, and got the same result as Raymond. However, I was able to provoke a similar looking error by trying to convert a large long to a float (and the exception is telling the plain truth - a double precision float can't handle a number that big): Py> num = 1.0 Py> lng = -9 Py> num += abs(lng) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-17 03:33 Message: Logged In: YES user_id=80475 That's odd. It works for me: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> abs(-999) 999L -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump)
Bugs item #1201456, was opened at 2005-05-14 01:43
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Vladimir Yu. Stepanov (vys)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with recursion in dict (crash with core dump)
Initial Comment:
Please see example code.
--
>Comment By: Nick Coghlan (ncoghlan)
Date: 2005-05-18 22:15
Message:
Logged In: YES
user_id=1038590
What does sys.getrecursionlimit() return?
Does the buggy code generate the expected exception if you
use sys.setrecursionlimit() to make the value smaller (e.g.
500)?
FreeBSD has a history of not playing well with CPython's
ability to detect inifinite recursion. . .
--
Comment By: Vladimir Yu. Stepanov (vys)
Date: 2005-05-14 02:06
Message:
Logged In: YES
user_id=384980
This is output from `uname -a`:
FreeBSD fox.renet.ru 5.3-RELEASE FreeBSD 5.3-RELEASE
#1: Fri Apr 15 10:38:49 MSD 2005
[EMAIL PROTECTED]:/M/safedir/src/sys/i386/compile/FOX i386
I get some others with this code:
Python 2.4.1 (#2, Apr 26 2005, 14:16:31)
[GCC 3.4.2 [FreeBSD] 20040728] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>> d = {}
>>>
>>> class test:
... def __hash__(self):
... d[self] = None
...
>>> d[test()] = None
Bus error (core dumped)
fox:vys!~ > gdb python python.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show
warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no
debugging symbols found)...
Core was generated by `python'.
Program terminated with signal 10, Bus error.
(gdb) where
#0 0x2828b3b1 in ldexp () from /lib/libc.so.5
#1 0x2828b618 in malloc () from /lib/libc.so.5
#2 0x080bdca1 in _PyObject_GC_Malloc ()
#3 0x080bdd4a in _PyObject_GC_New ()
#4 0x0805f556 in PyMethod_New ()
#5 0x0805c1a6 in PyInstance_NewRaw ()
#6 0x0805c66a in PyInstance_New ()
#7 0x0805cca1 in _PyInstance_Lookup ()
#8 0x080703e6 in PyDict_SetItem ()
#9 0x0809bb0e in PyEval_EvalFrame ()
#10 0x0809fc20 in PyEval_EvalCodeEx ()
#11 0x080d4d66 in PyFunction_SetClosure ()
#12 0x0805a38c in PyObject_Call ()
#13 0x0805fbe2 in PyMethod_New ()
#14 0x0805a38c in PyObject_Call ()
#15 0x08099f1b in PyEval_CallObjectWithKeywords ()
#16 0x0805ccb9 in _PyInstance_Lookup ()
#17 0x080703e6 in PyDict_SetItem ()
#18 0x0809bb0e in PyEval_EvalFrame ()
#19 0x0809fc20 in PyEval_EvalCodeEx ()
#20 0x080d4d66 in PyFunction_SetClosure ()
#21 0x0805a38c in PyObject_Call ()
#22 0x0805fbe2 in PyMethod_New ()
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-05-14 01:55
Message:
Logged In: YES
user_id=80475
I get the expected behavior:
RuntimeError: maximum recursion depth exceeded
--
Comment By: Michael Hudson (mwh)
Date: 2005-05-14 01:55
Message:
Logged In: YES
user_id=6656
I get an infinite recursion runtime error. What platform
are you on?
--
Comment By: Vladimir Yu. Stepanov (vys)
Date: 2005-05-14 01:46
Message:
Logged In: YES
user_id=384980
d = {}
class test:
def __hash__(self):
d[self] = None
d[test()] = None
--
Comment By: Michael Hudson (mwh)
Date: 2005-05-14 01:46
Message:
Logged In: YES
user_id=6656
I see no code. SF can be a pain with this...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump)
Bugs item #1201456, was opened at 2005-05-13 19:43
Message generated for change (Comment added) made by vys
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Vladimir Yu. Stepanov (vys)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with recursion in dict (crash with core dump)
Initial Comment:
Please see example code.
--
>Comment By: Vladimir Yu. Stepanov (vys)
Date: 2005-05-18 17:05
Message:
Logged In: YES
user_id=384980
sys.getrecursionlimit() returns 1000.
I set sys.setrecursionlimit() to 500 and problem was resolved :)
Thank you very much !
PS. Is it possible to add some checks in Py_SetRecursionLimit
to reject overflow values ?
--
Comment By: Nick Coghlan (ncoghlan)
Date: 2005-05-18 16:15
Message:
Logged In: YES
user_id=1038590
What does sys.getrecursionlimit() return?
Does the buggy code generate the expected exception if you
use sys.setrecursionlimit() to make the value smaller (e.g.
500)?
FreeBSD has a history of not playing well with CPython's
ability to detect inifinite recursion. . .
--
Comment By: Vladimir Yu. Stepanov (vys)
Date: 2005-05-13 20:06
Message:
Logged In: YES
user_id=384980
This is output from `uname -a`:
FreeBSD fox.renet.ru 5.3-RELEASE FreeBSD 5.3-RELEASE
#1: Fri Apr 15 10:38:49 MSD 2005
[EMAIL PROTECTED]:/M/safedir/src/sys/i386/compile/FOX i386
I get some others with this code:
Python 2.4.1 (#2, Apr 26 2005, 14:16:31)
[GCC 3.4.2 [FreeBSD] 20040728] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>> d = {}
>>>
>>> class test:
... def __hash__(self):
... d[self] = None
...
>>> d[test()] = None
Bus error (core dumped)
fox:vys!~ > gdb python python.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show
warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no
debugging symbols found)...
Core was generated by `python'.
Program terminated with signal 10, Bus error.
(gdb) where
#0 0x2828b3b1 in ldexp () from /lib/libc.so.5
#1 0x2828b618 in malloc () from /lib/libc.so.5
#2 0x080bdca1 in _PyObject_GC_Malloc ()
#3 0x080bdd4a in _PyObject_GC_New ()
#4 0x0805f556 in PyMethod_New ()
#5 0x0805c1a6 in PyInstance_NewRaw ()
#6 0x0805c66a in PyInstance_New ()
#7 0x0805cca1 in _PyInstance_Lookup ()
#8 0x080703e6 in PyDict_SetItem ()
#9 0x0809bb0e in PyEval_EvalFrame ()
#10 0x0809fc20 in PyEval_EvalCodeEx ()
#11 0x080d4d66 in PyFunction_SetClosure ()
#12 0x0805a38c in PyObject_Call ()
#13 0x0805fbe2 in PyMethod_New ()
#14 0x0805a38c in PyObject_Call ()
#15 0x08099f1b in PyEval_CallObjectWithKeywords ()
#16 0x0805ccb9 in _PyInstance_Lookup ()
#17 0x080703e6 in PyDict_SetItem ()
#18 0x0809bb0e in PyEval_EvalFrame ()
#19 0x0809fc20 in PyEval_EvalCodeEx ()
#20 0x080d4d66 in PyFunction_SetClosure ()
#21 0x0805a38c in PyObject_Call ()
#22 0x0805fbe2 in PyMethod_New ()
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-05-13 19:55
Message:
Logged In: YES
user_id=80475
I get the expected behavior:
RuntimeError: maximum recursion depth exceeded
--
Comment By: Michael Hudson (mwh)
Date: 2005-05-13 19:55
Message:
Logged In: YES
user_id=6656
I get an infinite recursion runtime error. What platform
are you on?
--
Comment By: Vladimir Yu. Stepanov (vys)
Date: 2005-05-13 19:46
Message:
Logged In: YES
user_id=384980
d = {}
class test:
def __hash__(self):
d[self] = None
d[test()] = None
--
Comment By: Michael Hudson (mwh)
Date: 2005-05-13 19:46
Message:
Logged In: YES
user_id=6656
I see no code. SF can be a pain with this...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1200686 ] SyntaxError raised on win32 for correct files
Bugs item #1200686, was opened at 2005-05-12 06:19
Message generated for change (Comment added) made by glchapman
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Federico Di Gregorio (fog)
Assigned to: Nobody/Anonymous (nobody)
Summary: SyntaxError raised on win32 for correct files
Initial Comment:
Try to import the attached file (dt.py) on Windows with
Python 2.4 or 2.4.1 and you'll get a SyntaxError (the
file was written a long time ago, and worked perfectly
well on Python 2.1, 2.2 and 2.3.) The same does not
happen when importing the same module on Linux (tested
with 2.4 and 2.4.1). When the module imports fine
you'll get an ImportError (don't want to attach all
dependencies here) but the SyntaxError comes before that.
Also note that compiling the file with
compiler.compileFile("dt.py") generates a perfectly
good .pyc file that can be later imported just fine
(tested with 2.4 and 2.4.1 on Windows).
--
Comment By: Greg Chapman (glchapman)
Date: 2005-05-18 06:15
Message:
Logged In: YES
user_id=86307
I'm fairly sure this is caused by the bug described here:
www.python.org/sf/1175396
The module imports without syntax error on my Windows system
(with a patched codecs.py to work around the above bug).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&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-1200804 ] enhancing os.chown functionality
Feature Requests item #1200804, was opened at 2005-05-12 11:26 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1200804&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: gyrof (gyrof) Assigned to: Nobody/Anonymous (nobody) Summary: enhancing os.chown functionality Initial Comment: Hi, I don't think it is currently possible (with os.chown or any other Python library function) to change the groupId of a file without specifying the userId (like posix 'chgrp' does), or to change the userId without specifying the groupId. I would suggest adding the option of having os.chown accept None as either the userId or groupId, and having the function change only the 'non-None' portion of the file ownership. Thanks for your consideration. -g -- Comment By: Jeff Epler (jepler) Date: 2005-05-18 17:49 Message: Logged In: YES user_id=2772 the posix (os) module is intended as a thin wrapper around operating system services. The chown(2) syscall requires that owner and group both be specified. Possibly an enhanced chownonly/chgrp would find a home in the 'shutil' module. Possibly translating a parameter of None into -1 (which means 'no change') would be accepted as a patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1200804&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1199808 ] installation problem with python 2.4.1 on Win2k system
Bugs item #1199808, was opened at 2005-05-11 08:50 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: mmkobayashi (mmkobayashi) Assigned to: Nobody/Anonymous (nobody) Summary: installation problem with python 2.4.1 on Win2k system Initial Comment: After several attempts to install python2.4.1 on a win2k systems with doing all windows updates, we have been unable to install python2.4.1 on this system. We have attached an error logfile. The main thing that happens is that the install proceeds as normal but at some point the install decides that something has gone wrong and uninstalls itself. Any help in this matter would be greatly appreciated. -- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 20:48 Message: Logged In: YES user_id=593130 Help questions should better be directed to comp.lang.python == python mailing list == gmane.comp.python.general. The answers you get should help determine whether there is a bug in the install file distributed by PSF that should be reported here. Given that the install appeared to go ok until it tried to remove the existing files, I wonder whether there is a process running in the background that is using the existing install. That issue has been discussed on the python group recently. -- Comment By: mmkobayashi (mmkobayashi) Date: 2005-05-12 01:53 Message: Logged In: YES user_id=1273313 add file -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1199808 ] installation problem with python 2.4.1 on Win2k system
Bugs item #1199808, was opened at 2005-05-11 08:50 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: mmkobayashi (mmkobayashi) Assigned to: Nobody/Anonymous (nobody) Summary: installation problem with python 2.4.1 on Win2k system Initial Comment: After several attempts to install python2.4.1 on a win2k systems with doing all windows updates, we have been unable to install python2.4.1 on this system. We have attached an error logfile. The main thing that happens is that the install proceeds as normal but at some point the install decides that something has gone wrong and uninstalls itself. Any help in this matter would be greatly appreciated. -- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 21:01 Message: Logged In: YES user_id=593130 You might also check out http://python.org/sf/1199947 -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 20:48 Message: Logged In: YES user_id=593130 Help questions should better be directed to comp.lang.python == python mailing list == gmane.comp.python.general. The answers you get should help determine whether there is a bug in the install file distributed by PSF that should be reported here. Given that the install appeared to go ok until it tried to remove the existing files, I wonder whether there is a process running in the background that is using the existing install. That issue has been discussed on the python group recently. -- Comment By: mmkobayashi (mmkobayashi) Date: 2005-05-12 01:53 Message: Logged In: YES user_id=1273313 add file -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1200287 ] Windows msi installer fails on virtual drives
Bugs item #1200287, was opened at 2005-05-11 20:55 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200287&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: bartgrantham (bartgrantham) Assigned to: Nobody/Anonymous (nobody) Summary: Windows msi installer fails on virtual drives Initial Comment: The MSI installer for 2.4.1 failed to install from a virtual drive under windows (ie. a drive created with subst). It would error out without an error code, immediately after package selection and before "thinking...". Not sure if this also applies to network mapped drives. Moving installer to genuine C: drive and running from there fixed the problem. -- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 21:03 Message: Logged In: YES user_id=593130 This is almost certainly not a Python bug. See http://python.org/sf/1199947 Please close unless you see a particular bug with Python. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200287&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202395 ] Description of string.lstrip() needs improvement
Bugs item #1202395, was opened at 2005-05-15 13:50 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Description of string.lstrip() needs improvement Initial Comment: In http://docs.python.org/lib/string-methods.html, under lstrip(), it says, "chars must be a string; the characters in the string will be stripped from the beginning of the string this method is called on". It would be clearer if it said: "chars must be a string; the characters in the string constitute a set of characters to be stripped from the beginning of the string this method is called on". Similarly for rstrip() and strip(). There was a recent posting to comp.lang.python where it appears that the poster thought the argument to lstrip() was a leading string to be removed, not a set of characters. -- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 21:18 Message: Logged In: YES user_id=593130 Over the years, several people have tripped over this and posted to c.l.p., so I think the existing text is unclear enough to arguably qualify as a buglet. In response to the same posting, I had the same thought of clarifying that the 'string' defines a set, so I support this suggestion or something similar ;-) and thank you for submitting it. -- Comment By: Roy Smith (roysmith) Date: 2005-05-15 13:55 Message: Logged In: YES user_id=390499 I notice bug #1196824 (recently submitted and closed as "not a bug") relates to the same issue. It seems more than one person has gotten confused by this :-) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 19:43 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 Category: Python Interpreter Core Group: None Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault -- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 22:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202946 ] Problem with abs function
Bugs item #1202946, was opened at 2005-05-16 12:32 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ric-b (ric-b) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with abs function Initial Comment: On windows version I get : >>> abs(-999) Traceback (most recent call last): File "", line 1, in -toplevel- abs(-999) OverflowError: long too big to convert does not handle new longs. I am using the following work around: t = a - b # calc t = abs(a - b) if t < 0 : t *= -1 -- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 22:10 Message: Logged In: YES user_id=593130 Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> abs(-999) 999L Ric-b: what windows version? Even older? If the problem is not with current or future (cvs) Python, please close this. -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-18 07:53 Message: Logged In: YES user_id=1038590 I tried the OP's example in wxPython's PyShell as well as in the standard interpreter, and got the same result as Raymond. However, I was able to provoke a similar looking error by trying to convert a large long to a float (and the exception is telling the plain truth - a double precision float can't handle a number that big): Py> num = 1.0 Py> lng = -9 Py> num += abs(lng) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-16 13:33 Message: Logged In: YES user_id=80475 That's odd. It works for me: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> abs(-999) 999L -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump)
Bugs item #1201456, was opened at 2005-05-13 11:43
Message generated for change (Settings changed) made by tjreedy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Vladimir Yu. Stepanov (vys)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with recursion in dict (crash with core dump)
Initial Comment:
Please see example code.
--
Comment By: Vladimir Yu. Stepanov (vys)
Date: 2005-05-18 09:05
Message:
Logged In: YES
user_id=384980
sys.getrecursionlimit() returns 1000.
I set sys.setrecursionlimit() to 500 and problem was resolved :)
Thank you very much !
PS. Is it possible to add some checks in Py_SetRecursionLimit
to reject overflow values ?
--
Comment By: Nick Coghlan (ncoghlan)
Date: 2005-05-18 08:15
Message:
Logged In: YES
user_id=1038590
What does sys.getrecursionlimit() return?
Does the buggy code generate the expected exception if you
use sys.setrecursionlimit() to make the value smaller (e.g.
500)?
FreeBSD has a history of not playing well with CPython's
ability to detect inifinite recursion. . .
--
Comment By: Vladimir Yu. Stepanov (vys)
Date: 2005-05-13 12:06
Message:
Logged In: YES
user_id=384980
This is output from `uname -a`:
FreeBSD fox.renet.ru 5.3-RELEASE FreeBSD 5.3-RELEASE
#1: Fri Apr 15 10:38:49 MSD 2005
[EMAIL PROTECTED]:/M/safedir/src/sys/i386/compile/FOX i386
I get some others with this code:
Python 2.4.1 (#2, Apr 26 2005, 14:16:31)
[GCC 3.4.2 [FreeBSD] 20040728] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>> d = {}
>>>
>>> class test:
... def __hash__(self):
... d[self] = None
...
>>> d[test()] = None
Bus error (core dumped)
fox:vys!~ > gdb python python.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show
warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no
debugging symbols found)...
Core was generated by `python'.
Program terminated with signal 10, Bus error.
(gdb) where
#0 0x2828b3b1 in ldexp () from /lib/libc.so.5
#1 0x2828b618 in malloc () from /lib/libc.so.5
#2 0x080bdca1 in _PyObject_GC_Malloc ()
#3 0x080bdd4a in _PyObject_GC_New ()
#4 0x0805f556 in PyMethod_New ()
#5 0x0805c1a6 in PyInstance_NewRaw ()
#6 0x0805c66a in PyInstance_New ()
#7 0x0805cca1 in _PyInstance_Lookup ()
#8 0x080703e6 in PyDict_SetItem ()
#9 0x0809bb0e in PyEval_EvalFrame ()
#10 0x0809fc20 in PyEval_EvalCodeEx ()
#11 0x080d4d66 in PyFunction_SetClosure ()
#12 0x0805a38c in PyObject_Call ()
#13 0x0805fbe2 in PyMethod_New ()
#14 0x0805a38c in PyObject_Call ()
#15 0x08099f1b in PyEval_CallObjectWithKeywords ()
#16 0x0805ccb9 in _PyInstance_Lookup ()
#17 0x080703e6 in PyDict_SetItem ()
#18 0x0809bb0e in PyEval_EvalFrame ()
#19 0x0809fc20 in PyEval_EvalCodeEx ()
#20 0x080d4d66 in PyFunction_SetClosure ()
#21 0x0805a38c in PyObject_Call ()
#22 0x0805fbe2 in PyMethod_New ()
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-05-13 11:55
Message:
Logged In: YES
user_id=80475
I get the expected behavior:
RuntimeError: maximum recursion depth exceeded
--
Comment By: Michael Hudson (mwh)
Date: 2005-05-13 11:55
Message:
Logged In: YES
user_id=6656
I get an infinite recursion runtime error. What platform
are you on?
--
Comment By: Vladimir Yu. Stepanov (vys)
Date: 2005-05-13 11:46
Message:
Logged In: YES
user_id=384980
d = {}
class test:
def __hash__(self):
d[self] = None
d[test()] = None
--
Comment By: Michael Hudson (mwh)
Date: 2005-05-13 11:46
Message:
Logged In: YES
user_id=6656
I see no code. SF can be a pain with this...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1204734 ] Documentation error?
Bugs item #1204734, was opened at 2005-05-18 22:21 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=1204734&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Eikenberry (zhar) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation error? Initial Comment: >From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html "Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)." But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux. class A(object): def __getattr__(self,key): print '__getattr__',key raise AttributeError,key def __getattribute__(self,key): print '__getattribute__',key raise AttributeError,key a = A() a.foo $ python test.py __getattribute__ foo __getattr__ foo Traceback (most recent call last): File "test.py", line 14, in ? a.foo File "test.py", line 7, in __getattr__ raise AttributeError(key) AttributeError: foo It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
