[ python-Bugs-1520327 ] __missing__ does not get called
Bugs item #1520327, was opened at 2006-07-11 03:40
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520327&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
Submitted By: Milind (t-milich)
Assigned to: Nobody/Anonymous (nobody)
Summary: __missing__ does not get called
Initial Comment:
On the last step a[10] we expect 100
>>> class A(dict):
... pass
...
>>> a = A({1:2})
>>> def foo(a,b): return 100
...
>>> a.__missing__ = foo
>>> a[1]
2
>>> a.__missing__(10,20)
100
>>> a[10]
Traceback (most recent call last):
File "", line 1, in
KeyError: 10
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-11 07:01
Message:
Logged In: YES
user_id=849994
Methods are looked up on the type, not the instance. Add
your __missing__ method to A to make it work.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520327&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 06:56 Message generated for change (Comment added) made by hoffmanm 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: Michael Hoffman (hoffmanm) Date: 2006-07-11 08:16 Message: Logged In: YES user_id=987664 +1 from me. Thanks. -- Comment By: Peter à strand (astrand) Date: 2006-07-10 22: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-10 20: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-21 20:13 Message: Logged In: YES user_id=344921 I've changed my mind, since CalledProcessError is only in the development version of Python. Perhaps it's acceptable to change the API after all, then. Re-opening. -- Comment By: Peter à strand (astrand) Date: 2005-06-21 15: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-1472251 ] pdb 'run' crashes when the it's first argument is non-string
Bugs item #1472251, was opened at 2006-04-18 12:16
Message generated for change (Comment added) made by jakamkon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&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: 3
Submitted By: Kuba KoÅczyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb 'run' crashes when the it's first argument is non-string
Initial Comment:
Pdb 'run/runeval' commands fails to check the type of
given argument.When argument to 'run/runeval' is
non-string the functions crashes with further
impilications on (correctly)invoking this functions:
Python 2.5a1 (trunk:45527, Apr 18 2006, 11:12:31)
>>> def x(): pass
>>> import pdb
>>> pdb.run(x())
Traceback (most recent call last):
File "", line 1, in
File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
Pdb().run(statement, globals, locals)
File "/home/jkk/python/python-svn/Lib/bdb.py", line
363, in run
cmd = cmd+'\n'
TypeError: unsupported operand type(s) for +:
'NoneType' and 'str'
>>> pdb.run('x()')
> /home/jkk/python/python-svn/Lib/pdb.py(1113)run()
-> Pdb().run(statement, globals, locals)
(Pdb)
# CTRL-D pressed
Traceback (most recent call last):
File "", line 1, in
File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
Pdb().run(statement, globals, locals)
File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
Pdb().run(statement, globals, locals)
File "/home/jkk/python/python-svn/Lib/bdb.py", line
48, in trace_dispatch
return self.dispatch_line(frame)
File "/home/jkk/python/python-svn/Lib/bdb.py", line
67, in dispatch_line
if self.quitting: raise BdbQuit
bdb.BdbQuit
The solution is to simply ensure that the first
argument passed to the 'run/runeval' functions is string.
--
>Comment By: Kuba KoÅczyk (jakamkon)
Date: 2006-07-11 14:02
Message:
Logged In: YES
user_id=1491175
Is your comment directly related to this bug?
Maybe you should create separete bug tracker item to discuss
problem presented in your comment?
--
Comment By: Ilya Sandler (isandler)
Date: 2006-06-25 18:54
Message:
Logged In: YES
user_id=971153
I have looked at what's happening in a bit more detail and
now I agree that the current behaviour seems wrong.
Apparently, when one passes a nonstring to bdb's run(), bdb
sets tracing first and only then throws an exception...
Leaving tracing on seems like a bad thing to do
Would calling settrace() a couple lines later be the
simplest solution then?
so relevant fragment of bdb.py's run() becomes:
if not isinstance(cmd, types.CodeType):
cmd = cmd+'\n'
sys.settrace(self.trace_dispatch)
This should prevent bdb from turning tracing too early.
What do you think?
--
Comment By: Kuba KoÅczyk (jakamkon)
Date: 2006-06-19 13:48
Message:
Logged In: YES
user_id=1491175
You're right,but don't you think that this kind of switching
between namespaces could confuse users?
--
Comment By: Ilya Sandler (isandler)
Date: 2006-05-23 03:36
Message:
Logged In: YES
user_id=971153
Well, I don't see anything in bdb's run which could
overwrite your namespace..
What seems to be happenning in your example is that bdb's
first line event happens while bdb is still in run(), so you
when you see pdb's prompt, are in bdb's namespace not in
yours.. If you do "next" you will get where you should be..
bagira:~> python2.4
Python 2.4.1 (#2, May 5 2005, 11:32:06)
>>> def x(): print "in x"
>>> import pdb
>>> pdb.run( x())
in x
TypeError: unsupported operand type(s) for +: 'NoneType'
and 'str'
>>> pdb.run( 'x()' )
> /usr/lib/python2.4/pdb.py(987)run()
-> Pdb().run(statement, globals, locals)
(Pdb) n #now you are back in your namespace
> (1)?()
(Pdb) p x#and you get your symbols back
(Pdb) p pdb
(Pdb) n
in x
--Return--
> (1)?()->None
What do you think?
--
Comment By: Kuba KoÅczyk (jakamkon)
Date: 2006-05-22 09:20
Message:
Logged In: YES
user_id=1491175
The point is that when you want to invoke pdb.run correctly
(with string argument) after getting TypeError as in above
example,
your namespace is probably overwritten or deleted so that
you don't have access to previously defined symbols.
>>> def x():pass
>>> import pdb
>>> pdb.run(x())
TypeError
>>> pdb.run('x()')
> /home/jkk/python-svn/Lib/pdb.py(1122)run()
-> Pdb().run(statement, globals, locals)
(Pdb) pdb
*** NameError: name 'pdb' is not
[ python-Bugs-1472251 ] pdb 'run' crashes when the it's first argument is non-string
Bugs item #1472251, was opened at 2006-04-18 12:16
Message generated for change (Comment added) made by jakamkon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472251&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: 3
Submitted By: Kuba KoÅczyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb 'run' crashes when the it's first argument is non-string
Initial Comment:
Pdb 'run/runeval' commands fails to check the type of
given argument.When argument to 'run/runeval' is
non-string the functions crashes with further
impilications on (correctly)invoking this functions:
Python 2.5a1 (trunk:45527, Apr 18 2006, 11:12:31)
>>> def x(): pass
>>> import pdb
>>> pdb.run(x())
Traceback (most recent call last):
File "", line 1, in
File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
Pdb().run(statement, globals, locals)
File "/home/jkk/python/python-svn/Lib/bdb.py", line
363, in run
cmd = cmd+'\n'
TypeError: unsupported operand type(s) for +:
'NoneType' and 'str'
>>> pdb.run('x()')
> /home/jkk/python/python-svn/Lib/pdb.py(1113)run()
-> Pdb().run(statement, globals, locals)
(Pdb)
# CTRL-D pressed
Traceback (most recent call last):
File "", line 1, in
File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
Pdb().run(statement, globals, locals)
File "/home/jkk/python/python-svn/Lib/pdb.py", line
1113, in run
Pdb().run(statement, globals, locals)
File "/home/jkk/python/python-svn/Lib/bdb.py", line
48, in trace_dispatch
return self.dispatch_line(frame)
File "/home/jkk/python/python-svn/Lib/bdb.py", line
67, in dispatch_line
if self.quitting: raise BdbQuit
bdb.BdbQuit
The solution is to simply ensure that the first
argument passed to the 'run/runeval' functions is string.
--
>Comment By: Kuba KoÅczyk (jakamkon)
Date: 2006-07-11 15:02
Message:
Logged In: YES
user_id=1491175
Simple solution is to catch TypeError in bdb's run function:
try:
if not isinstance(cmd, types.CodeType):
cmd = cmd+'\n'
except TypeError:
pass
Now it seems that handling nonstring arguments is better:
>>> import pdb
>>> def x():pass
...
>>> pdb.run(x())
Traceback (most recent call last):
File "", line 1, in
File "/home/jkk/python-svn/Lib/pdb.py", line 1122, in run
Pdb().run(statement, globals, locals)
File "/home/jkk/python-svn/Lib/bdb.py", line 369, in run
exec cmd in globals, locals
TypeError: exec: arg 1 must be a string, file, or code object
>>> pdb.run('x()')
> (1)()
(Pdb) x
(Pdb) pdb.run('x()')
(Pdb)
>>>
--
Comment By: Kuba KoÅczyk (jakamkon)
Date: 2006-07-11 14:02
Message:
Logged In: YES
user_id=1491175
Is your comment directly related to this bug?
Maybe you should create separete bug tracker item to discuss
problem presented in your comment?
--
Comment By: Ilya Sandler (isandler)
Date: 2006-06-25 18:54
Message:
Logged In: YES
user_id=971153
I have looked at what's happening in a bit more detail and
now I agree that the current behaviour seems wrong.
Apparently, when one passes a nonstring to bdb's run(), bdb
sets tracing first and only then throws an exception...
Leaving tracing on seems like a bad thing to do
Would calling settrace() a couple lines later be the
simplest solution then?
so relevant fragment of bdb.py's run() becomes:
if not isinstance(cmd, types.CodeType):
cmd = cmd+'\n'
sys.settrace(self.trace_dispatch)
This should prevent bdb from turning tracing too early.
What do you think?
--
Comment By: Kuba KoÅczyk (jakamkon)
Date: 2006-06-19 13:48
Message:
Logged In: YES
user_id=1491175
You're right,but don't you think that this kind of switching
between namespaces could confuse users?
--
Comment By: Ilya Sandler (isandler)
Date: 2006-05-23 03:36
Message:
Logged In: YES
user_id=971153
Well, I don't see anything in bdb's run which could
overwrite your namespace..
What seems to be happenning in your example is that bdb's
first line event happens while bdb is still in run(), so you
when you see pdb's prompt, are in bdb's namespace not in
yours.. If you do "next" you will get where you should be..
bagira:~> python2.4
Python 2.4.1 (#2, May 5 2005, 11:32:06)
>>> def x(): print "in x"
>>> import pdb
>>> pdb.run( x())
in x
TypeError: unsupported operand type(s) for +: 'NoneType'
and 'str'
>>> pdb.run( 'x()' )
> /usr/lib/
[ python-Feature Requests-1520662 ] support all of strftime(3)
Feature Requests item #1520662, was opened at 2006-07-11 18:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1520662&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Toni Mueller (tonimueller) Assigned to: Nobody/Anonymous (nobody) Summary: support all of strftime(3) Initial Comment: Hello, I'd like to see support for all of strftime(3) in time.strftime() and time.strptime(). Thank you! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1520662&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Bugs item #1494314, was opened at 2006-05-24 23:51 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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.4 >Status: Open >Resolution: Remind Priority: 5 Submitted By: Michael Smith (mlrsmith) Assigned to: Anthony Baxter (anthonybaxter) Summary: Cannot use high-numbered sockets in 2.4.3 Initial Comment: Python 2.4.3 introduced (in Modules/socketmodule.c) the IS_SELECTABLE() macro, to check whether calling select() on a given file descriptor is permissible. However, it executes this check even when it won't actually call select(). Specifically, select() is called ONLY when s->sock_timeout > 0 (in internal_select mostly, but also internal_connect). I have a twisted application which uses many FDs (several thousand), and upgrading python to 2.4.3 makes it hit this limit (at 1024 file descriptors), regardless of ulimit settings. Twisted itself always uses non-blocking I/O on sockets, so with older versions of python this worked fine. A simple solution relies on the fact that select is only ever actually called, and changes the IS_SELECTABLE macro as in the attached fairly trivial patch. This is sufficient to restore my application to its previous state (where it works fine). This doesn't solve the more general problem in socketmodule - that we simply can't do all operations properly with the current reliance on select(), though, and it seems like a bit of a hack... If I wrote up a patch to use poll() on systems where it's available, throughout socketmodule.c, in preference to select(), would this be accepted? Mike -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-07-12 03:21 Message: Logged In: YES user_id=29957 Re-opening to remind myself to apply this to release24-maint for the eventual 2.4.4 release. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-07-11 13:52 Message: Logged In: YES user_id=29957 Applied. Patch will be in 2.5b2 (to be released shortly). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-11 12:53 Message: Logged In: YES user_id=33168 Anthony checked this in to 2.5 as 50567. I will backport at least part of it later. -- Comment By: Martin v. Löwis (loewis) Date: 2006-07-10 15:47 Message: Logged In: YES user_id=21627 The patch is fine, please apply. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 09:57 Message: Logged In: YES user_id=33168 I meant I don't think we *care* in this case (not can). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 09:55 Message: Logged In: YES user_id=33168 I think you're right Martin. Looking at what it means to have a broken poll, I don't think we can in this instance. So I removed all refs to HAVE_BROKEN_POLL. What do you think of the new version? -- Comment By: Martin v. Löwis (loewis) Date: 2006-07-08 01:50 Message: Logged In: YES user_id=21627 The __APPLE__ stuff looks wrong in file 184131. You would have to use selectmodule.c:select_have_broken_poll at run-time to be sure you can use poll(2) on OS X (you can use it on 10.4, but can't on 10.3, IIRC). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-07 16:10 Message: Logged In: YES user_id=33168 I've added a more complete patch (against 2.5, hopefully applies to 2.4 too). It cleans up some things and adds support for SSL sockets too. Can people please review/test this? I manually tested this with regular sockets and it seemed to work. All the tests pass, but this is somewhat tricky. I hate the duplicated code between socket and ssl modules, but added to it. It would be great to clean this up for 2.6. If you are forced to use select with a high socket, the exception on connect is operation in progress rather than can't select on socket. I guess that's ok, it doesn't actually change the existing behaviour. That would have been more involved and I'm not sure it's worth it. -- Comment By: Michael Smith (mlrsmith) Date: 2006-06-09 20:31 Message: Logged In: YES user_id=1488997 Ok, I'll attach a patch that uses poll when available (HAVE_POLL is already being set by the configure s
[ python-Bugs-1467450 ] test_ctypes fails on OSX 10.3
Bugs item #1467450, was opened at 2006-04-10 03:21
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&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: Anthony Baxter (anthonybaxter)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on OSX 10.3
Initial Comment:
test test_ctypes failed -- Traceback (most recent call
last):
File
"/Users/anthonybaxter/python/Lib/ctypes/test/test_loading.py",
line 30, in test_load
cdll.load(libc_name)
File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 112, in load
return self._load(libname, mode)
File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 153, in _load
return self.load_library(pathname, mode)
File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 124, in load_library
return self._dlltype(libname, mode)
File
"/Users/anthonybaxter/python/Lib/ctypes/__init__.py",
line 288, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlcompat: unable to open this file with RTLD_LOCAL
This happens both with and without the patch in r43748.
Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed
Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power
Macintosh powerpc
GCC version:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)
--
>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-11 19:45
Message:
Logged In: YES
user_id=580910
With this patch test_ctypes passed on 10.3.
I'm in favor of applying this patch.
--
Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-10 11:43
Message:
Logged In: YES
user_id=29957
I'm not going to get the opportunity to look at this before
the b2 freeze tomorrow morning, but will look at it soon after.
--
Comment By: Thomas Heller (theller)
Date: 2006-07-10 11:07
Message:
Logged In: YES
user_id=11105
Even better would imo be to call the Gestalt function in the
_ctypes extensions module itself.
--
Comment By: Thomas Heller (theller)
Date: 2006-07-10 10:13
Message:
Logged In: YES
user_id=11105
Here is a patch that I hope will fix this problem. Ronald
Oussuren suggested in private email to use RTLD_GLOBAL as
default library loading mode on OS X 10.3. He suggested to
use the platform module to find out the osx version, however
I don't like. Instead I found by examining platform that
gestalt.gestalt("sysv") returns the information I need.
I still don't have access to 10.3 (and Python does not
compile on the 10.2.8 sourceforge osx compile farm machine -
should I add a bug for that one?), so I cannot really test
the patch myself.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 06:14
Message:
Logged In: YES
user_id=33168
Anthony is this still a problem?
--
Comment By: Thomas Heller (theller)
Date: 2006-05-09 20:38
Message:
Logged In: YES
user_id=11105
Does this failure still occur with Python 2.5a2, or the
current SVN trunk?
--
Comment By: Thomas Heller (theller)
Date: 2006-04-13 08:59
Message:
Logged In: YES
user_id=11105
I'm trying to get a copy of OS X 10.3, then will try to
install it and look after this problem.
OTOH, the ctypes loading code is currently rewritten in the
upstream version - this will probably prevent this failure.
In the meantime, can you try to find out the cause of this
failure? Would RTLD_GLOBAL instead of RTLD_LOCAL work? Is
the library file missing?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&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-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 01:57 Message generated for change (Comment added) made by shmengie 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: Joe Brown (shmengie) Date: 2006-07-11 16: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 13: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 02: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-1520818 ] fcntl.ioctl fails to copy back exactly-1024 buffer
Bugs item #1520818, was opened at 2006-07-11 17:38 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=1520818&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: None Priority: 5 Submitted By: Mark Eichin (eichin) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl.ioctl fails to copy back exactly-1024 buffer Initial Comment: The appended code is a simple call of the SCSI Inquiry ioctl, based on what scsi-tools scsiinfo.c does. The intended behaviour is simple - pass it /dev/sg0 (or any scsi device, really) and it pulls out the vendor, product and revision from the returned buffer. However, if you change PAD_SIZE, the behaviour changes: at 1023 and 1025, it does what is expected; at 1024, the second assertion fires, because the array b on output hasn't changed at all. Not sure if there's a different ioctl that can demonstrate this more easily (this needs root and a scsi device, though it does explicitly open it readonly) but it points in the direction of a fencepost error in the "if the supplied buffer is less than 1024 bytes long it is first copied into a static buffer 1024 bytes long which is then passed to ioctl and copied back into the supplied buffer" behaviour in current documentation. observed under: Python 2.4.1 (#2, May 5 2005, 11:32:06) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 (on debian sarge.) I didn't see it mentioned among the ioctl bugs in the sourceforge tracker... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520818&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1520831 ] urrlib2 max_redirections=0 disables redirects
Bugs item #1520831, was opened at 2006-07-11 15:16 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=1520831&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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: rus_r_orange (rus_r_orange) Assigned to: Nobody/Anonymous (nobody) Summary: urrlib2 max_redirections=0 disables redirects Initial Comment: When using urllib2, I wanted to be able to see all redirects that come back from an http server. I set the variable max_redirections in HTTPRedirectHandler to 0. However, redirects were still being followed because the req didn't have a redirect_dict set. IMHO, if max_redirections is set to 0, redirects should not be followed, no matter what. For my personal situation, I copied urllib2 and hacked it to that if max_redirections is 0 (or less), it will always raise the HTTPError that is associated with the status code received by the request. I saw this issue on WinXP with 2.4.1 and on Linux with 2.4.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520831&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1520864 ] unpack list of singleton tuples not unpacking
Bugs item #1520864, was opened at 2006-07-11 17:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&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: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: unpack list of singleton tuples not unpacking Initial Comment: The following code works differently in Python 2.5 than Python 2.4: x = [(1,), (2,), (3,)] for y, in x: print y In Python 2.4, this code produces the following: 1 2 3 In Python 2.5, this code produces the following: (1,) (2,) (3,) Interestingly enough the following code: x = (1,) y, = x print y produces the output 1 in both Python 2.4 and Python 2.5. I'm thinking this is not intentional. :-) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1520914 ] time.strftime breakage in 2.4/2.5
Bugs item #1520914, was opened at 2006-07-11 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=1520914&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: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime breakage in 2.4/2.5
Initial Comment:
Up to Python 2.3 this worked just fine:
>>> import time
>>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)
'2005-06-04'
Starting with 2.4 it broke:
>>> import time
>>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)
Traceback (most recent call last):
File "", line 1, in ?
ValueError: day of year out of range
though if you change the unused fields to 1 it works:
>>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (1,)*6)
'2005-06-04'
While this wasn't documented behavior, it was certainly behaviour that
worked for a long time. It should probably be allowed to continue
working.
Skip
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520914&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 01:57
Message generated for change (Comment added) made by shmengie
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: Joe Brown (shmengie)
Date: 2006-07-11 22: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 16: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 13: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 02: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-1520914 ] time.strftime breakage in 2.4/2.5
Bugs item #1520914, was opened at 2006-07-11 18:52
Message generated for change (Settings changed) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520914&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: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Brett Cannon (bcannon)
Summary: time.strftime breakage in 2.4/2.5
Initial Comment:
Up to Python 2.3 this worked just fine:
>>> import time
>>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)
'2005-06-04'
Starting with 2.4 it broke:
>>> import time
>>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)
Traceback (most recent call last):
File "", line 1, in ?
ValueError: day of year out of range
though if you change the unused fields to 1 it works:
>>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (1,)*6)
'2005-06-04'
While this wasn't documented behavior, it was certainly behaviour that
worked for a long time. It should probably be allowed to continue
working.
Skip
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520914&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1520864 ] unpack list of singleton tuples not unpacking
Bugs item #1520864, was opened at 2006-07-11 18:21 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&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: 9 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: unpack list of singleton tuples not unpacking Initial Comment: The following code works differently in Python 2.5 than Python 2.4: x = [(1,), (2,), (3,)] for y, in x: print y In Python 2.4, this code produces the following: 1 2 3 In Python 2.5, this code produces the following: (1,) (2,) (3,) Interestingly enough the following code: x = (1,) y, = x print y produces the output 1 in both Python 2.4 and Python 2.5. I'm thinking this is not intentional. :-) -- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-11 21:38 Message: Logged In: YES user_id=80475 Ouch. This is bad. The disassembly shows that the compiler isn't generating the unpack_sequence opcode. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1520864 ] unpack list of singleton tuples not unpacking
Bugs item #1520864, was opened at 2006-07-11 16:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&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: Fixed Priority: 9 Submitted By: Anthony Tuininga (atuining) >Assigned to: Neal Norwitz (nnorwitz) Summary: unpack list of singleton tuples not unpacking Initial Comment: The following code works differently in Python 2.5 than Python 2.4: x = [(1,), (2,), (3,)] for y, in x: print y In Python 2.4, this code produces the following: 1 2 3 In Python 2.5, this code produces the following: (1,) (2,) (3,) Interestingly enough the following code: x = (1,) y, = x print y produces the output 1 in both Python 2.4 and Python 2.5. I'm thinking this is not intentional. :-) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-11 22:26 Message: Logged In: YES user_id=33168 Awww come on, can't we change the language just to make your life difficult? ;-) Thanks a lot for catching this! Committed revision 50597. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-11 19:38 Message: Logged In: YES user_id=80475 Ouch. This is bad. The disassembly shows that the compiler isn't generating the unpack_sequence opcode. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520864&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1520818 ] fcntl.ioctl fails to copy back exactly-1024 buffer
Bugs item #1520818, was opened at 2006-07-11 14:38 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520818&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: None Priority: 5 Submitted By: Mark Eichin (eichin) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl.ioctl fails to copy back exactly-1024 buffer Initial Comment: The appended code is a simple call of the SCSI Inquiry ioctl, based on what scsi-tools scsiinfo.c does. The intended behaviour is simple - pass it /dev/sg0 (or any scsi device, really) and it pulls out the vendor, product and revision from the returned buffer. However, if you change PAD_SIZE, the behaviour changes: at 1023 and 1025, it does what is expected; at 1024, the second assertion fires, because the array b on output hasn't changed at all. Not sure if there's a different ioctl that can demonstrate this more easily (this needs root and a scsi device, though it does explicitly open it readonly) but it points in the direction of a fencepost error in the "if the supplied buffer is less than 1024 bytes long it is first copied into a static buffer 1024 bytes long which is then passed to ioctl and copied back into the supplied buffer" behaviour in current documentation. observed under: Python 2.4.1 (#2, May 5 2005, 11:32:06) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 (on debian sarge.) I didn't see it mentioned among the ioctl bugs in the sourceforge tracker... -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-11 22:33 Message: Logged In: YES user_id=33168 This code was recently changed. It is not in any released version AFAIK. Can you try 2.5b2 which recently came out? If not, can you try 2.4.3+ from SVN? This is the version that will become 2.4.4. I think the problem may be fixed. The patch was for http://python.org/sf/1433877 . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520818&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
