[ python-Bugs-1224621 ] tokenize module does not detect inconsistent dedents
Bugs item #1224621, was opened at 2005-06-21 01:10 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224621&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 Submitted By: Danny Yoo (dyoo) >Assigned to: Raymond Hettinger (rhettinger) Summary: tokenize module does not detect inconsistent dedents Initial Comment: The attached code snippet 'testcase.py' should produce an IndentationError, but does not. The code in tokenize.py is too trusting, and needs to add a check against bad indentation as it yields DEDENT tokens. I'm including a diff to tokenize.py that should at least raise an exception on bad indentation like this. Just in case, I'm including testcase.py here too: -- import tokenize from StringIO import StringIO sampleBadText = """ def foo(): bar baz """ print list(tokenize.generate_tokens( StringIO(sampleBadText).readline)) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224621&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1224672 ] rsplit introduces spurious CR
Bugs item #1224672, was opened at 2005-06-21 07:47 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=1224672&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: Richard Prosser (rprosser) Assigned to: Nobody/Anonymous (nobody) Summary: rsplit introduces spurious CR Initial Comment: Using ActiveState Python 2.4.1 on "SunOS svpadm03 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-60", it seems that the new rsplit() adds a '\r' character at the end of the field. This was not present in the original data, so I suspect that there is a bug. Attachment gives partial script - I cannot upload the whole file for copyright reasons. However the process should be pretty clear, and it should be possible to arrange a test on a local machine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224672&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1224621 ] tokenize module does not detect inconsistent dedents
Bugs item #1224621, was opened at 2005-06-21 01:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224621&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Danny Yoo (dyoo) Assigned to: Raymond Hettinger (rhettinger) Summary: tokenize module does not detect inconsistent dedents Initial Comment: The attached code snippet 'testcase.py' should produce an IndentationError, but does not. The code in tokenize.py is too trusting, and needs to add a check against bad indentation as it yields DEDENT tokens. I'm including a diff to tokenize.py that should at least raise an exception on bad indentation like this. Just in case, I'm including testcase.py here too: -- import tokenize from StringIO import StringIO sampleBadText = """ def foo(): bar baz """ print list(tokenize.generate_tokens( StringIO(sampleBadText).readline)) -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-21 02:54 Message: Logged In: YES user_id=80475 Fixed. See Lib/tokenize.py 1.38 and 1.36.4.1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224621&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1224672 ] rsplit introduces spurious CR
Bugs item #1224672, was opened at 2005-06-21 02:47 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224672&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: Richard Prosser (rprosser) Assigned to: Nobody/Anonymous (nobody) Summary: rsplit introduces spurious CR Initial Comment: Using ActiveState Python 2.4.1 on "SunOS svpadm03 5.6 Generic_105181-25 sun4u sparc SUNW,Ultra-60", it seems that the new rsplit() adds a '\r' character at the end of the field. This was not present in the original data, so I suspect that there is a bug. Attachment gives partial script - I cannot upload the whole file for copyright reasons. However the process should be pretty clear, and it should be possible to arrange a test on a local machine. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-21 02:58 Message: Logged In: YES user_id=80475 Please submit a test case reduced to one line: "somestring".rsplit() # introduces \r not present in input -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224672&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1223937 ] subprocess.py abuse of errno
Bugs item #1223937, was opened at 2005-06-20 01:56 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&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 Submitted By: Oren Tirosh (orenti) >Assigned to: Peter Åstrand (astrand) Summary: subprocess.py abuse of errno Initial Comment: The CalledProcessError exception's .errno attribute is set to a child process return code which is not an errno. Any attempt to look up this number with os.strerror() or errno.errorcode[] will result in meaningless output. This can break existing code that catches OSError and does not expect CalledProcessError. Possible resolutions: 1. Don't make CalledProcessError a subclass of OSError 2. If CalledProcessError stays a subclass of OSError .errno should be set to some specific meaningful value (which one? add new value to errnomodule.c?) and use a separate attribute for the child process return code. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1047540 ] Turtle.py hangs Idle
Bugs item #1047540, was opened at 2004-10-15 13:51 Message generated for change (Comment added) made by tso You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1047540&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: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Taro Ogawa (tso) Assigned to: Nobody/Anonymous (nobody) Summary: Turtle.py hangs Idle Initial Comment: 1 line fix: After line 336's: root.destroy() insert root.quit() [Since IDLE is Tkinter based, the implict quit can't happen immediately. Worse, the shell has difficulty resetting and using a ^C can leave a zombie process] -T. -- >Comment By: Taro Ogawa (tso) Date: 2005-06-21 20:24 Message: Logged In: YES user_id=121025 I've tracked down some more info: It also happens on XP using 2.4.1 and Idle 1.1.1. The way to trigger it is to start IDLE with no subprocess. The way that I got that to happen is to right click on Turtle.py in Windows Explorer, and select "Edit with IDLE". While the fix that I suggested still cures it, it may be possible to achieve a better general solution by leaving turtle.py alone, and fixing IDLE... -T. -- Comment By: Taro Ogawa (tso) Date: 2004-10-25 10:46 Message: Logged In: YES user_id=121025 Sorry - should have included this: NT4, Python 2.3.3 [This isn't an isolated case - I've had problems with other programs behaving similarly on my XP box (using 2.3.4), eg the pygame demos]. Windows only thing...? -T. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-10-24 10:35 Message: Logged In: YES user_id=80475 What version of Python are you using? I cannot reproduce this on Py2.3 or on Py2.4b1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1047540&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1223937 ] subprocess.py abuse of errno
Bugs item #1223937, was opened at 2005-06-20 08:56 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Oren Tirosh (orenti) Assigned to: Peter Åstrand (astrand) Summary: subprocess.py abuse of errno Initial Comment: The CalledProcessError exception's .errno attribute is set to a child process return code which is not an errno. Any attempt to look up this number with os.strerror() or errno.errorcode[] will result in meaningless output. This can break existing code that catches OSError and does not expect CalledProcessError. Possible resolutions: 1. Don't make CalledProcessError a subclass of OSError 2. If CalledProcessError stays a subclass of OSError .errno should be set to some specific meaningful value (which one? add new value to errnomodule.c?) and use a separate attribute for the child process return code. -- >Comment By: Peter Åstrand (astrand) Date: 2005-06-21 17:52 Message: Logged In: YES user_id=344921 In hindsight, CalledProcessError should perhaps have been designed some other way. But now when we have it, it's not easy to change it. It all comes down to what is the documented behaviour and not. As far as I understand, there's no requirement that the errno number or an OSError should be possible to look up with os.strerror(). I cannot find anything about this at http://docs.python.org/lib/module-exceptions.html, at least. All it says is "[errno is] assumed to be an error number". In my opinion, code should be prepared for "unknown" error numbers. So currently, I'm not prepared to make any changes to CalledProcessError. (If you disagree with me, post to python-dev and see what others think.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1220113 ] subprocess call() helper should close stdin if PIPE
Bugs item #1220113, was opened at 2005-06-14 07:04 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&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: Closed >Resolution: Rejected Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Peter Åstrand (astrand) Summary: subprocess call() helper should close stdin if PIPE Initial Comment: The following code snippet should die instead of hang. >>> from subprocess import call, PIPE >>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE, stdin=PIPE) It makes no sense not to close stdin if it is PIPE because the stream cannot be accessed. The use case for this is ensuring a subprocess that detects if it is connected to a terminal or not runs in 'batch' mode, and that it will die instead of hang if it unexpectidly attempts to read from stdin. Workaround is to use Popen instead. -- >Comment By: Peter Åstrand (astrand) Date: 2005-06-21 18:08 Message: Logged In: YES user_id=344921 >It makes no sense not to close stdin if it is PIPE >because the stream cannot be accessed True, but what if you actually *want* to create an inaccessible pipe, and give it to the child? Currently, the call() wrapper is *very* short and simple. I think this is very good. For example, it allows us to document it in two sentences. You get what you ask for: If you use call() with strange arguments, you'll get a somewhat strange behavíour. I see no point in introducing lots of sanity checks in the wrapper functions. >The use case for this is ensuring a subprocess that >detects if it is connected to a terminal or not runs in >batch' mode, and that it will die instead of hang if >it unexpectidly attempts to read from stdin I'm not sure I understand what you want, but if you want to have stdin connected to a closed file descriptor, just pass one: >>> from subprocess import call, PIPE >>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE, stdin=4711) (Of course, you should verify that 4711 is unused.) If you don't agree with me, post to python-dev for discussion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1225059 ] Line endings problem with Python 2.4.1 cause imports to fail
Bugs item #1225059, was opened at 2005-06-21 20:56 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=1225059&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: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nicolas Lehuen (nlehuen) Assigned to: Nobody/Anonymous (nobody) Summary: Line endings problem with Python 2.4.1 cause imports to fail Initial Comment: Hi, Here is my Python version string : ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win32 I'm having troubles with a series of source code files that were working perfectly under Python 2.4.0 and earlier releases. I have enclosed one of those source files which should be independent of the rest, so that you can test it by yourself. Now, here is my problem : Test 1 --- C:\projets\development\python\tcc>python ActivePython 2.4.1 Build 245 (ActiveState Corp.) based on Python 2.4.1 (#65, Mar 30 2005, 09:33:37) [MSC v.1310 32 bit (Intel)] on win3 Type "help", "copyright", "credits" or "license" for more information. >>> import util Traceback (most recent call last): File "", line 1, in ? File "util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : this is the problem, the Python interpreter fails to parse the file. Note that is is a DOS-style file, with \r\n as lines separator, instead of simply \n. If I convert the file to a UNIX-style, \n separated lines format, then everything is OK. Test 2 --- C:\projets\development\python\tcc>python -i util.py C:\projets\development\python\tcc>python -i util.py >>> ^Z --- interpretation : launching the script instead of importing it is OK. It seems that the way scripts are loaded for direct launching is different than the way they are loaded for import. Test 3 --- C:\projets\development\python\tcc>python -m util File "C:\projets\development\python\tcc\util.py", line 612 _max=None ^ SyntaxError: invalid syntax --- interpretation : using another way to import the module and launch it yield the same buggy behaviour. Once again, if I convert line termination from DOS to UNIX, everything is OK. I've seen a few bugs related to rstrip() and readline() having a new behaviour, maybe this problem is related ? This is quite an annoying bug, because some perfectly valid code just stop working. The workaround is to convert everything to UNIX format, which is a bit tiresome given that my code is distributed on a bunch of computers... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225059&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1223937 ] subprocess.py abuse of errno
Bugs item #1223937, was opened at 2005-06-20 08:56 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&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 Submitted By: Oren Tirosh (orenti) Assigned to: Peter Åstrand (astrand) Summary: subprocess.py abuse of errno Initial Comment: The CalledProcessError exception's .errno attribute is set to a child process return code which is not an errno. Any attempt to look up this number with os.strerror() or errno.errorcode[] will result in meaningless output. This can break existing code that catches OSError and does not expect CalledProcessError. Possible resolutions: 1. Don't make CalledProcessError a subclass of OSError 2. If CalledProcessError stays a subclass of OSError .errno should be set to some specific meaningful value (which one? add new value to errnomodule.c?) and use a separate attribute for the child process return code. -- >Comment By: Peter Åstrand (astrand) Date: 2005-06-21 22:13 Message: Logged In: YES user_id=344921 I've changed my mind, since CalledProcessError is only in the development version of Python. Perhaps it's acceptable to change the API after all, then. Re-opening. -- Comment By: Peter Åstrand (astrand) Date: 2005-06-21 17:52 Message: Logged In: YES user_id=344921 In hindsight, CalledProcessError should perhaps have been designed some other way. But now when we have it, it's not easy to change it. It all comes down to what is the documented behaviour and not. As far as I understand, there's no requirement that the errno number or an OSError should be possible to look up with os.strerror(). I cannot find anything about this at http://docs.python.org/lib/module-exceptions.html, at least. All it says is "[errno is] assumed to be an error number". In my opinion, code should be prepared for "unknown" error numbers. So currently, I'm not prepared to make any changes to CalledProcessError. (If you disagree with me, post to python-dev and see what others think.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1225107 ] inspect.isclass() fails with custom __getattr__
Bugs item #1225107, was opened at 2005-06-21 14:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225107&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
Submitted By: Jeremy Kloth (jkloth)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.isclass() fails with custom __getattr__
Initial Comment:
inspect.isclass() can return True for instances of classes
which define a __getattr__ method. For example:
>>> class Namespace(unicode):
...def __getattr__(self, attr):
... return '<%s>' % (self + attr)
...
>>> inspect.isclass(Namespace('foo'))
True
Changing inspect.isclass() to:
return isinstance(object, (types.ClassType, type))
solves this issue.
The check for __bases__ is no longer need due to
type/class unification.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1225107&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1220113 ] subprocess call() helper should close stdin if PIPE
Bugs item #1220113, was opened at 2005-06-14 15:04 Message generated for change (Comment added) made by zenzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&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: Closed Resolution: Rejected Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Peter Åstrand (astrand) Summary: subprocess call() helper should close stdin if PIPE Initial Comment: The following code snippet should die instead of hang. >>> from subprocess import call, PIPE >>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE, stdin=PIPE) It makes no sense not to close stdin if it is PIPE because the stream cannot be accessed. The use case for this is ensuring a subprocess that detects if it is connected to a terminal or not runs in 'batch' mode, and that it will die instead of hang if it unexpectidly attempts to read from stdin. Workaround is to use Popen instead. -- >Comment By: Stuart Bishop (zenzen) Date: 2005-06-22 16:12 Message: Logged In: YES user_id=46639 I can't think of any uses cases for wanting to create an inaccessible pipe and give it to the child. Wanting to pass a closed file handle is common. It is needed when calling a program that behaves differently if its stdin is a terminal or not. Or when you simply would prefer the subprocess to die if it attempts to read from its stdin rather than block. Using Popen instead of call is s simpler workaround than creating and closing a file descriptor and passing it in. Perhaps what is needed is a new constant, subprocess.CLOSED which creates a new file descriptor and closes it? This would be useful for Popen too, allowing call() to remain a think and trivially documented wrapper? -- Comment By: Peter Åstrand (astrand) Date: 2005-06-22 02:08 Message: Logged In: YES user_id=344921 >It makes no sense not to close stdin if it is PIPE >because the stream cannot be accessed True, but what if you actually *want* to create an inaccessible pipe, and give it to the child? Currently, the call() wrapper is *very* short and simple. I think this is very good. For example, it allows us to document it in two sentences. You get what you ask for: If you use call() with strange arguments, you'll get a somewhat strange behavíour. I see no point in introducing lots of sanity checks in the wrapper functions. >The use case for this is ensuring a subprocess that >detects if it is connected to a terminal or not runs in >batch' mode, and that it will die instead of hang if >it unexpectidly attempts to read from stdin I'm not sure I understand what you want, but if you want to have stdin connected to a closed file descriptor, just pass one: >>> from subprocess import call, PIPE >>> rv = call(['/usr/bin/bzip2', '-c'], stdout=PIPE, stdin=4711) (Of course, you should verify that 4711 is unused.) If you don't agree with me, post to python-dev for discussion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1220113&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
