[ python-Bugs-1684991 ] Explain __method__ lookup semantics for new-style classes
Bugs item #1684991, was opened at 2007-03-21 08:53 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=1684991&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: Explain __method__ lookup semantics for new-style classes Initial Comment: __method__s (and next) are looked up on the type, not the instance. This isn't documented properly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684991&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1682749 ] next method assignment is ignored in new-style classes
Bugs item #1682749, was opened at 2007-03-17 15:06 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&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.5 >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Albert Weichselbraun (albert2611) Assigned to: Neal Norwitz (nnorwitz) Summary: next method assignment is ignored in new-style classes Initial Comment: in old-style classes the next method of an iterator-superclass can be "overwritten" using self.next = self.new_next_method when new-style classes are used the assignment is ignored and instead of new_next_method the next method of the superclass is called when the class is used as iterator (tested for python2.3-2.5 under debian/linux). - if the next() method is called directly, the assigned method is used (see attached code example). -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 08:54 Message: Logged In: YES user_id=849994 Originator: NO Closing this then, I have opened a new bug (#1684991) for the documentation issue. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-21 07:02 Message: Logged In: YES user_id=33168 Originator: NO Yup, based on mail thread this behaviour seems correct. Unfortunately, I don't think it's properly documented or consistent either. :-( -- Comment By: Albert Weichselbraun (albert2611) Date: 2007-03-17 16:27 Message: Logged In: YES user_id=806170 Originator: YES i only experienced this behavior for the next method in iterator classes. overwriting methods with other names using an assignment works as expected. -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 15:52 Message: Logged In: YES user_id=849994 Originator: NO This is another incarnation of __methods__ being looked up on the type, not the instance, except that next() is not a __method__ yet. For new-style classes, this behavior is considered correct. Neal? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682749&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1685000 ] DoS asyncore vulnerability
Bugs item #1685000, was opened at 2007-03-21 10:15 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=1685000&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: DoS asyncore vulnerability Initial Comment: DoS asyncore vulnerability asyncore, independently if used with select() or poll(), suffers a DoS-type vulnerability when a high number of simultaneous connections to handle simultaneously is reached. The number of maximum connections is system-dependent as well as the type of error raised. I attached two simple Proof of Concept scripts demonstrating such bug. If you want to try the behaviours listed below run the attached "asyncore_server.py" and "asyncore_client.py" scripts on your local workstation. On my Windows XP system (Python 2.5), independently if asyncore has been used to develop a server or a client, the error is raised by select() inside asyncore's "poll" function when 512 (socket_map's elements) simultaneous connections are reached. Here's the traceback I get: [...] connections: 510 connections: 511 connections: 512 Traceback (most recent call last): File "C:\scripts\asyncore_server.py", line 38, in asyncore.loop() File "C:\Python25\lib\asyncore.py", line 191, in loop poll_fun(timeout, map) File "C:\Python25\lib\asyncore.py", line 121, in poll r, w, e = select.select(r, w, e, timeout) ValueError: too many file descriptors in select() On my Linux Ubuntu 6.10 (kernel 2.6.17-10, Python 2.5) different type of errors are raised depending on the application (client or server). In an asyncore-based client the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'connect' method of 'dispatcher' class: [...] connections: 1018 connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_client.py", line 31, in File "asyncore.py", line 191, in loop File "asyncore.py", line 138, in poll File "asyncore.py", line 80, in write File "asyncore.py", line 76, in write File "asyncore.py", line 395, in handle_write_event File "asyncore_client.py", line 24, in handle_connect File "asyncore_client.py", line 9, in __init__ File "asyncore.py", line 257, in create_socket File "socket.py", line 156, in __init__ socket.error: (24, 'Too many open files') On an asyncore-based server the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'accept' method of 'dispatcher' class: [...] connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_server.py", line 38, in File "asyncore.py", line 191, in loop File "asyncore.py", line 132, in poll File "asyncore.py", line 72, in read File "asyncore.py", line 68, in read File "asyncore.py", line 384, in handle_read_event File "asyncore_server.py", line 16, in handle_accept File "asyncore.py", line 321, in accept File "socket.py", line 170, in accept socket.error: (24, 'Too many open files') -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685000&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675967 ] Python2.5 can't read a (complex) pickle build by python2.4
Bugs item #1675967, was opened at 2007-03-07 18:16
Message generated for change (Comment added) made by mvo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Vogt (mvo)
Assigned to: Žiga Seilnacht (zseil)
Summary: Python2.5 can't read a (complex) pickle build by python2.4
Initial Comment:
Part of gnome-app-install in ubuntu is a pickle data structure cache. If I
create this pickle with python 2.4 and read it later with 2.5. I get the
following error:
$ python2.5 -c 'import pickle;
pickle.load(open("/var/cache/app-install/menu.p"))'
/usr/lib/python2.5/pickle.py:1124: DeprecationWarning: The sre module is
deprecated, please import re.
__import__(module)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/pickle.py", line 1370, in load
return Unpickler(file).load()
File "/usr/lib/python2.5/pickle.py", line 858, in load
dispatch[key](self)
File "/usr/lib/python2.5/pickle.py", line 1090, in load_global
klass = self.find_class(module, name)
File "/usr/lib/python2.5/pickle.py", line 1126, in find_class
klass = getattr(mod, name)
AttributeError: 'module' object has no attribute '_compile'
With:
$ python2.4 -c 'import pickle;
pickle.load(open("/var/cache/app-install/menu.p"))'
[EMAIL PROTECTED] ~ $
It loads just fine.
The test pickle can be found here:
http://people.ubuntu.com/~mvo/gnome-app-install/menu.p.gz
Cheers,
Michael
--
>Comment By: Michael Vogt (mvo)
Date: 2007-03-21 09:43
Message:
Logged In: YES
user_id=3206
Originator: YES
Thanks a lot for the patch. It works fine here with the patch.
--
Comment By: Žiga Seilnacht (zseil)
Date: 2007-03-11 15:40
Message:
Logged In: YES
user_id=1326842
Originator: NO
Attaching the patch with a test here. Unpickling
old patterns with this patch works, but it still
issues a DeprecationWarning. The test itself is
a bit obscure, but the other option is to add
a binary file to the test suite.
File Added: sre_pickle_compatibility.diff
--
Comment By: Žiga Seilnacht (zseil)
Date: 2007-03-07 19:43
Message:
Logged In: YES
user_id=1326842
Originator: NO
This happens because of SRE_Pattern objects in jour pickle.
The sre module was renamed to re in Python 2.5, but the
old pickles still expect the _compile function in sre module.
I posted the patch here:
http://freeweb.siol.net/chollus/
Could you try if it fixes the problem for you and in that
case, attach it to this report?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669349 ] make install fails if no previous Python installation
Bugs item #1669349, was opened at 2007-02-26 19:22
Message generated for change (Comment added) made by percivall
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669349&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: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matthias S. Benkmann (mbenkmann)
Assigned to: Nobody/Anonymous (nobody)
Summary: make install fails if no previous Python installation
Initial Comment:
When installing Python 2.5 on a completely Python-less system 'make install'
failed. The error that caused the failure was
Compiling /usr/lib/python2.5/test/test_multibytecodec.py ...
Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedata
module)",)
[snip]
Compiling /usr/lib/python2.5/zipfile.py ...
make: *** [libinstall] Error 1
'find -name unicodedata.so' showed me that the library did not exist in the
build tree. However, after a 'make -i install' to force make to continue
despite the error, unicodedata.so was there. So apparently the library is not
built until a later stage of make install. And indeed, subsequent 'make
install' calls without -i were successful.
It is important to note that if you have a previous Python installation (at
least of the same version), 'make install' will go through, because it'll load
the library from there. So if you want to reproduce the issue you will have to
install from a freshly unpacked tarball on a system with no Python installation.
--
Comment By: Simon Percivall (percivall)
Date: 2007-03-21 12:26
Message:
Logged In: YES
user_id=329382
Originator: NO
It shouldn't be a problem changing the Makefile to do sharedinstall before
libinstall in the altinstall target. I'm guessing that would solve the
problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669349&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681974 ] mkdtemp fails on Windows if username has non-ASCII character
Bugs item #1681974, was opened at 2007-03-16 10:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681974&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Markus Niemist� (niemisto) Assigned to: Nobody/Anonymous (nobody) Summary: mkdtemp fails on Windows if username has non-ASCII character Initial Comment: mkdtemp fails miserably on Windows if Windows user name has any non-ASCII characters, like ä or ö, in it. mkdtemp throws an encoding error. This seems to be because the default temp dir in Windows is "c:\documents and settings\\local settings\temp". Now if the user name has non-ASCII characters ASCII decoder cannot handle it and creating temp directories won't work. As a work around I have used the following code: tempdir = unicode(tempfile.gettempdir(), 'mbcs') mkdtemp(suffix='foo', dir=tempdir) This applies for both Python 2.4 and Python 2.5. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 11:42 Message: Logged In: YES user_id=849994 Originator: NO Could you indicate where exactly what error is raised? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681974&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1684254 ] regression in webbrowser command line parsing
Bugs item #1684254, was opened at 2007-03-20 11:09 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684254&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: Fixed Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: regression in webbrowser command line parsing Initial Comment: With Python 2.4 it was common to use BROWSER environment variables like: BROWSER="firefox '%s' &" to launch a browser. The apostrophes around %s are required to escape special characters in the URL (because the command is launched using os.system, which uses a shell), and & at the end is required to not block GUI applications. However, in Python 2.5 it uses the subprocess module, and the example above doesn't work. It tries to open `firefox 'URL' &` literally, which causes Firefox to open URIs like file:///path/to/current/directory/'URL'. Attached a patch that fixes the problem. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 11:53 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the report, fixed it using shlex in rev. 54485, 54486 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684254&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1684254 ] regression in webbrowser command line parsing
Bugs item #1684254, was opened at 2007-03-20 12:09 Message generated for change (Comment added) made by luks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684254&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: Fixed Priority: 5 Private: No Submitted By: Lukas Lalinsky (luks) Assigned to: Nobody/Anonymous (nobody) Summary: regression in webbrowser command line parsing Initial Comment: With Python 2.4 it was common to use BROWSER environment variables like: BROWSER="firefox '%s' &" to launch a browser. The apostrophes around %s are required to escape special characters in the URL (because the command is launched using os.system, which uses a shell), and & at the end is required to not block GUI applications. However, in Python 2.5 it uses the subprocess module, and the example above doesn't work. It tries to open `firefox 'URL' &` literally, which causes Firefox to open URIs like file:///path/to/current/directory/'URL'. Attached a patch that fixes the problem. -- >Comment By: Lukas Lalinsky (luks) Date: 2007-03-21 12:57 Message: Logged In: YES user_id=587716 Originator: YES Oh, I didn't know about shlex.split. Thanks. -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 12:53 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the report, fixed it using shlex in rev. 54485, 54486 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1684254&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-515751 ] Missing docs for module imputil
Bugs item #515751, was opened at 2002-02-11 00:55 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=515751&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.6 Status: Open Resolution: None Priority: 6 Private: No Submitted By: David Abrahams (david_abrahams) >Assigned to: Nobody/Anonymous (nobody) Summary: Missing docs for module imputil Initial Comment: The summary says it all. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-03-12 15:29 Message: Logged In: YES user_id=3066 Greg -- please write documentation for this module. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=515751&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-692884 ] python always searches python23.zip
Bugs item #692884, was opened at 2003-02-25 08:43 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692884&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.3 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Just van Rossum (jvr) Summary: python always searches python23.zip Initial Comment: In trying to figure out why startup of the spambayes hammiefilter seems so slow, I ran it under the control of ktrace (also known as strace or truss on other systems). I noticed that even though it's not in sys.path, the interpreter is always searching for modules in $prefix/python23.zip. Why's that? Here's a little ktrace/kdump output: 2361 python CALL stat(0xbfffe1d0,0xbfffe5e0) 2361 python NAMI "/Users/skip/local/lib/python23.zip" 2361 python RET stat -1 errno 2 No such file or directory 2361 python CALL stat(0xbfffe1d0,0xbfffe5e0) 2361 python NAMI "/Users/skip/local/lib" 2361 python RET stat 0 2361 python CALL stat(0xbfffece0,0xbfffe7d0) 2361 python NAMI "/Users/skip/local/lib/python23.zip/warnings" 2361 python RET stat -1 errno 2 No such file or directory 2361 python CALL open(0xbfffece0,0,0x1b6) 2361 python NAMI "/Users/skip/local/lib/python23.zip/warnings.py" 2361 python RET open -1 errno 2 No such file or directory 2361 python CALL open(0xbfffece0,0,0x1b6) 2361 python NAMI "/Users/skip/local/lib/python23.zip/warnings.pyc" 2361 python RET open -1 errno 2 No such file or directory 2361 python CALL open(0xbfffece0,0,0x1b6) 2361 python NAMI "/Users/skip/local/lib/python23.zip/warnings.so" 2361 python RET open -1 errno 2 No such file or directory 2361 python CALL open(0xbfffece0,0,0x1b6) 2361 python NAMI "/Users/skip/local/lib/python23.zip/warningsmodule.so" 2361 python RET open -1 errno 2 No such file or directory What's particularly odd is that even though the search for python23.zip fails, it continues to march along looking for files within the nonexistent zip file. Searching for modules in something not in sys.path seems like a bug to me. -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-21 13:18 Message: Logged In: YES user_id=1344176 Originator: NO "python -vv" tells me this was fixed some time between Python 2.4.4 and Python 2.5.0. Closing as "fixed". -- Comment By: Just van Rossum (jvr) Date: 2003-02-25 10:32 Message: Logged In: YES user_id=92689 I think it would cause more confusion to have the .pyo's in an earlier location than the .pyc's and .py's. Also, this would cause the .pyo's to always be used, even when not using -O. The solution is what I said: phase two of PEP 302. -- Comment By: Skip Montanaro (montanaro) Date: 2003-02-25 10:15 Message: Logged In: YES user_id=44345 If $prefix/python23.zip must always be present and is always going to be searched (and searched ahead of $prefix/python2.3, why not have the installation process create it with the .pyo contents of $prefix/python2.3? (Hammiefilter doesn't import any Mac modules, so the problem Jack fixed shouldn't affect this case.) -- Comment By: Just van Rossum (jvr) Date: 2003-02-25 10:07 Message: Logged In: YES user_id=92689 (You probably could have found this with python -vv ;-) Since Python 2.3a1, site.py no longer removes sys.path items that don't exist on the file system, because it may be (eg.) a URL, handled by a custom importer. PEP 273 explains why a standard zip entry must be on sys.path. The problem is that the PEP 302 mechanism doesn't make a difference between "no importer found for this sys.path entry" and "use the builtin path importer". This will be fixed in "phase 2" of PEP 302, which consits of adding an explicit importer object on sys.meta_path representing the builtin path importer. (I should really do this before 2.3b1, this report should serve as a reminder for me.) That said, Jack _yesterday_ fixed a problem on OSX which caused importing Mac modules to be extremely slow (a delay of *seconds*). If spambayes happens to import a Mac module on OSX this would have affected you. Rebuilding from current CVS would help then. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=692884&group_id=5470 ___ Python-bugs-list
[ python-Bugs-696206 ] Move modules out of Carbon
Bugs item #696206, was opened at 2003-03-02 16:26 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696206&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jack Jansen (jackjansen) >Assigned to: Brett Cannon (bcannon) Summary: Move modules out of Carbon Initial Comment: Some modules that are in the Carbon package for historical reasons need to move to other places (with a compaitbility module in Carbon, for 2.3). Definitely CG, CF and Qt, and for Qd and AE there's a point to be made too (but there are some technical difficulties there). -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-21 13:38 Message: Logged In: YES user_id=1344176 Originator: NO I don't understand how having these modules in Carbon is a bug. Why should they be moved out? Assigning to Brett since this seems like something that would fall under his PEP 3108. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696206&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-214033 ] re incompatibility in sre
Bugs item #214033, was opened at 2000-09-11 04:24 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&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: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Martin v. Löwis (loewis) Assigned to: Fredrik Lundh (effbot) Summary: re incompatibility in sre Initial Comment: [submitted by Adam Sampson] Under Python 1.5.2, I had a script containing the following line: m = re.match(r"[a-z0-9]*://[^/]+/.*\.([^.#\?/]*)([#\?]?.*)?", url) Under 1.6, this fails with: [...] File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat I can narrow it down to: >>> m = re.match(r"(x?)?", url) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python1.6/sre.py", line 44, in match return _compile(pattern, flags).match(string) File "/usr/local/lib/python1.6/sre.py", line 102, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat whereas: >>> m = re.match(r"(x?.)?", url) works fine. Is this correct behaviour for SRE, or am I just being stupid? "(x?)?" looks like a perfectly reasonable Perl-style regexp to me (and Perl too)... -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-21 13:49 Message: Logged In: YES user_id=1344176 Originator: NO The original bug no longer applies to Python 2.5.0 or 2.6a0. Trent's bug still exists in Python 2.5.0 and 2.6a0 (where 2.6a0 == SVN r54478). -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-01 09:45 Message: Logged In: YES user_id=849994 #1456280 is a duplicate of this. -- Comment By: Trent Mick (tmick) Date: 2006-04-10 19:11 Message: Logged In: YES user_id=34892 I've run into another incarnation of this (it breaks in Python 2.3.5 and Python 2.4.3): >>> import sre >>> sre.compile("(a*)?") Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\Lib\sre.py", line 180, in compile return _compile(pattern, flags) File "C:\Python24\Lib\sre.py", line 227, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat Now granted that the '?' here is redundant for the '*' quantifier on 'a', but compiling this regex works with Python 2.3's "pre" and it works in Perl. The actual use case I've hit here is trying to compile all the regex's in Fedora Core 5's SELinux config files (/etc/selinux/targeted/contexts/files/file_contexts*). The first such regex that broke was: '/usr/share/selinux-policy([^/]*)?/html(/.*)?' -- Comment By: Martin v. Löwis (loewis) Date: 2000-10-01 14:13 Message: Yes, it is still broken in 2.0b2. -- Comment By: Guido van Rossum (gvanrossum) Date: 2000-10-01 00:33 Message: Martin, is this still broken in 2.0? Fredrik, any idea? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=214033&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1685453 ] email package should work better with unicode
Bugs item #1685453, was opened at 2007-03-21 14:39 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=1685453&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email package should work better with unicode Initial Comment: This is a catch-all issue for improving the email package's handling of unicode. For now, please add issues/problems you find with email & unicode to this tracker item. For example: MIMEText()'s first argument should accept a unicode if _charset is also given. It should not be necessary to manually encode the first argument into an 8-bit string. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685453&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-882297 ] socket's makefile file object doesn't work with timeouts.
Bugs item #882297, was opened at 2004-01-22 15:36
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&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.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Facundo Batista (facundobatista)
Summary: socket's makefile file object doesn't work with timeouts.
Initial Comment:
Ok, here's what I did:
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.bind(('', 9009))
>>> s.listen(5)
>>> s.accept()
Now, I opened a second Python interpreter in which I
typed this:
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.connect(('localhost', 9009))
In the first interpreter I did this:
>>> s.accept()
(,
('127.0.0.1', 33059))
>>> s1 = _[0]
>>> s1.settimeout(3)
>>> fd = s1.makefile()
Then I tested that the timeout worked correctly. Still
in the first interpreter:
>>> fd.readline()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()
Now, while that was blocking, I did this in the second
interpreter:
>>> s.send('foo')
3
Which caused this in the first interpreter (as
expected, since I didn't send a newline):
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()
While that was blocking, I did this in the second
interpreter:
>>> s.send('bar\n')
4
Finally sending a newline. But lo and behold! In the
first interpreter I got this:
>>> fd.readline()
'bar\n'
Alas, my 'foo' has been lost!
Anyway, the documentation does explicitly state that
the socket should be in blocking mode, *implying* that
it does no buffering, but it doesn't say anything about
timeouts. Ideally, the file object would buffer enough
data until the readline could return meaningfully, but
failing that, the documentation should probably be
updated to mention that timeouts shouldn't be used with
readline on the returned file object.
--
>Comment By: Facundo Batista (facundobatista)
Date: 2007-03-21 16:45
Message:
Logged In: YES
user_id=752496
Originator: NO
>From the makefile documentation: "The socket must be in blocking mode".
If the socket is in blocking mode, it can NOT have a timeout. I fixed the
docs, and made that explicit.
Regards,
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-03-11 15:46
Message:
Logged In: YES
user_id=44345
Originator: NO
Okay, this is the socket.makefile/timeout bug report. Sorry about the
previous blip.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 09:10
Message:
Logged In: YES
user_id=1188172
If this is a bug, it hasn't been fixed. I reproduced it here.
Assigning to Skip since he worked on "makefile" as it seems.
--
Comment By: John J Lee (jjlee)
Date: 2006-02-01 16:38
Message:
Logged In: YES
user_id=261020
I believe this was fixed in socket.py in rev 32056, closing
bug 707074.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675967 ] Python2.5 can't read a (complex) pickle build by python2.4
Bugs item #1675967, was opened at 2007-03-07 19:16
Message generated for change (Comment added) made by zseil
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&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: Fixed
Priority: 5
Private: No
Submitted By: Michael Vogt (mvo)
Assigned to: Žiga Seilnacht (zseil)
Summary: Python2.5 can't read a (complex) pickle build by python2.4
Initial Comment:
Part of gnome-app-install in ubuntu is a pickle data structure cache. If I
create this pickle with python 2.4 and read it later with 2.5. I get the
following error:
$ python2.5 -c 'import pickle;
pickle.load(open("/var/cache/app-install/menu.p"))'
/usr/lib/python2.5/pickle.py:1124: DeprecationWarning: The sre module is
deprecated, please import re.
__import__(module)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/pickle.py", line 1370, in load
return Unpickler(file).load()
File "/usr/lib/python2.5/pickle.py", line 858, in load
dispatch[key](self)
File "/usr/lib/python2.5/pickle.py", line 1090, in load_global
klass = self.find_class(module, name)
File "/usr/lib/python2.5/pickle.py", line 1126, in find_class
klass = getattr(mod, name)
AttributeError: 'module' object has no attribute '_compile'
With:
$ python2.4 -c 'import pickle;
pickle.load(open("/var/cache/app-install/menu.p"))'
[EMAIL PROTECTED] ~ $
It loads just fine.
The test pickle can be found here:
http://people.ubuntu.com/~mvo/gnome-app-install/menu.p.gz
Cheers,
Michael
--
>Comment By: Žiga Seilnacht (zseil)
Date: 2007-03-21 21:41
Message:
Logged In: YES
user_id=1326842
Originator: NO
The patch was commited as revision 54492, 54497 (2.5).
--
Comment By: Michael Vogt (mvo)
Date: 2007-03-21 10:43
Message:
Logged In: YES
user_id=3206
Originator: YES
Thanks a lot for the patch. It works fine here with the patch.
--
Comment By: Žiga Seilnacht (zseil)
Date: 2007-03-11 16:40
Message:
Logged In: YES
user_id=1326842
Originator: NO
Attaching the patch with a test here. Unpickling
old patterns with this patch works, but it still
issues a DeprecationWarning. The test itself is
a bit obscure, but the other option is to add
a binary file to the test suite.
File Added: sre_pickle_compatibility.diff
--
Comment By: Žiga Seilnacht (zseil)
Date: 2007-03-07 20:43
Message:
Logged In: YES
user_id=1326842
Originator: NO
This happens because of SRE_Pattern objects in jour pickle.
The sre module was renamed to re in Python 2.5, but the
old pickles still expect the _compile function in sre module.
I posted the patch here:
http://freeweb.siol.net/chollus/
Could you try if it fixes the problem for you and in that
case, attach it to this report?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-696206 ] Move modules out of Carbon
Bugs item #696206, was opened at 2003-03-02 22:26 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696206&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jack Jansen (jackjansen) Assigned to: Brett Cannon (bcannon) Summary: Move modules out of Carbon Initial Comment: Some modules that are in the Carbon package for historical reasons need to move to other places (with a compaitbility module in Carbon, for 2.3). Definitely CG, CF and Qt, and for Qd and AE there's a point to be made too (but there are some technical difficulties there). -- >Comment By: Jack Jansen (jackjansen) Date: 2007-03-21 22:02 Message: Logged In: YES user_id=45365 Originator: YES I would just close this bug. The original reason for the report is that the mentioned modules are not technically part of what Apple calls "Carbon", so it was more of a naming thing than anything else. -- Comment By: Collin Winter (collinwinter) Date: 2007-03-21 18:38 Message: Logged In: YES user_id=1344176 Originator: NO I don't understand how having these modules in Carbon is a bug. Why should they be moved out? Assigning to Brett since this seems like something that would fall under his PEP 3108. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696206&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-696206 ] Move modules out of Carbon
Bugs item #696206, was opened at 2003-03-02 13:26 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696206&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: Invalid Priority: 5 Private: No Submitted By: Jack Jansen (jackjansen) Assigned to: Brett Cannon (bcannon) Summary: Move modules out of Carbon Initial Comment: Some modules that are in the Carbon package for historical reasons need to move to other places (with a compaitbility module in Carbon, for 2.3). Definitely CG, CF and Qt, and for Qd and AE there's a point to be made too (but there are some technical difficulties there). -- >Comment By: Brett Cannon (bcannon) Date: 2007-03-21 14:53 Message: Logged In: YES user_id=357491 Originator: NO Closed it is! -- Comment By: Jack Jansen (jackjansen) Date: 2007-03-21 14:02 Message: Logged In: YES user_id=45365 Originator: YES I would just close this bug. The original reason for the report is that the mentioned modules are not technically part of what Apple calls "Carbon", so it was more of a naming thing than anything else. -- Comment By: Collin Winter (collinwinter) Date: 2007-03-21 10:38 Message: Logged In: YES user_id=1344176 Originator: NO I don't understand how having these modules in Carbon is a bug. Why should they be moved out? Assigning to Brett since this seems like something that would fall under his PEP 3108. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696206&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 20:32 Message generated for change (Comment added) made by blakeross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. -- >Comment By: Blake Ross (blakeross) Date: 2007-03-21 15:03 Message: Logged In: YES user_id=1747060 Originator: YES Looks good. I skimmed briefly the tests you mentioned. The issue with test_array appears to be exactly the kind of bug this is intended to identify: it calls array.__init__(...), but array doesn't have its own initializer, so object's is used. I'd guess that the others are failing due to whatever the problem with pickling is (test_descr uses pickling). I haven't looked into that yet. I'm sure cooperative super calling of __init__ isn't all that common (it seems like the mechanism itself isn't used much yet, and may not be until it's done via keyword) but it doesn't seem like such a bad practice, especially when mixins are in the picture. There doesn't seem to be a great alternative. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 14:24 Message: Logged In: YES user_id=6380 Originator: NO I should mention that if we can't get the strict version of this in 2.6, we should be able to get it into 3.0. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 13:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch -- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch -- Comment By: Blake Ross (blakeross) Date: 2007-03-19 15:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __in
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 18:42 Message: Logged In: YES user_id=6380 Originator: NO Well, but since it's been like this for a long time, I don't want to gratuitously break code. At least not in 2.6. So I'm rejecting the stricter patch for 2.6. (However, if you want to submit patches that would fix these breakages anyway, be my guest.) -- Comment By: Blake Ross (blakeross) Date: 2007-03-21 18:03 Message: Logged In: YES user_id=1747060 Originator: YES Looks good. I skimmed briefly the tests you mentioned. The issue with test_array appears to be exactly the kind of bug this is intended to identify: it calls array.__init__(...), but array doesn't have its own initializer, so object's is used. I'd guess that the others are failing due to whatever the problem with pickling is (test_descr uses pickling). I haven't looked into that yet. I'm sure cooperative super calling of __init__ isn't all that common (it seems like the mechanism itself isn't used much yet, and may not be until it's done via keyword) but it doesn't seem like such a bad practice, especially when mixins are in the picture. There doesn't seem to be a great alternative. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 17:24 Message: Logged In: YES user_id=6380 Originator: NO I should mention that if we can't get the strict version of this in 2.6, we should be able to get it into 3.0. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 16:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch -- Comment By: Blake Ross (blakeross) Date: 2007-03-19 21:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden.
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 20:32 Message generated for change (Comment added) made by blakeross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. -- >Comment By: Blake Ross (blakeross) Date: 2007-03-21 15:48 Message: Logged In: YES user_id=1747060 Originator: YES Holding the strict version for 3 makes sense to me. Let me know if you need anything more on my end... thanks for the fast turnaround. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 15:42 Message: Logged In: YES user_id=6380 Originator: NO Well, but since it's been like this for a long time, I don't want to gratuitously break code. At least not in 2.6. So I'm rejecting the stricter patch for 2.6. (However, if you want to submit patches that would fix these breakages anyway, be my guest.) -- Comment By: Blake Ross (blakeross) Date: 2007-03-21 15:03 Message: Logged In: YES user_id=1747060 Originator: YES Looks good. I skimmed briefly the tests you mentioned. The issue with test_array appears to be exactly the kind of bug this is intended to identify: it calls array.__init__(...), but array doesn't have its own initializer, so object's is used. I'd guess that the others are failing due to whatever the problem with pickling is (test_descr uses pickling). I haven't looked into that yet. I'm sure cooperative super calling of __init__ isn't all that common (it seems like the mechanism itself isn't used much yet, and may not be until it's done via keyword) but it doesn't seem like such a bad practice, especially when mixins are in the picture. There doesn't seem to be a great alternative. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 14:24 Message: Logged In: YES user_id=6380 Originator: NO I should mention that if we can't get the strict version of this in 2.6, we should be able to get it into 3.0. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 13:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch -- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:31 Message: Logged In: YES
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. -- >Comment By: Terry J. Reedy (tjreedy) Date: 2007-03-21 19:16 Message: Logged In: YES user_id=593130 Originator: NO I ask myself, what should I expect from the documentation... >>> object.__init__.__doc__ 'x.__init__(...) initializes x; see x.__class__.__doc__ for signature' >>> object.__class__ >>> type.__doc__ "type(object) -> the object's type\ntype(name, bases, dict) -> a new type" and I still don't know ;-). -- Comment By: Blake Ross (blakeross) Date: 2007-03-21 18:48 Message: Logged In: YES user_id=1747060 Originator: YES Holding the strict version for 3 makes sense to me. Let me know if you need anything more on my end... thanks for the fast turnaround. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 18:42 Message: Logged In: YES user_id=6380 Originator: NO Well, but since it's been like this for a long time, I don't want to gratuitously break code. At least not in 2.6. So I'm rejecting the stricter patch for 2.6. (However, if you want to submit patches that would fix these breakages anyway, be my guest.) -- Comment By: Blake Ross (blakeross) Date: 2007-03-21 18:03 Message: Logged In: YES user_id=1747060 Originator: YES Looks good. I skimmed briefly the tests you mentioned. The issue with test_array appears to be exactly the kind of bug this is intended to identify: it calls array.__init__(...), but array doesn't have its own initializer, so object's is used. I'd guess that the others are failing due to whatever the problem with pickling is (test_descr uses pickling). I haven't looked into that yet. I'm sure cooperative super calling of __init__ isn't all that common (it seems like the mechanism itself isn't used much yet, and may not be until it's done via keyword) but it doesn't seem like such a bad practice, especially when mixins are in the picture. There doesn't seem to be a great alternative. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 17:24 Message: Logged In: YES user_id=6380 Originator: NO I should mention that if we can't get the strict version of this in 2.6, we should be able to get it into 3.0. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-20 16:54 Message: Logged In: YES user_id=6380 Originator: NO Here's a stricter version. Unfortunately it breaks a couple of standard modules; this is a confirmation of my doubts whether the style of cooperative super calling of __init__ that you use is really the most common or "best practice". So far I have only fixed string.py (which would otherwise prevent extensions from being built); I haven't looked into why the other tests fail: test_array, test_cpickle, test_descr, test_pickle (and maybe more?). My conclusion: this would probably break too much code to be worth it. So I'll have to revert to the previous version. But anyway, here it is for your perusal. File Added: new_init_strict.patch -- Comment By: Blake Ross (blakeross) Date: 2007-03-19 21:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(
[ python-Bugs-1681671 ] Python and Indeterminate Forms (Math)
Bugs item #1681671, was opened at 2007-03-15 15:28
Message generated for change (Comment added) made by tjreedy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681671&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.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: jehahn (jehahn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python and Indeterminate Forms (Math)
Initial Comment:
Primary example:
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 0 ** 0
1
Per http://mathworld.wolfram.com/Indeterminate.html, 0 ** 0 is an indeterminate
form. 0 ** 0 should probably return NaN and NOT 1.
Other examples include:
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> inf = float("infinity")
>>> inf ** 0
1.0
>>> 1 ** inf
1.0
For a few others, Python provides an arguably correct answer of NaN. Examples:
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> inf = float("infinity")
>>> inf * 0
nan
>>> inf / inf
nan
>>> inf - inf
nan
And, of course, for the most obvious indeterminate form (0/0) Python does
precisely the right thing:
Python 2.3.5 (#1, Mar 20 2005, 20:38:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 0/0
Traceback (most recent call last):
File "", line 1, in ?
ZeroDivisionError: integer division or modulo by zero
It could be argued that the correct thing to do here is to throw an exception -
mathematically speaking these forms are about as meaningful as division by zero
which Python handles by throwing an exception. (unlike Java and IEEE 754,
which do arguably evil things here by returning +/- infinity for the quantity
k/0 for all k != 0)
Unfortunately, some people doing numerical work may have gotten used to the
current Python behavior so the change isn't without risk. And some of the
current values are common "conventions" used to simplify certain common issues.
(e.g. 0 ** 0 == 1) Moreover, I don't know if this is dependent on platform
(having only tried it on a couple of the boxes I have handy.)
However, from a mathematical purist's standpoint, Python is doing the wrong
thing on these counts.
--
>Comment By: Terry J. Reedy (tjreedy)
Date: 2007-03-21 21:09
Message:
Logged In: YES
user_id=593130
Originator: NO
Definition: n**m == 1 multiplied by n m times.
This definition is consistent with n**m * n**k == n**(m+k).
By this definition, the 3 examples you call wrong are correct,
though the latter two involving inf are possibly platform dependent.
Closing as invalid
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-03-17 04:20
Message:
Logged In: YES
user_id=341410
Originator: NO
Python's behavior with respect to floating point arithmetic is left to the
platform's C floating point libraries. For example, on my Windows machine
running Python 2.3.5, float("infinity") raises a ValueError. I would also
point out that 0/0 is integer division in Python 2.3.5 .
For other examples of platform-specific behavior:
Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> inf*0
-1.#IND
>>> inf**0
1.0
>>> 1**inf
Traceback (most recent call last):
File "", line 1, in ?
ValueError: (33, 'Domain error')
>>> inf*0
-1.#IND
>>> inf/inf
-1.#IND
>>> inf-inf
-1.#IND
>>>
So yeah. If you don't like how Python does math, complain to your vendor
(Apple) or compile a version of Python with a C floating point library that
works the way you want it to.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681671&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1685704 ] Command line interface to timeit.py
Bugs item #1685704, was opened at 2007-03-21 23:06 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=1685704&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Heaney (theaney) Assigned to: Nobody/Anonymous (nobody) Summary: Command line interface to timeit.py Initial Comment: In the documentation for timeit.py http://docs.python.org/lib/node808.html it says 25.9.1 Command Line Interface When called as a program from the command line, the following form is used: python timeit.py [-n N] [-r N] [-s S] [-t] [-c] [-h] [statement ...] In fact, for this to work we have to put in the full path to timeit.py. Wouldn't it be better to ask Python to search for it with the -m flag? That is, shouldn't that line be python -m timeit [-n N] [-r N] [-s S] [-t] [-c] [-h] [statement ...] instead? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685704&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 23:32
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Blake Ross (blakeross)
Assigned to: Guido van Rossum (gvanrossum)
Summary: object.__init__ shouldn't allow args/kwds
Initial Comment:
object.__init__ currently allows any amount of args and keywords even though
they're ignored. This is inconsistent with other built-ins, like list, that are
stricter about what they'll accept. It's also inconsistent with object.__new__,
which does throw if any are provided (if the default __init__ is to be used).
To reproduce:
object.__init__(object(), foo, bar=3)
This is a slight irritation when using cooperative super calling. I'd like each
class' __init__ to cherry-pick keyword params it accepts and pass the remaining
ones up the chain, but right now I can't rely on object.__init__ to throw if
there are remaining keywords by that point.
--
>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-03-22 00:28
Message:
Logged In: YES
user_id=6380
Originator: NO
> I think it would also help if calling a method via super() didn't allow
> positional arguments.
That's absurd, *except* for __init__(), where it could make sense
depending on the style of cooperation used. But not enough to enforce this
in the language; in Py3k you will be able to enforce this on a per-class
basis.
> Having two mixins with the same method name and
> without a common parent class is just not sane.
Right. This is a cornerstone of cooperative multiple inheritance that
sometimes seems to be forgotten; there is a big difference between defining
a method and extending a method, and only extending methods can make super
calls.
The __init__ case is an exception, because there's no requirement that a
subclass have a signature compatible with the superclass (if you don't get
this, read up on constructors in C++ or Java).
--
Comment By: Adam Olsen (rhamphoryncus)
Date: 2007-03-21 20:44
Message:
Logged In: YES
user_id=12364
Originator: NO
I think the avoidance of super() is largely *because* of this kind of
leniency. Consider this snippet on python 2.3:
class Base(object):
def __init__(self, foo=None, *args, **kwargs):
super(Base, self).__init__(foo, *args, **kwargs)
Base(foo='bar')
Base('bar', 42)
Base('bar', 42, x=7)
All pass silently, no error checking. Now consider a python 3.0 version,
with a strict object.__init__:
class Base:
def __init__(self, foo=None, *, y='hi', **kwargs):
super(Base, self).__init__(**kwargs)
Base(foo='bar') # Valid, accepted
Base('bar', 42) # Raises exception
Base('bar', x=7) # Raises exception
The error checking added by this bug/patch and the error checking added by
PEP 3102 (keyword-only arguments) make super a lot more sane.
I think it would also help if calling a method via super() didn't allow
positional arguments. If the base class's arguments can't be given as
keyword args then you probably should call it explicitly, rather than
relying on super()'s MRO.
I was also going to suggest super() should automagically create empty
methods your parent classes don't have, but then I realized you really
should have a base class that asserts the lack of such an automagic
method:
class Base(object):
def mymethod(self, myonlyarg='hello world'):
assert not hasattr(super(Base, self), 'mymethod')
By the time you reach this base class you will have stripped off any extra
arguments that your subclasses added, leaving you with nothing to pass up
(and nothing to pass to). Having two mixins with the same method name and
without a common parent class is just not sane.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2007-03-21 19:16
Message:
Logged In: YES
user_id=593130
Originator: NO
I ask myself, what should I expect from the documentation...
>>> object.__init__.__doc__
'x.__init__(...) initializes x; see x.__class__.__doc__ for signature'
>>> object.__class__
>>> type.__doc__
"type(object) -> the object's type\ntype(name, bases, dict) -> a new
type"
and I still don't know ;-).
--
Comment By: Blake Ross (blakeross)
Date: 2007-03-21 18:48
Message:
Logged In: YES
user_id=1747060
Originator: YES
Holding the strict version for 3 makes sense to me. Let me know if you
need anything more on my end... thanks for the fast turnaround.
-
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 21:32
Message generated for change (Comment added) made by rhamphoryncus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Blake Ross (blakeross)
Assigned to: Guido van Rossum (gvanrossum)
Summary: object.__init__ shouldn't allow args/kwds
Initial Comment:
object.__init__ currently allows any amount of args and keywords even though
they're ignored. This is inconsistent with other built-ins, like list, that are
stricter about what they'll accept. It's also inconsistent with object.__new__,
which does throw if any are provided (if the default __init__ is to be used).
To reproduce:
object.__init__(object(), foo, bar=3)
This is a slight irritation when using cooperative super calling. I'd like each
class' __init__ to cherry-pick keyword params it accepts and pass the remaining
ones up the chain, but right now I can't rely on object.__init__ to throw if
there are remaining keywords by that point.
--
Comment By: Adam Olsen (rhamphoryncus)
Date: 2007-03-21 22:46
Message:
Logged In: YES
user_id=12364
Originator: NO
>> I think it would also help if calling a method via super() didn't
allow
>> positional arguments.
>
> That's absurd, *except* for __init__(), where it could make sense
> depending on the style of cooperation used. But not enough to enforce
this
> in the language; in Py3k you will be able to enforce this on a
per-class
> basis.
The vast majority of "positional" arguments can also be given via name.
The rare exceptions (primarily C functions) may not cooperate well anyway,
so you're trading a relatively obscure limitation for better error
detection.
Perhaps not that important though, since it could be taught as bad style
unless absolutely needed.
>> Having two mixins with the same method name and
>> without a common parent class is just not sane.
>
> Right. This is a cornerstone of cooperative multiple inheritance that
> sometimes seems to be forgotten; there is a big difference between
defining
> a method and extending a method, and only extending methods can make
super
> calls.
>
> The __init__ case is an exception, because there's no requirement that
a
> subclass have a signature compatible with the superclass (if you don't
get
> this, read up on constructors in C++ or Java).
I understand the desire for it to be an exception, I fail to see how it
actually is one. The namespace/signature conflicts exist just the same.
The only way I can see to handle incompatible signatures is to add a flag
that says "I am the *ONLY* class allowed to subclass X" (triggering an
error if violated), have super() entirely bypass it, and then call
X.__init__() directly. Even that doesn't handle X's superclasses being
subclassed more than once, and it looks pretty complicated/obscure anyway.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2007-03-21 22:28
Message:
Logged In: YES
user_id=6380
Originator: NO
> I think it would also help if calling a method via super() didn't allow
> positional arguments.
That's absurd, *except* for __init__(), where it could make sense
depending on the style of cooperation used. But not enough to enforce this
in the language; in Py3k you will be able to enforce this on a per-class
basis.
> Having two mixins with the same method name and
> without a common parent class is just not sane.
Right. This is a cornerstone of cooperative multiple inheritance that
sometimes seems to be forgotten; there is a big difference between defining
a method and extending a method, and only extending methods can make super
calls.
The __init__ case is an exception, because there's no requirement that a
subclass have a signature compatible with the superclass (if you don't get
this, read up on constructors in C++ or Java).
--
Comment By: Adam Olsen (rhamphoryncus)
Date: 2007-03-21 18:44
Message:
Logged In: YES
user_id=12364
Originator: NO
I think the avoidance of super() is largely *because* of this kind of
leniency. Consider this snippet on python 2.3:
class Base(object):
def __init__(self, foo=None, *args, **kwargs):
super(Base, self).__init__(foo, *args, **kwargs)
Base(foo='bar')
Base('bar', 42)
Base('bar', 42, x=7)
All pass silently, no error checking. Now consider a python 3.0 version,
with a strict object.__init__:
class Base:
def __init__(self, foo=None, *, y='hi', **kwargs):
super(Base, self).__init__(**kwargs)
Base(foo='bar') # Valid, accepted
Bas
[ python-Bugs-1685773 ] tarfile file names under win32
Bugs item #1685773, was opened at 2007-03-22 08: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=1685773&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ralf (indi4source)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile file names under win32
Initial Comment:
the tarfile module uses normpath() to store the file name in the archive. Under
win32 this results in pathes with backslashes and possible a leading "\". This
confuses the unix tar command.
I suppose the following commands instead of
just normpath():
path = normpath (path)
path = path.replace ("\\", "/")
path = path.lstrip ("/")
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685773&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
