[ python-Bugs-1173637 ] quit should quit
Bugs item #1173637, was opened at 2005-03-30 21:37 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470 Category: None Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Matt Chaput (mchaput) Assigned to: Nobody/Anonymous (nobody) Summary: quit should quit Initial Comment: When the user types "quit" in the interpreter, instead of quitting the program gives him or her a lecture on the "proper" way to quit. This is very obnoxious. Since the interpreter obviously understands the "quit" command, it should just quit, dammit. -- >Comment By: Armin Rigo (arigo) Date: 2005-04-02 12:24 Message: Logged In: YES user_id=4771 Raymond, an argument against quit() actually quitting the interpreter is that it suddenly makes quit() a quasi-official piece of the Python API, and we're bound to see user programs start to write quit() instead of sys.exit(). -- Comment By: Martin v. Löwis (loewis) Date: 2005-04-01 21:47 Message: Logged In: YES user_id=21627 But how is this better than the current >>> quit 'Use Ctrl-D (i.e. EOF) to exit.' I'd rather learn that I have to type Ctrl-D instead of typing quit() I think the original report is misguided: The interpreter does not "obviously understand" the quit command. Instead, it really does not understand it all. The name quit is bound to a string, and the interpreter displays the string. It does not understand at all what the string says. So I'm rejecting the report as "won't fix". -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-01 18:13 Message: Logged In: YES user_id=80475 class quit: def __repr__(self): return "Type quit() to exit the interpreter" def __call__(self): sys.exit() Requiring the parentheses is not a big deal as long as there is an advisory where they are omitted. -- Comment By: Armin Rigo (arigo) Date: 2005-04-01 11:12 Message: Logged In: YES user_id=4771 This discussion keeps coming up time and again. sjoerd's trick has been tried a few times already, until people implementing it realized that trying to display the builtins dict (directly or indirectly) would quit the interpreter! 'quit' cannot just be a synonym for 'sys.exit' either, because typing 'quit' would just print '', which is worse than the current situation in term of expliciteness. -- Comment By: Sjoerd Mullender (sjoerd) Date: 2005-04-01 11:04 Message: Logged In: YES user_id=43607 Something like this instead of the current quit should do the trick: class Quit: def __repr__(self): import sys sys.exit(0) quit = Quit() del Quit The problem with the Raymond's suggestion is that you need to type parentheses. But of course, this does get a little magical... -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-01 06:14 Message: Logged In: YES user_id=80475 'quit' and 'exit' currently show-up in a dir() of__builtins__. If the OP's suggestion is accepted, it should probably be implemented just like a builtin: def quit(): sys.exit() That approach is not at all magical and still allows shadowing (quit=2, etc.) What we have now is an annoying wart. -- Comment By: Ilya Sandler (isandler) Date: 2005-04-01 04:35 Message: Logged In: YES user_id=971153 I am not sure adding quit to interpreter is such a good idea: Right now quit is treated as an ordinary (non-keyword) identifier... (with a bit of magic: if quit is not defined then lecture the user :-))... E.g now you can do this: >>> quit=2 >>> quit 2 Would you want to disallow this usage when quit becomes a "magic word"? -- Comment By: Michael Hudson (mwh) Date: 2005-03-31 09:49 Message: Logged In: YES user_id=6656 I'm not so sure typing quit should quit -- that doesn't seem like Python to me (how would you implement it?) Having quit be the same object as sys.exit seems sensible. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-30 22:11 Message: Logged In: YES user_id=80475 I concur! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://
[ python-Bugs-1174712 ] subclassing ModuleType and another built-in type
Bugs item #1174712, was opened at 2005-04-01 09:22
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174712&group_id=5470
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: subclassing ModuleType and another built-in type
Initial Comment:
class X(types.ModuleType, str): pass
X('name')
-> segfault
This buggy subclassing goes through typeobject.c's checks because
PyModuleObject looks exactly like a user-defined subclass of 'object': it has a
PyObject_HEAD followed only by the dict, as specified by tp_dictoffset.
A fix would be to forbid any subclassing to move the tp_dictoffset of a
non-heap type.
--
>Comment By: Armin Rigo (arigo)
Date: 2005-04-02 12:27
Message:
Logged In: YES
user_id=4771
The proposed fix is not good enough. If another built-in C type similar to
PyModuleObject is defined (say by a C extension module), then it would become
possible to subclass both this new type and ModuleType. This might lead to
unwanted behavior if e.g. one parent class allows rebinding __dict__ and the
other not (and crashes if __dict__ is rebound).
This might point to the need for cleaning up typeobject.c's darker corners...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174712&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1174606 ] Reading /dev/zero causes SystemError
Bugs item #1174606, was opened at 2005-04-01 04:48
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174606&group_id=5470
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Olsen (rhamphoryncus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reading /dev/zero causes SystemError
Initial Comment:
$ python -c 'open("/dev/zero").read()'
Traceback (most recent call last):
File "", line 1, in ?
SystemError: ../Objects/stringobject.c:3316: bad
argument to internal function
Compare with this two variants:
$ python -c 'open("/dev/zero").read(2**31-1)'
Traceback (most recent call last):
File "", line 1, in ?
MemoryError
$ python -c 'open("/dev/zero").read(2**31)'
Traceback (most recent call last):
File "", line 1, in ?
OverflowError: long int too large to convert to int
The unsized read should produce either MemoryError or
OverflowError instead of SystemError.
Tested with Python 2.2, 2.3, and 2.4.
--
>Comment By: Armin Rigo (arigo)
Date: 2005-04-02 12:31
Message:
Logged In: YES
user_id=4771
os.stat() doesn't always give consistent results on dev files. On my machine
for some reason os.stat('/dev/null') appears to be random (and extremely
large). I suspect that on the OP's machine os.stat('/dev/zero') is not 0
either, but a random number that turns out to be negative, hence a "bad
argument" SystemError.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-04-01 21:42
Message:
Logged In: YES
user_id=21627
I think it should trust the stat result, and then find that
it cannot allocate that much memory.
Actually, os.stat("/dev/zero").st_size is 0, so something
else must be going on.
--
Comment By: Armin Rigo (arigo)
Date: 2005-04-01 09:58
Message:
Logged In: YES
user_id=4771
I think that file.read() with no argument needs to be more conservative.
Currently it asks and trusts the stat() to get the file size, but this can lead
to just plain wrong results on special devices. (I had the problem that
open('/dev/null').read() would give a MemoryError!)
We can argue whether plain read() on special devices is a good idea or not, but
I guess that not blindly trusting stat() if it returns huge values could be a
good idea.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174606&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1175396 ] codecs.readline sometimes removes newline chars
Bugs item #1175396, was opened at 2005-04-02 17:14 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=1175396&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Walter Dörwald (doerwalter) Summary: codecs.readline sometimes removes newline chars Initial Comment: In Python 2.4.1 i observed a new bug in codecs.readline, it seems that with certain inputs it removes newline characters from the end of the line Probably related to bug #1076985 (Incorrect behaviour of StreamReader.readline leads to crash) and bug #1098990 codec readline() splits lines apart (both with status closed) so I'm assigning this to Walter. See the attached files that demonstrate the problem. Reproduced with Python 2.4.1 on windows XP and on Linux. The problem does not occur with Python 2.4. (btw, it seems bug #1076985 was fixed in python 2.4.1, but the other one (#1098990) not? ) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175396&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163401 ] uncaught AttributeError deep in urllib
Bugs item #1163401, was opened at 2005-03-14 19:39
Message generated for change (Comment added) made by roysmith
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: K Lars Lohn (lohnk)
Assigned to: Nobody/Anonymous (nobody)
Summary: uncaught AttributeError deep in urllib
Initial Comment:
Python 2.4 and Python 2.3.4 running under Suse 9.2
We're getting an AttributeError exception "AttributeError: 'NoneType' object
has no attribute 'read'" within a very simple call to urllib.urlopen.
This was discovered while working on Sentry 2, the new mirror integrity checker
for the Mozilla project. We try to touch hundreds of URLs to make sure that
the files are present on each of the mirrors. One particular URL kills the
call to urllib.urlopen:
http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe
This file probably does not exist on the mirror, however, in other cases of bad
URLs, we get much more graceful failures when we try to read from the object
returned by urllib.urlopen.
>>> import urllib
>>> urlReader =
>>> urllib.urlopen("http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe";)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.4/urllib.py", line 77, in urlopen
return opener.open(url)
File "/usr/local/lib/python2.4/urllib.py", line 180, in open
return getattr(self, name)(url)
File "/usr/local/lib/python2.4/urllib.py", line 305, in open_http
return self.http_error(url, fp, errcode, errmsg, headers)
File "/usr/local/lib/python2.4/urllib.py", line 322, in http_error
return self.http_error_default(url, fp, errcode, errmsg, headers)
File "/usr/local/lib/python2.4/urllib.py", line 550, in http_error_default
return addinfourl(fp, headers, "http:" + url)
File "/usr/local/lib/python2.4/urllib.py", line 836, in __init__
addbase.__init__(self, fp)
File "/usr/local/lib/python2.4/urllib.py", line 786, in __init__
self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'
The attached file is a three line scipt that demos the problem.
--
Comment By: Roy Smith (roysmith)
Date: 2005-04-02 16:44
Message:
Logged In: YES
user_id=390499
Wow, this is bizarre. I just spend some time tracking down exactly this
same bug and was just about to enter it when I saw this entry. For what
it's worth, I can reliably reproduce this exception when fetching a URL from
a deliberately broken server (well, at least I think it's broken; have to
double-check the HTTP spec to be sure this isn't actually allowed) which
produces headers but no body:
(This is on Mac OSX-10.3.8, Python-2.3.4)
---
Roy-Smiths-Computer:bug$ cat server.py
#!/usr/bin/env python
from BaseHTTPServer import *
class NullHandler (BaseHTTPRequestHandler):
def do_GET (self):
self.send_response (100)
self.end_headers ()
server = HTTPServer (('', 8000), NullHandler)
server.handle_request()
--
Roy-Smiths-Computer:bug$ cat client.py
#!/usr/bin/env python
import urllib
urllib.urlopen ('http://127.0.0.1:8000')
-
Roy-Smiths-Computer:bug$ ./client.py
Traceback (most recent call last):
File "./client.py", line 5, in ?
urllib.urlopen ('http://127.0.0.1:8000')
File "/usr/local/lib/python2.3/urllib.py", line 76, in urlopen
return opener.open(url)
File "/usr/local/lib/python2.3/urllib.py", line 181, in open
return getattr(self, name)(url)
File "/usr/local/lib/python2.3/urllib.py", line 306, in open_http
return self.http_error(url, fp, errcode, errmsg, headers)
File "/usr/local/lib/python2.3/urllib.py", line 323, in http_error
return self.http_error_default(url, fp, errcode, errmsg, headers)
File "/usr/local/lib/python2.3/urllib.py", line 551, in http_error_default
return addinfourl(fp, headers, "http:" + url)
File "/usr/local/lib/python2.3/urllib.py", line 837, in __init__
addbase.__init__(self, fp)
File "/usr/local/lib/python2.3/urllib.py", line 787, in __init__
self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'
-
I'll give urllib2 a try and see how that works.
--
Comment By: K Lars Lohn (lohnk)
Date: 2005-03-16 12:07
Message:
Logged In: YES
user_id=1239273
I've changed over to urllib2. The only complication involved the exception
handling model: urllib2's HTTPError exceptions cannot be pickled because they
contain an open socket._fileobject. While mildly inconvenient, the workaround
was not difficult.
-
[ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops
Bugs item #1112549, was opened at 2005-01-30 08:40 Message generated for change (Comment added) made by chrism You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chris McDonough (chrism) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage memory usage can spike in line-oriented ops Initial Comment: Various parts of cgi.FieldStorage call its "read_lines_to_outerboundary", "read_lines" and "skip_lines" methods.These methods use the "readline" method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a "file-data" part that consists of a 2GB string composed entirely of "x" characters (which happens to be something I did that led me to noticing this bug). The simplest fix is to make use of the "size" argument of the readline method of the file object where it is used within all parts of FieldStorage that make use of it. A patch against the Python 2.3.4 cgi.py module that does this is attached. -- >Comment By: Chris McDonough (chrism) Date: 2005-04-02 22:42 Message: Logged In: YES user_id=32974 An updated test_cgi.py is attached. I test both the readline behavior and add a test for basic multipart parsing. -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 23:48 Message: Logged In: YES user_id=6380 Can I tweak you into uploading a unit test? -- Comment By: Chris McDonough (chrism) Date: 2005-03-31 21:56 Message: Logged In: YES user_id=32974 Re: parse_multipart.. yes, it looks like there's no use fixing that as it just turns around and puts the line into a list.. it is vulnerable but just by virtue of its non-use of a tempfile, it appears doomed anyway for large requests. I don't know of anything that uses it. Good catch wrt boundary recognition bug, I'm uploading another patch. -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 17:13 Message: Logged In: YES user_id=6380 Methinks that the fix isn't quite right: it would incorrectly recognize as a boundary a very long line starting with "--" followed by the appropriate random string at offset 2**16. This could probably be taken care of by adding a flag that is true initially and after that keeps track of whether the previous line ended in \n. Also, there's a call to fp.readline() in parse_multipart() that you didn't patch -- it wouldn't help because that code is saving the lines in a list anyway, but isn't that code vulnerable as well? Or is it not used? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops
Bugs item #1112549, was opened at 2005-01-30 08:40 Message generated for change (Comment added) made by chrism You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chris McDonough (chrism) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage memory usage can spike in line-oriented ops Initial Comment: Various parts of cgi.FieldStorage call its "read_lines_to_outerboundary", "read_lines" and "skip_lines" methods.These methods use the "readline" method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a "file-data" part that consists of a 2GB string composed entirely of "x" characters (which happens to be something I did that led me to noticing this bug). The simplest fix is to make use of the "size" argument of the readline method of the file object where it is used within all parts of FieldStorage that make use of it. A patch against the Python 2.3.4 cgi.py module that does this is attached. -- >Comment By: Chris McDonough (chrism) Date: 2005-04-02 23:00 Message: Logged In: YES user_id=32974 FYI, I'd be happy to do the merging here if you wanted to give me checkin access. -- Comment By: Chris McDonough (chrism) Date: 2005-04-02 22:42 Message: Logged In: YES user_id=32974 An updated test_cgi.py is attached. I test both the readline behavior and add a test for basic multipart parsing. -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 23:48 Message: Logged In: YES user_id=6380 Can I tweak you into uploading a unit test? -- Comment By: Chris McDonough (chrism) Date: 2005-03-31 21:56 Message: Logged In: YES user_id=32974 Re: parse_multipart.. yes, it looks like there's no use fixing that as it just turns around and puts the line into a list.. it is vulnerable but just by virtue of its non-use of a tempfile, it appears doomed anyway for large requests. I don't know of anything that uses it. Good catch wrt boundary recognition bug, I'm uploading another patch. -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 17:13 Message: Logged In: YES user_id=6380 Methinks that the fix isn't quite right: it would incorrectly recognize as a boundary a very long line starting with "--" followed by the appropriate random string at offset 2**16. This could probably be taken care of by adding a flag that is true initially and after that keeps track of whether the previous line ended in \n. Also, there's a call to fp.readline() in parse_multipart() that you didn't patch -- it wouldn't help because that code is saving the lines in a list anyway, but isn't that code vulnerable as well? Or is it not used? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
