[ python-Bugs-1521491 ] file.seek() influelce write() when opened with a+ mode
Bugs item #1521491, was opened at 2006-07-12 22:04
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&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: Open
Resolution: None
Priority: 5
Submitted By: Lior (rudnik_lior)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.seek() influelce write() when opened with a+ mode
Initial Comment:
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)
Assuming documentation is correct: (from seek() help
"Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write"
Doing the following is __not__ undoing the seek
operation after calling this a few times (Simplified
code snippet):
from __future__ import with_statement
with open(path,'a+') as f:
f.seek(0,2) # go to end
pos = f.tell()
f.seek(0,0)
line = f.readline().strip()
f.seek(0,2) # go to end, not effective if opened
with mode a/a+ (currently bug?)
f.write("something")
Calling the above code repeatedly didnt increase the
file size beyond 166 bytes (in my code)
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-13 07:43
Message:
Logged In: YES
user_id=849994
I also cannot see any problem with the above code and can
append to a file indefinitely. What exactly are you
expecting the code to do, and what do you get? Which OS is this?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-13 06:29
Message:
Logged In: YES
user_id=33168
This seems to work for me on Linux. Maybe we are testing
differently. What o/s and version are you using? Does this
work with Python 2.4? Can you attach a complete test case
that demonstrates this problem?
Thanks.
--
Comment By: Lior (rudnik_lior)
Date: 2006-07-12 22:09
Message:
Logged In: YES
user_id=1364480
Re-tried the code with empty file - it doesnt grow beyond
creating and writting at position 0 so it seems the seek
does influence the write position.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1519452 ] zipfile -- too many files?
Bugs item #1519452, was opened at 2006-07-09 07:57
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&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: None
Priority: 5
Submitted By: Joe Brown (shmengie)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile -- too many files?
Initial Comment:
While creating a huge zipfile (probably too big) the
following error appeared.
Exception exceptions.OverflowError: 'long int too large
to convert to int' in > ignored
I assume this is during the closing of the zipfile,
further assuming too many files were added to the archive.
--
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 09:47
Message:
Logged In: YES
user_id=580910
The problem with zipfile is not the number of files, but the size of the
archive.
The basic zip file format stores file sizes as 32 bit (signed) integers, there
is an
extension for using 64 bit integers, but that isn't supported in python 2.4.
--
Comment By: Joe Brown (shmengie)
Date: 2006-07-12 04:17
Message:
Logged In: YES
user_id=729883
Windows 2.5 beta 2 responded like this:
Traceback (most recent call last):
File "C:\python_scripts\archive.py", line 27, in
main()
File "C:\python_scripts\archive.py", line 23, in main
zipper(zip, folder)
File "C:\python_scripts\archive.py", line 15, in zipper
zip.write(os.path.join(root, item))
File "C:\Python25\lib\zipfile.py", line 561, in write
self._writecheck(zinfo)
File "C:\Python25\lib\zipfile.py", line 536, in _writecheck
raise LargeZipFile("Zipfile size would require ZIP64
extensions")
zipfile.LargeZipFile: Zipfile size would require ZIP64
extensions
C:\Python25\lib\struct.py:63: DeprecationWarning: struct
integer overflow maskin
g is deprecated
return o.pack(*args)
--
Comment By: Joe Brown (shmengie)
Date: 2006-07-11 22:08
Message:
Logged In: YES
user_id=729883
The zip file was on order of 6-9 GBs, surely over 32000
files. I will give Python2.5 a shot and see how that works.
I've stumbled on another bug with tarfile. It's not
reporting an error, but I only find 350 files when I
unarchive. That's entirely different bug tho :-o
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-11 19:47
Message:
Logged In: YES
user_id=580910
How large is the resulting file? Zipfile in python2.4 cannot handle zipfiles
that
require the zip64 extensions and fails misserably when you do cross that limit.
This was fixed in python 2.5.
--
Comment By: Joe Brown (shmengie)
Date: 2006-07-09 08:01
Message:
Logged In: YES
user_id=729883
Platform: Windows SBS 2003
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1519452 ] zipfile -- too many files?
Bugs item #1519452, was opened at 2006-07-09 07:57
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&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: None
Priority: 5
Submitted By: Joe Brown (shmengie)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile -- too many files?
Initial Comment:
While creating a huge zipfile (probably too big) the
following error appeared.
Exception exceptions.OverflowError: 'long int too large
to convert to int' in > ignored
I assume this is during the closing of the zipfile,
further assuming too many files were added to the archive.
--
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 10:17
Message:
Logged In: YES
user_id=580910
hmm, I should read all new comments before responding :-(
To use the ZIP64 extensions with python2.5 you must add 'allowZip64=True' to
arguments of the zipfile constructor. ZIP64 is disabled by default because the
unix zip tools don't support zip64.
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 09:47
Message:
Logged In: YES
user_id=580910
The problem with zipfile is not the number of files, but the size of the
archive.
The basic zip file format stores file sizes as 32 bit (signed) integers, there
is an
extension for using 64 bit integers, but that isn't supported in python 2.4.
--
Comment By: Joe Brown (shmengie)
Date: 2006-07-12 04:17
Message:
Logged In: YES
user_id=729883
Windows 2.5 beta 2 responded like this:
Traceback (most recent call last):
File "C:\python_scripts\archive.py", line 27, in
main()
File "C:\python_scripts\archive.py", line 23, in main
zipper(zip, folder)
File "C:\python_scripts\archive.py", line 15, in zipper
zip.write(os.path.join(root, item))
File "C:\Python25\lib\zipfile.py", line 561, in write
self._writecheck(zinfo)
File "C:\Python25\lib\zipfile.py", line 536, in _writecheck
raise LargeZipFile("Zipfile size would require ZIP64
extensions")
zipfile.LargeZipFile: Zipfile size would require ZIP64
extensions
C:\Python25\lib\struct.py:63: DeprecationWarning: struct
integer overflow maskin
g is deprecated
return o.pack(*args)
--
Comment By: Joe Brown (shmengie)
Date: 2006-07-11 22:08
Message:
Logged In: YES
user_id=729883
The zip file was on order of 6-9 GBs, surely over 32000
files. I will give Python2.5 a shot and see how that works.
I've stumbled on another bug with tarfile. It's not
reporting an error, but I only find 350 files when I
unarchive. That's entirely different bug tho :-o
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-11 19:47
Message:
Logged In: YES
user_id=580910
How large is the resulting file? Zipfile in python2.4 cannot handle zipfiles
that
require the zip64 extensions and fails misserably when you do cross that limit.
This was fixed in python 2.5.
--
Comment By: Joe Brown (shmengie)
Date: 2006-07-09 08:01
Message:
Logged In: YES
user_id=729883
Platform: Windows SBS 2003
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit
(Intel)] on win32
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521375 ] ctypes test overwrites /dev/null
Bugs item #1521375, was opened at 2006-07-12 20:22 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Scot Doyle (scotdoyle) Assigned to: Thomas Heller (theller) Summary: ctypes test overwrites /dev/null Initial Comment: Steps to reproduce on Debian Sarge: 1. ls -l /dev/null 2. wget http://www.python.org/ftp/python/2.5/Python-2.5b2.tgz 3. tar xvzf Pyth* 4. cd Pyth* 5. ./configure 6. make 7. su 8. make test 9. ls -l /dev/null /dev/null goes from being a special character device to a normal file of length zero. The following command can be used instead of step 8 above to delete /dev/null ./python -c 'import ctypes.test.test_find' To recreate /dev/null: 1. su 2. rm /dev/null 3. mknod -m 666 /dev/null c 1 3 4. chown root:root /dev/null -- >Comment By: Thomas Heller (theller) Date: 2006-07-13 10:28 Message: Logged In: YES user_id=11105 Scot, your patch is not correct because 'cmd' is never executed. However, I was able to reproduce the overwriting of /dev/null by calling 'ctypes.util.find_library' for a shared lib that does not exist. Attached is a new patch 'util.diff' which fixes the problem for me. Can you please verify that it also works for you? Thanks for finding the bug and locating the problem! -- Comment By: Scot Doyle (scotdoyle) Date: 2006-07-13 00:17 Message: Logged In: YES user_id=1554504 Hey Thomas, that pointer is just what I needed :-) /dev/null was being deleted by gcc. Discussion at http://www.cs.helsinki.fi/linux/linux-kernel/2001-38/1503.html The attached patch fixed the problem on Debian Sarge and Ubuntu 6.06. -- Comment By: Thomas Heller (theller) Date: 2006-07-12 20:53 Message: Logged In: YES user_id=11105 Now, that is an 'interesting' bug. ctypes.util.find_library does execute shell commands that happen to have '/dev/null' in them, but it is completely unclear to me how one can overwrite /dev/null (even if root). Can you see anything that's wrong there (That code is not from me, and I'm not at all an expert in linux programming)? BTW, I cannot reproduce this on ubuntu with 'sudo ./python -c "import ctypes.test.test_find"'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512814 ] Incorrect lineno's in code objects
Bugs item #1512814, was opened at 2006-06-26 18:01 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512814&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Thomas Wouters (twouters) >Assigned to: Neal Norwitz (nnorwitz) Summary: Incorrect lineno's in code objects Initial Comment: The 2.5 compiler forgets how to count linenumbers in certain situations: >>> s255 = "".join(["\n"] * 255 + ["spam"]) >>> s256 = "".join(["\n"] * 256 + ["spam"]) >>> exec s255 Traceback (most recent call last): File "", line 1, in File "", line 256, in NameError: name 'spam' is not defined >>> exec s256 Traceback (most recent call last): File "", line 1, in File "", line 1, in NameError: name 'spam' is not defined Notice the 'line 1' linenumber in the case of 256 blank lines. The same happens for 'pass' statements or 'if 0' blocks instead of blank lines. The problem is in the actual code objects created: >>> dis.disco(compile(s255, "", "exec")) 256 0 LOAD_NAME0 (spam) 3 POP_TOP 4 LOAD_CONST 0 (None) 7 RETURN_VALUE >>> dis.disco(compile(s256, "", "exec")) 1 0 LOAD_NAME0 (spam) 3 POP_TOP 4 LOAD_CONST 0 (None) 7 RETURN_VALUE -- >Comment By: Thomas Wouters (twouters) Date: 2006-07-13 11:58 Message: Logged In: YES user_id=34209 Yep, the patch seems to work, also for the other case someone pointed out to me, that was still broken after the last fix: >>> exec "import os\ns='''" + "\n"*256 + "'''\n1/0\n" Traceback (most recent call last): File "", line 1, in File "", line 1, in ZeroDivisionError: integer division or modulo by zero I tried a couple of other ways to get large linenumbers and complex(er) parsing structures, and they all seem to work right. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-13 07:59 Message: Logged In: YES user_id=33168 Try the attached patch on for size. Let me know if you can find any other holes. -- Comment By: Thomas Wouters (twouters) Date: 2006-07-12 15:11 Message: Logged In: YES user_id=34209 Unfortunately, it isn't quite fixed. It's fixed for code in the global scope, but not for functions: >>> s255 = "def foo():\n " + "".join(["\n "] * 254 + [" spam\n"]) >>> exec s255 >>> dis.dis(foo) .256 0 LOAD_GLOBAL 0 (spam) . 3 POP_TOP . 4 LOAD_CONST 0 (None) . 7 RETURN_VALUE >>> s256 = "def foo():\n " + "".join(["\n "] * 255 + [" spam\n"]) >>> exec s256 >>> dis.dis(foo) . 1 0 LOAD_GLOBAL 0 (spam) . 3 POP_TOP . 4 LOAD_CONST 0 (None) . 7 RETURN_VALUE I haven't tried figuring out for what else it's broken like this, sorry :) -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 02:04 Message: Logged In: YES user_id=33168 Committed revision 50500. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512814&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1519816 ] urllib2 proxy does not work in 2.4.3 and 2.5b
Bugs item #1519816, was opened at 2006-07-10 10:29 Message generated for change (Comment added) made by mniklas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michal Niklas (mniklas) Assigned to: Nobody/Anonymous (nobody) >Summary: urllib2 proxy does not work in 2.4.3 and 2.5b Initial Comment: My python app had to retrieve some web pages and while our network environment requires proxy it uses urllib2 opener (source is in attachment). It worked very well on older Python interpreters: ActivePython 2.4.2 Build 248 (ActiveState Corp.) based on Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310 32 bit (Intel)] on win32 It works on linux with 2.3 and 2.4.1: Python 2.4.1 (#2, May 5 2005, 11:32:06) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 But it does not work with newest 2.4.3 on Linux: Python 2.4.3 (#1, Jul 10 2006, 09:57:52) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Desired result: isof-mark:~# python2.3 proxy_bug.py trying http://www.python.org ... OK. We have reply from http://www.python.org. Size: 13757 [b] http://www.w3.org/TR/xhtml1/DTD/ xhtml1-transitional.dtd"> http://www.w3.org/ 1999/xhtml"> design by pollenation Copyright ÃÅ 1990-2006, Python Software Foundation Legal Statements isof-mark:~# /usr/local/bin/python proxy_bug.py trying http://www.python.org ... Traceback (most recent call last): File "proxy_bug.py", line 37, in ? get_page() File "proxy_bug.py", line 27, in get_page f = urllib2.urlopen(request) File "/usr/local/lib/python2.4/urllib2.py", line 130, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.4/urllib2.py", line 364, in open response = meth(req, response) File "/usr/local/lib/python2.4/urllib2.py", line 471, in http_response response = self.parent.error( File "/usr/local/lib/python2.4/urllib2.py", line 402, in error return self._call_chain(*args) File "/usr/local/lib/python2.4/urllib2.py", line 337, in _call_chain result = func(*args) File "/usr/local/lib/python2.4/urllib2.py", line 480, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) urllib2.HTTPError: HTTP Error 407: Proxy Authentication Required I have raported it on ActiveState bug list (http:// bugs.activestate.com/show_bug.cgi?id=47018) while I first spot this bug on their destribution but it seems that bug is in others distributions too. Regards, Michal Niklas -- >Comment By: Michal Niklas (mniklas) Date: 2006-07-13 12:09 Message: Logged In: YES user_id=226518 2.5b2 does not work any better: Python 2.5b2 (r25b2:50512, Jul 11 2006, 10:16:14) [MSC v.1310 32 bit (Intel)] on win32 Result is the same as in 2.5b1 :( -- Comment By: Michal Niklas (mniklas) Date: 2006-07-11 08:27 Message: Logged In: YES user_id=226518 Tried it with 2.5 beta 1 and it is not better :( c:\tools\pyscripts\scripts>c:\python25\python2.5 Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC v.1310 32 bit (Intel)] on win32 c:\tools\pyscripts\scripts>c:\python25\python2.5 proxy_bug.py trying http://www.python.org ... Traceback (most recent call last): File "proxy_bug.py", line 37, in get_page() File "proxy_bug.py", line 27, in get_page f = urllib2.urlopen(request) File "c:\python25\lib\urllib2.py", line 121, in urlopen return _opener.open(url, data) File "c:\python25\lib\urllib2.py", line 380, in open response = meth(req, response) File "c:\python25\lib\urllib2.py", line 491, in http_response 'http', request, response, code, msg, hdrs) File "c:\python25\lib\urllib2.py", line 412, in error result = self._call_chain(*args) File "c:\python25\lib\urllib2.py", line 353, in _call_chain result = func(*args) File "c:\python25\lib\urllib2.py", line 831, in http_error_407 authority, req, headers) File "c:\python25\lib\urllib2.py", line 795, in http_error_auth_reqed return self.retry_http_basic_auth(host, req, realm) File "c:\python25\lib\urllib2.py", line 805, in retry_http_basic_auth return self.parent.open(req) File "c:\python25\lib\urllib2.py", line 380, in open response = meth(req, response) File "c:\python25\lib\urllib2.py", line 491, in http_response 'http', request, response, code, msg, hdrs) File "c:\python25\lib\urllib2.py", line 418, in error return self._call_chain(*args) File "c:\python25\lib\urllib2.py", line 353, in _call_chain result = func(*args) File "c:\python25\lib\urllib2.py", line 499, in http_error_default raise HTTPError(req.get_full_url(),
[ python-Bugs-1514428 ] NaN comparison in Decimal broken
Bugs item #1514428, was opened at 2006-06-29 16:19
Message generated for change (Comment added) made by nmm
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm)
Assigned to: Raymond Hettinger (rhettinger)
Summary: NaN comparison in Decimal broken
Initial Comment:
Methinks this is a bit off :-) True should be False.
Python 2.5b1 (trunk:47059, Jun 29 2006, 14:26:46)
[GCC 4.1.0 (SUSE Linux)] on linux2
>>> import decimal
>>> d = decimal.Decimal
>>> inf = d("inf")
>>> nan = d("nan")
>>> nan > inf
True
>>> nan < inf
False
>>> inf > nan
True
>>> inf < nan
False
b
--
>Comment By: Nick Maclaren (nmm)
Date: 2006-07-13 10:35
Message:
Logged In: YES
user_id=42444
It's still there in Beta 2.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521726 ] isinstance failure in 2.6 Beta 2
Bugs item #1521726, was opened at 2006-07-13 10:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521726&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
Submitted By: Nick Maclaren (nmm)
Assigned to: Nobody/Anonymous (nobody)
Summary: isinstance failure in 2.6 Beta 2
Initial Comment:
Linux gosset 2.6.16.13-4-smp #1 SMP Wed May 3 04:53:23
UTC 2006 x86_64 x86_64 x86_64 GNU/Linux
./python Lib/test/test_compile.py
File "Lib/test/test_compile.py", line 6, in
class TestSpecifics(unittest.TestCase):
File "Lib/test/test_compile.py", line 399, in test_main
test_support.run_unittest(TestSpecifics)
File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
422, in run_unittest
run_suite(suite, testclass)
File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
407, in run_suiteraise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
File "Lib/test/test_compile.py", line 226, in
test_unary_minus
self.assertTrue(isinstance(eval("%s" % (-sys.maxint
- 1)), int))
./python
Python 2.5b2 (r25b2:50512, Jul 13 2006, 11:33:15)
>>> import sys
>>> print sys.maxint
9223372036854775807
>>> print "%s" % (-sys.maxint - 1)
-9223372036854775808
>>> print isinstance(eval("%s" % (-sys.maxint - 1)), int)
False
>>> print isinstance(eval("%s" % (-sys.maxint)), int)
True
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521726&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1469557 ] FTP modue functions are not re-entrant, give odd exceptions
Bugs item #1469557, was opened at 2006-04-13 02:13
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&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: Open
>Resolution: Invalid
Priority: 5
Submitted By: Bruce (brucepeterson)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTP modue functions are not re-entrant,give odd exceptions
Initial Comment:
If I define a class using the Thread and FTP moudles,
start a process which gathers FTP responses,
additional calls to the class may have the responses
of the thread instead of the main loop (or vice versa)
This causes weird and unexpected exceptions from the
ftplib.
For instance I get the following error when the
thread process does a pwd() function
error_reply: 213 34603008
The "213" reply is a response from the main process
size() function
-
Code
-
from time import sleep
from threading import Thread
class ftpMachine(Thread, ftplib.FTP):
def __init__(self, svr, user, passwd):
Thread.__init__(self)
ftplib.FTP.__init__(self, svr, user, passwd)
def run(self):
for x in xrange(20):
output="Thread -"+str(self.nlst())[:30]
print output
sleep (0.0100)
def main():
aCon = ftpMachine("LocalFTP", "user", "")
aCon.start()
for x in xrange(20):
output = "Main -- " + str(aCon.size("File"))
print output
sleep (0.010)
Workround:
Rewrite code to create a third worker thread for
response isolation? Don't know that this would solve
the problem.
---
Exception example
---
Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
self.run()
File "dualFTPIssue.py", line 17, in run
output = "Thread output " + str(self.nlst())[:30]
+" ..."
File "C:\Python24\lib\ftplib.py", line 448, in nlst
self.retrlines(cmd, files.append)
File "C:\Python24\lib\ftplib.py", line 396, in
retrlines
conn = self.transfercmd(cmd)
File "C:\Python24\lib\ftplib.py", line 345, in
transfercmd
return self.ntransfercmd(cmd, rest)[0]
File "C:\Python24\lib\ftplib.py", line 321, in
ntransfercmd
host, port = self.makepasv()
File "C:\Python24\lib\ftplib.py", line 299, in
makepasv
host, port = parse227(self.sendcmd('PASV'))
File "C:\Python24\lib\ftplib.py", line 566, in
parse227
raise error_reply, resp
error_reply: 213 34603008
--
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 13:54
Message:
Logged In: YES
user_id=580910
IMHO this isn't a bug, your accessing a shared resource (the FTP connection)
from two threads without locking. Most of python's libraries aren't safe for
this
kind of use.
BTW. The fact that you subclass form thread and ftplib.FTP is immaterial, you
will get the same effect if you create an ftplib.FTP and then use it in two
threads.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1514420 ] Missing module code does spurious file search
Bugs item #1514420, was opened at 2006-06-29 18:13
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514420&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: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing module code does spurious file search
Initial Comment:
Now, exactly WHY is it looking for a file called
? :-)
This bug has been present since at least 2.3.3 - I
can't be bothered to
check back further. Not surprisingly, it causes
misbehaviour if there
is a file called in any of the places searched,
but it doesn't
strike me as the world's most catastrophic bug.
strace -e open python
Python 2.5b1 (trunk:47059, Jun 29 2006, 14:26:46)
[GCC 4.1.0 (SUSE Linux)] on linux2
>>> import dismal
open("dismal.so", O_RDONLY) = -1 ENOENT (No
such file or directory)open("dismalmodule.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("dismal.py", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("dismal.pyc", O_RDONLY)= -1 ENOENT (No
such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/dismal.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/plat-linux2/",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/lib-tk/",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/lib-dynload/",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/nmm/Python_2.5/lib/python2.5/site-packages/",
O_RDONLY) = -1 ENOENT (No such file or directory)
File "", line 1, in
ImportError: No module named dismal
>>>
--
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-13 14:04
Message:
Logged In: YES
user_id=580910
It's probably looking for a file named because the co_filename
attribute for code that's executed from the interactive prompt has that value:
>>> import sys
>>> f = sys._getframe(0)
>>> f.f_code.co_filename
''
I agree that looking for that file is rather pointless and a bug.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514420&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521375 ] ctypes test overwrites /dev/null
Bugs item #1521375, was opened at 2006-07-12 13:22 Message generated for change (Comment added) made by scotdoyle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Scot Doyle (scotdoyle) Assigned to: Thomas Heller (theller) Summary: ctypes test overwrites /dev/null Initial Comment: Steps to reproduce on Debian Sarge: 1. ls -l /dev/null 2. wget http://www.python.org/ftp/python/2.5/Python-2.5b2.tgz 3. tar xvzf Pyth* 4. cd Pyth* 5. ./configure 6. make 7. su 8. make test 9. ls -l /dev/null /dev/null goes from being a special character device to a normal file of length zero. The following command can be used instead of step 8 above to delete /dev/null ./python -c 'import ctypes.test.test_find' To recreate /dev/null: 1. su 2. rm /dev/null 3. mknod -m 666 /dev/null c 1 3 4. chown root:root /dev/null -- >Comment By: Scot Doyle (scotdoyle) Date: 2006-07-13 08:56 Message: Logged In: YES user_id=1554504 Yes, not executing the command was one way to fix the bug :-) Thanks for catching that. I verified the new patch to work. -- Comment By: Thomas Heller (theller) Date: 2006-07-13 03:28 Message: Logged In: YES user_id=11105 Scot, your patch is not correct because 'cmd' is never executed. However, I was able to reproduce the overwriting of /dev/null by calling 'ctypes.util.find_library' for a shared lib that does not exist. Attached is a new patch 'util.diff' which fixes the problem for me. Can you please verify that it also works for you? Thanks for finding the bug and locating the problem! -- Comment By: Scot Doyle (scotdoyle) Date: 2006-07-12 17:17 Message: Logged In: YES user_id=1554504 Hey Thomas, that pointer is just what I needed :-) /dev/null was being deleted by gcc. Discussion at http://www.cs.helsinki.fi/linux/linux-kernel/2001-38/1503.html The attached patch fixed the problem on Debian Sarge and Ubuntu 6.06. -- Comment By: Thomas Heller (theller) Date: 2006-07-12 13:53 Message: Logged In: YES user_id=11105 Now, that is an 'interesting' bug. ctypes.util.find_library does execute shell commands that happen to have '/dev/null' in them, but it is completely unclear to me how one can overwrite /dev/null (even if root). Can you see anything that's wrong there (That code is not from me, and I'm not at all an expert in linux programming)? BTW, I cannot reproduce this on ubuntu with 'sudo ./python -c "import ctypes.test.test_find"'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521947 ] possible bug in mystrtol.c with recent gcc
Bugs item #1521947, was opened at 2006-07-13 19: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=1521947&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: possible bug in mystrtol.c with recent gcc Initial Comment: python 2.5b2 compiled with gentoo's gcc 4.1.1 and -O2 fails test_unary_minus in test_compile.py. Some investigating showed that the -ftree-vrp pass of that gcc (implied by -O2) optimizes out the "result == -result" test on line 215 of PyOS_strtol, meaning PyOS_strtol of the most negative long will incorrectly overflow. Python deals with this in this case by constructing a python long object instead of a python int object, so at least in this case the problem is not serious. I have no idea if there is a case where this is a "real" problem. At first I reported this as a gentoo compiler bug, but got the reply that: """ I'm pretty sure it's broken. -LONG_MIN overflows when LONG_MIN < -LONG_MAX, and in standard C as well as "GNU C", behaviour after overflow on signed integer operations is undefined. """ (see https://bugs.gentoo.org/show_bug.cgi?id=140133) So now I'm reporting this here. There seems to be a LONG_MIN constant in limits.h here that could checked against instead, but I have absolutely no idea how standard that is. Or this could be a compiler bug after all, in which case I would appreciate information I Can use to back that up :) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521947&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521950 ] shlex.split() does not tokenize like the shell
Bugs item #1521950, was opened at 2006-07-13 10:44 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=1521950&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Dan Christian (robodan) Assigned to: Nobody/Anonymous (nobody) Summary: shlex.split() does not tokenize like the shell Initial Comment: When shlex.split defines tokens, it doesn't properly interpret ';', '&', and '&&'. These should always be place in a separate token (unless inside a string). The shell treats the following as identical cases, but shlex.split doesn't: echo hi&&echo bye echo hi && echo bye echo hi;echo bye echo hi ; echo bye echo hi&echo bye echo hi & echo bye shlex.split makes these cases ambiguous: echo 'foo&' echo foo& echo '&&exit' echo &&exit -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521950&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521375 ] ctypes test overwrites /dev/null
Bugs item #1521375, was opened at 2006-07-12 20:22 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&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: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Scot Doyle (scotdoyle) Assigned to: Thomas Heller (theller) Summary: ctypes test overwrites /dev/null Initial Comment: Steps to reproduce on Debian Sarge: 1. ls -l /dev/null 2. wget http://www.python.org/ftp/python/2.5/Python-2.5b2.tgz 3. tar xvzf Pyth* 4. cd Pyth* 5. ./configure 6. make 7. su 8. make test 9. ls -l /dev/null /dev/null goes from being a special character device to a normal file of length zero. The following command can be used instead of step 8 above to delete /dev/null ./python -c 'import ctypes.test.test_find' To recreate /dev/null: 1. su 2. rm /dev/null 3. mknod -m 666 /dev/null c 1 3 4. chown root:root /dev/null -- >Comment By: Thomas Heller (theller) Date: 2006-07-13 19:44 Message: Logged In: YES user_id=11105 Thanks. Commited as r50619. -- Comment By: Scot Doyle (scotdoyle) Date: 2006-07-13 15:56 Message: Logged In: YES user_id=1554504 Yes, not executing the command was one way to fix the bug :-) Thanks for catching that. I verified the new patch to work. -- Comment By: Thomas Heller (theller) Date: 2006-07-13 10:28 Message: Logged In: YES user_id=11105 Scot, your patch is not correct because 'cmd' is never executed. However, I was able to reproduce the overwriting of /dev/null by calling 'ctypes.util.find_library' for a shared lib that does not exist. Attached is a new patch 'util.diff' which fixes the problem for me. Can you please verify that it also works for you? Thanks for finding the bug and locating the problem! -- Comment By: Scot Doyle (scotdoyle) Date: 2006-07-13 00:17 Message: Logged In: YES user_id=1554504 Hey Thomas, that pointer is just what I needed :-) /dev/null was being deleted by gcc. Discussion at http://www.cs.helsinki.fi/linux/linux-kernel/2001-38/1503.html The attached patch fixed the problem on Debian Sarge and Ubuntu 6.06. -- Comment By: Thomas Heller (theller) Date: 2006-07-12 20:53 Message: Logged In: YES user_id=11105 Now, that is an 'interesting' bug. ctypes.util.find_library does execute shell commands that happen to have '/dev/null' in them, but it is completely unclear to me how one can overwrite /dev/null (even if root). Can you see anything that's wrong there (That code is not from me, and I'm not at all an expert in linux programming)? BTW, I cannot reproduce this on ubuntu with 'sudo ./python -c "import ctypes.test.test_find"'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1522016 ] filter() doesn't use __len__ of str/unicode/tuple subclasses
Bugs item #1522016, was opened at 2006-07-13 15:25
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=1522016&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: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: filter() doesn't use __len__ of str/unicode/tuple subclasses
Initial Comment:
Consider the following code:
>>> class badstr(str):
... def __len__(self):
... return 6
... def __getitem__(self, index):
... return "a"
...
>>> filter(None, badstr("bbb"))
'aaa'
I would have expected the answer to be 'aa'.
The cause for this is that
Python/bltinmodule.c:filter{string,unicode,tuple} all
call PyString_Size (or the appropriate equivalent),
even if the sequence is a subclass of one of these
types. This bypasses any overloading of __len__ done by
the subclass, as demonstrated above.
If filter() is going to respect the subclass's
__getitem__ overload, it should also respect
overloading of __len__. The attached patch corrects this.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522016&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1517509 ] filter() implementation does not match docs
Bugs item #1517509, was opened at 2006-07-05 09:09
Message generated for change (Comment added) made by collinwinter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517509&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: Wont Fix
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: filter() implementation does not match docs
Initial Comment:
The docs for the built-in function filter() claim that
"filter(function, list) is equivalent to [item for item
in list if function(item)] if function is not None and
[item for item in list if item] if function is None".
>>> class infinite_str(str):
... def __getitem__(self, index):
... return "a"
...
>>> filter(None, infinite_str("1234"))
''
Now, if we translate this to a listcomp according to
the docs:
>>> [x for x in infinite_str("1234") if x]
The listcomp version proceeds to chew up memory until
it exhausts the system resources or is killed by the user.
If the docs are to be believed, the filter() version
should do the same thing.
--
>Comment By: Collin Winter (collinwinter)
Date: 2006-07-13 15:26
Message:
Logged In: YES
user_id=1344176
I've posted a patch for the __len__ issue; it's SF #1522016.
--
Comment By: Collin Winter (collinwinter)
Date: 2006-07-05 11:16
Message:
Logged In: YES
user_id=1344176
I wasn't just reviewing the docs; I came upon this while
re-implementing filter() in pure Python for a compatibility
module I'm working on. I discovered this particular
implementation detail when my naive implementation (as a
listcomp) didn't pass test_builtin.
My question is why filter() even cares about __len__, ie,
why it doesn't simply use the iterator protocol. This is
especially curious since filter() actively ignores the
iterator protocol when dealing with subclasses of str,
unicode and tuple:
>>> class badstr(str):
... def __len__(self):
... return 4
... def __getitem__(self, index):
... return "a"
... def __iter__(self):
... for i in range(5):
... yield "b"
...
>>> filter(None, badseq(""))
>>> [x for x in badseq("") if x]
['b', 'b', 'b', 'b', 'b']
Ignore the difference in return types (which is expected),
these two do not do the same thing; filter() uses a
combination of __len__ and __getitem__ while the listcomp
version uses the iterator protocol.
Clearly, in this case, "is equivalent to" means "bears only
a superficial relationship to".
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-07-05 10:58
Message:
Logged In: YES
user_id=80475
Please take a larger view when reviewing the docs.
The listcomp analogy is very helpful in explaining what
filter() does and readers would not benefit by its removal.
Throughtout the docs, the phrase "is equivalent to" does
not mean "is identical to" or "exactly the same as". In
this case, you have isolated a non-guaranteed
implementation detail that is almost always irrelevant.
When an object such as infinite_str lies about its length,
the consequent behavior is undefined. It is not hard to
produce weird results when objects violate basic
invariants such as len(istr)!=len(list(istr)) or the
expected relation between __eq__ and __hash__.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517509&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1522046 ] RPM build fails for Py2.5b2
Bugs item #1522046, was opened at 2006-07-13 21:55
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=1522046&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: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Behnel (scoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: RPM build fails for Py2.5b2
Initial Comment:
Using Misc/RPM/python-2.5.spec, Python 2.5b2 fails to
compile into an RPM on my machine (SuSE 10.1, AMD64,
gcc 4.1). Unlike with b1, I get loads of errors saying:
"ld: cannot find -lpython2.5"
The funny thing is that it continues to build and only
fails at the end when collecting the files for the RPM.
I use
configure --enable-shared --enable-unicode=ucs4 \
--enable-ipv6 --with-pymalloc --prefix=/usr \
--libdir=/usr/lib64
The shared library is correctly built before these
errors come up. The error appear on the "sharedmods"
target. I also tried setting LD_LIBRARY_PATH by hand,
although the build script sets it before starting to
build the modules - no help.
What *does* help is adding "-L." to the LDFLAGS in
Makefile.pre.in:
sed -e '/DIR=.*lib$/ s|/lib$|/%{libdirname}| ; \
/LDFLAGS/ s|LDFLAGS=|LDFLAGS= -L. |'\
./Makefile.pre.in.old >Makefile.pre.in
The "DIR=" is for an x86_64 bug that installs Python to
the wrong directory (/usr/lib instead of /usr/lib64).
I tried building Py2.5 by hand (configure/make) and
that also works nicely.
I attached a patch that fixes the problems I encountered.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522046&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1517509 ] filter() implementation does not match docs
Bugs item #1517509, was opened at 2006-07-05 08:09
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517509&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: Wont Fix
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: filter() implementation does not match docs
Initial Comment:
The docs for the built-in function filter() claim that
"filter(function, list) is equivalent to [item for item
in list if function(item)] if function is not None and
[item for item in list if item] if function is None".
>>> class infinite_str(str):
... def __getitem__(self, index):
... return "a"
...
>>> filter(None, infinite_str("1234"))
''
Now, if we translate this to a listcomp according to
the docs:
>>> [x for x in infinite_str("1234") if x]
The listcomp version proceeds to chew up memory until
it exhausts the system resources or is killed by the user.
If the docs are to be believed, the filter() version
should do the same thing.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-07-13 17:35
Message:
Logged In: YES
user_id=80475
It's a speed hack. The result list for filter() is
pre-allocated to the input length and then resized downward
to the actual length.
Stop posting patches for non-bugs.
--
Comment By: Collin Winter (collinwinter)
Date: 2006-07-13 14:26
Message:
Logged In: YES
user_id=1344176
I've posted a patch for the __len__ issue; it's SF #1522016.
--
Comment By: Collin Winter (collinwinter)
Date: 2006-07-05 10:16
Message:
Logged In: YES
user_id=1344176
I wasn't just reviewing the docs; I came upon this while
re-implementing filter() in pure Python for a compatibility
module I'm working on. I discovered this particular
implementation detail when my naive implementation (as a
listcomp) didn't pass test_builtin.
My question is why filter() even cares about __len__, ie,
why it doesn't simply use the iterator protocol. This is
especially curious since filter() actively ignores the
iterator protocol when dealing with subclasses of str,
unicode and tuple:
>>> class badstr(str):
... def __len__(self):
... return 4
... def __getitem__(self, index):
... return "a"
... def __iter__(self):
... for i in range(5):
... yield "b"
...
>>> filter(None, badseq(""))
>>> [x for x in badseq("") if x]
['b', 'b', 'b', 'b', 'b']
Ignore the difference in return types (which is expected),
these two do not do the same thing; filter() uses a
combination of __len__ and __getitem__ while the listcomp
version uses the iterator protocol.
Clearly, in this case, "is equivalent to" means "bears only
a superficial relationship to".
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-07-05 09:58
Message:
Logged In: YES
user_id=80475
Please take a larger view when reviewing the docs.
The listcomp analogy is very helpful in explaining what
filter() does and readers would not benefit by its removal.
Throughtout the docs, the phrase "is equivalent to" does
not mean "is identical to" or "exactly the same as". In
this case, you have isolated a non-guaranteed
implementation detail that is almost always irrelevant.
When an object such as infinite_str lies about its length,
the consequent behavior is undefined. It is not hard to
produce weird results when objects violate basic
invariants such as len(istr)!=len(list(istr)) or the
expected relation between __eq__ and __hash__.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517509&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1522016 ] filter() doesn't use __len__ of str/unicode/tuple subclasses
Bugs item #1522016, was opened at 2006-07-13 14:25
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522016&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: Rejected
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: filter() doesn't use __len__ of str/unicode/tuple subclasses
Initial Comment:
Consider the following code:
>>> class badstr(str):
... def __len__(self):
... return 6
... def __getitem__(self, index):
... return "a"
...
>>> filter(None, badstr("bbb"))
'aaa'
I would have expected the answer to be 'aa'.
The cause for this is that
Python/bltinmodule.c:filter{string,unicode,tuple} all
call PyString_Size (or the appropriate equivalent),
even if the sequence is a subclass of one of these
types. This bypasses any overloading of __len__ done by
the subclass, as demonstrated above.
If filter() is going to respect the subclass's
__getitem__ overload, it should also respect
overloading of __len__. The attached patch corrects this.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-07-13 17:43
Message:
Logged In: YES
user_id=80475
This isn't a bug. You're making assumptions about
undocumented implementation details. The is no shortage of
cases where the C code makes optimized direct internal calls
that bypass method overrides on subclasses of builtin types.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522016&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1522237 ] _threading_local.py logic error in _localbase __new__
Bugs item #1522237, was opened at 2006-07-13 20:52 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=1522237&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tony Nelson (tony_nelson) Assigned to: Nobody/Anonymous (nobody) Summary: _threading_local.py logic error in _localbase __new__ Initial Comment: I don't understand _threading_local.py, but I think that parens are needed below in class _localbase __new__(). if args or kw and (cls.__init__ is object.__init__): raise TypeError... should be "(args or kw)", I think, looking at the related test in _patch(). I'm not quite sure if this is python 2.5, but it is in trunk. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522237&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1223937 ] subprocess.py abuse of errno
Bugs item #1223937, was opened at 2005-06-20 16:56 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Oren Tirosh (orenti) Assigned to: Peter à strand (astrand) Summary: subprocess.py abuse of errno Initial Comment: The CalledProcessError exception's .errno attribute is set to a child process return code which is not an errno. Any attempt to look up this number with os.strerror() or errno.errorcode[] will result in meaningless output. This can break existing code that catches OSError and does not expect CalledProcessError. Possible resolutions: 1. Don't make CalledProcessError a subclass of OSError 2. If CalledProcessError stays a subclass of OSError .errno should be set to some specific meaningful value (which one? add new value to errnomodule.c?) and use a separate attribute for the child process return code. -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-07-14 13:48 Message: Logged In: YES user_id=29957 Sounds fine. Please make sure to add a NEWS entry! -- Comment By: Michael Hoffman (hoffmanm) Date: 2006-07-11 18:16 Message: Logged In: YES user_id=987664 +1 from me. Thanks. -- Comment By: Peter à strand (astrand) Date: 2006-07-11 08:53 Message: Logged In: YES user_id=344921 If we fix this before Python 2.5, I guess we don't need to think about backwards compatibility. See the attached patch for a suggested solution. -- Comment By: Peter à strand (astrand) Date: 2006-07-11 06:34 Message: Logged In: YES user_id=344921 Bug 1376309 has been marked as a duplicate of this bug. -- Comment By: Peter à strand (astrand) Date: 2005-06-22 06:13 Message: Logged In: YES user_id=344921 I've changed my mind, since CalledProcessError is only in the development version of Python. Perhaps it's acceptable to change the API after all, then. Re-opening. -- Comment By: Peter à strand (astrand) Date: 2005-06-22 01:52 Message: Logged In: YES user_id=344921 In hindsight, CalledProcessError should perhaps have been designed some other way. But now when we have it, it's not easy to change it. It all comes down to what is the documented behaviour and not. As far as I understand, there's no requirement that the errno number or an OSError should be possible to look up with os.strerror(). I cannot find anything about this at http://docs.python.org/lib/module-exceptions.html, at least. All it says is "[errno is] assumed to be an error number". In my opinion, code should be prepared for "unknown" error numbers. So currently, I'm not prepared to make any changes to CalledProcessError. (If you disagree with me, post to python-dev and see what others think.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1508010 ] msvccompiler.py using VC6 with Python 2.5a2
Bugs item #1508010, was opened at 2006-06-18 09:11
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508010&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.5
>Status: Closed
Resolution: Accepted
Priority: 7
Submitted By: Jimmy Retzlaff (jretz)
Assigned to: Martin v. Löwis (loewis)
Summary: msvccompiler.py using VC6 with Python 2.5a2
Initial Comment:
The change in revision 42515 checks if MSSdk is
defined, and if so it will "Assume that the SDK set up
everything alright." The problem is that the SDK may be
set up for a different version of cl.exe than is
expected. In my case I have VC6 and VC7.1 installed and
the SDK is set up for VC6. When building extensions for
Python 2.5a2, distutils tries to use VC6 in my case.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-07-14 06:56
Message:
Logged In: YES
user_id=21627
Committed as r50509
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-09 19:20
Message:
Logged In: YES
user_id=33168
Martin, this looks fine if you think it's important. Don't
forget to add a Misc/NEWS entry.
There are some typos in the doc:
chose -> choose
"most be both set" -> "must both be set"
Should the last distutils in the doc be: \module{distutils}?
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-07-09 11:41
Message:
Logged In: YES
user_id=21627
Here is a proposed patch: in addition to requiring MSSdk to
be set, distutils would also require DISTUTILS_USE_SDK to be
set.
Neal, can you please approve this new feature before beta 2?
--
Comment By: Jimmy Retzlaff (jretz)
Date: 2006-06-25 01:01
Message:
Logged In: YES
user_id=101588
There is an option when installing VC (or at least there
used to be, I haven't checked lately) to set the environment
variables to take effect system wide. This is useful in that
the build environment is always available at any command
line (and they are also set when I build from my editor
which is not VS). I've left mine pointed at VC6 as I
typically do standalone DLLs using VC6 so they are easier to
redistribute. Distutils has always selected the right
version so it hasn't been an issue for me when working on
Python things before.
The issue wouldn't be as difficult if the resulting behavior
were more obvious. Unfortunately the initial errors in my
case were syntax errors arising from macro definitions that
changed between VC6 and VC7.1. Most of the time I spent
updating py2exe to work with 2.5 was spent on diagnosing
this. It wasnât helped by the fact that I had a blind spot
regarding the compiler version. I use a batch file to build
py2exe for 2.3, then 2.4, and finally 2.5. Since 2.3 and 2.4
were building fine I didnât even consider the idea of the
wrong compiler version being used for quite a while.
For now I just do "set MSSDK=" before building and then
everything works just fine.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-06-24 12:30
Message:
Logged In: YES
user_id=21627
I don't understand the problem. MSSdk gets defined by
opening a specific SDK build environment. Just don't open
that build environment, but open a regular cmd.exe window,
and it should work fine.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508010&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521726 ] isinstance failure in 2.5 Beta 2
Bugs item #1521726, was opened at 2006-07-13 12:56
Message generated for change (Settings changed) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521726&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
Submitted By: Nick Maclaren (nmm)
Assigned to: Nobody/Anonymous (nobody)
>Summary: isinstance failure in 2.5 Beta 2
Initial Comment:
Linux gosset 2.6.16.13-4-smp #1 SMP Wed May 3 04:53:23
UTC 2006 x86_64 x86_64 x86_64 GNU/Linux
./python Lib/test/test_compile.py
File "Lib/test/test_compile.py", line 6, in
class TestSpecifics(unittest.TestCase):
File "Lib/test/test_compile.py", line 399, in test_main
test_support.run_unittest(TestSpecifics)
File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
422, in run_unittest
run_suite(suite, testclass)
File
"/home/nmm/Python-2.5b2/Lib/test/test_support.py", line
407, in run_suiteraise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
File "Lib/test/test_compile.py", line 226, in
test_unary_minus
self.assertTrue(isinstance(eval("%s" % (-sys.maxint
- 1)), int))
./python
Python 2.5b2 (r25b2:50512, Jul 13 2006, 11:33:15)
>>> import sys
>>> print sys.maxint
9223372036854775807
>>> print "%s" % (-sys.maxint - 1)
-9223372036854775808
>>> print isinstance(eval("%s" % (-sys.maxint - 1)), int)
False
>>> print isinstance(eval("%s" % (-sys.maxint)), int)
True
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521726&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
