[ python-Bugs-1282539 ] logging.shutdown() not correct for chained handlers
Bugs item #1282539, was opened at 2005-09-05 21:12
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1282539&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: Accepted
Priority: 5
Submitted By: Fons Dijkstra (fdij)
Assigned to: Vinay Sajip (vsajip)
Summary: logging.shutdown() not correct for chained handlers
Initial Comment:
Consider the following code:
import logging
import logging.handlers
if __name__ == "__main__":
fh = logging.handlers.RotatingFileHandler("log.txt")
mh = logging.handlers.MemoryHandler(1024,
logging.ERROR, fh)
logging.getLogger().addHandler(mh)
logging.getLogger().warning("next statement crashes")
logging.shutdown()
which results in a crash due to operating on a closed
file. The reason is that the shutdown flushes and closes
all handlers in undefined order. In above case, first
the 'fh' handlers is flushes and closed then the 'mh'
handler.
The solution is to first flush all handlers times the
number of handlers before closing them. Thus (omitting
error handling):
def shutdown():
for i in range(len(_handlers)):
for h in _handlers.keys():
h.flush()
for h in _handlers.keys():
h.close()
--
>Comment By: Vinay Sajip (vsajip)
Date: 2005-09-07 11:12
Message:
Logged In: YES
user_id=308438
There is indeed a problem - thanks for the report. Rather
than your proposed solution, I would rather add another
internal list, _handlerList, which holds the handlers in
*reverse* order of creation. When shutting down, (a copy of)
this list is used for the iteration rather than
_handlers.keys().
I may remove _handlers in the future - I can't remember why
I made it a dict rather than a list.
Will check into CVS soon, then mark this as Fixed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1282539&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1283895 ] os.path.abspath() / os.chdir() buggy with unicode paths
Bugs item #1283895, was opened at 2005-09-07 14:30 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=1283895&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: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.abspath() / os.chdir() buggy with unicode paths Initial Comment: Hi, Under Windows Explorer, one can create directory names using characters not belonging to the user locale. For example, one of our users created a directory named "C:\Mes Documents\コピー ～ solipsis_svn". Unfortunately, when trying to manipulate such a pathname, os.path.abspath() and os.chdir() don't work hand in hand. os.path.abspath() uses the garbled directory name as displayed by the command prompt and then os.chdir() refuses the path: C:\>cd "C:\Mes Documents\??? ~ solipsis_svn" C:\Mes Documents\??? ~ solipsis_svn>python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> >>> import os >>> os.curdir '.' >>> os.path.abspath(os.curdir) 'C:\Mes Documents\??? ~ solipsis_svn' >>> os.chdir(os.path.abspath(os.curdir)) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: 'C:\Mes Documents\??? ~ solipsis_svn' >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283895&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1283895 ] os.path.abspath() / os.chdir() buggy with unicode paths
Bugs item #1283895, was opened at 2005-09-07 14:30 Message generated for change (Comment added) made by pitrou You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283895&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: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Antoine Pitrou (pitrou) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.abspath() / os.chdir() buggy with unicode paths Initial Comment: Hi, Under Windows Explorer, one can create directory names using characters not belonging to the user locale. For example, one of our users created a directory named "C:\Mes Documents\コピー ～ solipsis_svn". Unfortunately, when trying to manipulate such a pathname, os.path.abspath() and os.chdir() don't work hand in hand. os.path.abspath() uses the garbled directory name as displayed by the command prompt and then os.chdir() refuses the path: C:\>cd "C:\Mes Documents\??? ~ solipsis_svn" C:\Mes Documents\??? ~ solipsis_svn>python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> >>> import os >>> os.curdir '.' >>> os.path.abspath(os.curdir) 'C:\Mes Documents\??? ~ solipsis_svn' >>> os.chdir(os.path.abspath(os.curdir)) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: 'C:\Mes Documents\??? ~ solipsis_svn' >>> -- >Comment By: Antoine Pitrou (pitrou) Date: 2005-09-07 14:36 Message: Logged In: YES user_id=133955 > "C:\Mes Documents\コピー ～ solipsis_svn" Gasp. Sourceforge escapes HTML entities instead of showing the real characters... These are Japanese characters, btw. It's easy to copy/paste some Japanese characters from a Web site and paste them into Windows Explorer to create a directory (at least it works with Mozilla Firefox). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283895&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1283491 ] nit for builtin sum doc
Bugs item #1283491, was opened at 2005-09-07 00:18 Message generated for change (Comment added) made by daishiharada You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&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: 4 Submitted By: daishi harada (daishiharada) Assigned to: Nobody/Anonymous (nobody) Summary: nit for builtin sum doc Initial Comment: the docstring signature for sum in bltinmodule.c should be changed from: sum(sequence, start=0) to: sum(sequence[, start]) to reflect the current implementation in builtin_sum. (or else the implementation should be changed to accept kwargs.) -- >Comment By: daishi harada (daishiharada) Date: 2005-09-07 19:02 Message: Logged In: YES user_id=493197 This is relatively minor so I don't mean to push particularly hard, but I'd like to at least show how the docstring made me stray: >>> sum([x] for x in xrange(10)) Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'list' >>> help(sum) Help on built-in function sum in module __builtin__: sum(...) sum(sequence, start=0) -> value Returns the sum of a sequence of numbers (NOT strings) plus the value of parameter 'start'. When the sequence is empty, returns start. >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? >>> sum(([x] for x in xrange(10)), start=[]) Traceback (most recent call last): File "", line 1, in ? TypeError: sum() takes no keyword arguments # examine lib docs, which give the signature: # sum(sequence[, start]) >>> sum(([x] for x in xrange(10)), []) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> # examine bltinmodule.c to confirm that # sum doesn't accept kwargs. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-07 03:11 Message: Logged In: YES user_id=80475 While the proposed change is technically correct, I find the original to be more informative. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1283491 ] nit for builtin sum doc
Bugs item #1283491, was opened at 2005-09-07 00:18 Message generated for change (Comment added) made by daishiharada You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&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: 4 Submitted By: daishi harada (daishiharada) Assigned to: Nobody/Anonymous (nobody) Summary: nit for builtin sum doc Initial Comment: the docstring signature for sum in bltinmodule.c should be changed from: sum(sequence, start=0) to: sum(sequence[, start]) to reflect the current implementation in builtin_sum. (or else the implementation should be changed to accept kwargs.) -- >Comment By: daishi harada (daishiharada) Date: 2005-09-07 19:02 Message: Logged In: YES user_id=493197 This is relatively minor so I don't mean to push particularly hard, but I'd like to at least show how the docstring made me stray: >>> sum([x] for x in xrange(10)) Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'list' >>> help(sum) Help on built-in function sum in module __builtin__: sum(...) sum(sequence, start=0) -> value Returns the sum of a sequence of numbers (NOT strings) plus the value of parameter 'start'. When the sequence is empty, returns start. >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? >>> sum(([x] for x in xrange(10)), start=[]) Traceback (most recent call last): File "", line 1, in ? TypeError: sum() takes no keyword arguments # examine lib docs, which give the signature: # sum(sequence[, start]) >>> sum(([x] for x in xrange(10)), []) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> # examine bltinmodule.c to confirm that # sum doesn't accept kwargs. -- Comment By: daishi harada (daishiharada) Date: 2005-09-07 19:02 Message: Logged In: YES user_id=493197 This is relatively minor so I don't mean to push particularly hard, but I'd like to at least show how the docstring made me stray: >>> sum([x] for x in xrange(10)) Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'list' >>> help(sum) Help on built-in function sum in module __builtin__: sum(...) sum(sequence, start=0) -> value Returns the sum of a sequence of numbers (NOT strings) plus the value of parameter 'start'. When the sequence is empty, returns start. >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? >>> sum(([x] for x in xrange(10)), start=[]) Traceback (most recent call last): File "", line 1, in ? TypeError: sum() takes no keyword arguments # examine lib docs, which give the signature: # sum(sequence[, start]) >>> sum(([x] for x in xrange(10)), []) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> # examine bltinmodule.c to confirm that # sum doesn't accept kwargs. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-07 03:11 Message: Logged In: YES user_id=80475 While the proposed change is technically correct, I find the original to be more informative. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1066546 ] test_pwd fails on 64bit system (Opteron)
Bugs item #1066546, was opened at 2004-11-15 01:34
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&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: Miki Tebeka (tebeka)
Assigned to: Martin v. Löwis (loewis)
Summary: test_pwd fails on 64bit system (Opteron)
Initial Comment:
test test_pwd failed -- Traceback (most recent call last):
File "/tmp/miki/Python-2.4b2/Lib/test/test_pwd.py",
line 42, in test_values
self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum
$ cat /proc/version
Linux version 2.4.21-20.ELsmp
([EMAIL PROTECTED]) (gcc version 3.2.3
20030502 (Red Hat Linux 3.2.3-42)) #1 SMP Wed Aug 18
20:34:58 EDT 2004
Processor is AMD Opteron 2.4MHz
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-07 14:16
Message:
Logged In: YES
user_id=33168
See this patch which looks like it may fix the same problem
(among others).
https://sourceforge.net/tracker/index.php?func=detail&aid=1284289&group_id=5470&atid=305470
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-03 11:17
Message:
Logged In: YES
user_id=1188172
Is the patch safe to apply? I think so, I haven't seen a
negative uid/gid yet.
--
Comment By: Clark Mobarry (cmobarry)
Date: 2005-09-01 05:57
Message:
Logged In: YES
user_id=1035073
The suggested patch by heffler worked brilliantly for my 64
bit environment. Thanks. My bug submission was on
2005-08-03 14:40.
--
Comment By: Marvin Heffler (heffler)
Date: 2005-08-11 11:19
Message:
Logged In: YES
user_id=298758
I think I figued out the problem with python handling uids and
gids greater than 2147483647 when using the grp.getgrgid
and pwd.getpwuid functions. Both of the functions call
PyArg_ParseTuple with a type of "i", thus indicating the
argument is a signed integer. Instead they should be
using "I" (upper-case i) for an unsigned integer. The fix is
fairly simple. Here are the two patches necessary to the
python source:
diff -Naur Python-2.4.orig/Modules/grpmodule.c Python-
2.4/Modules/grpmodule.c
--- Python-2.4.orig/Modules/grpmodule.c 2004-01-20
16:06:00.0 -0500
+++ Python-2.4/Modules/grpmodule.c 2005-08-11
13:36:48.0 -0400
@@ -87,7 +87,7 @@
{
int gid;
struct group *p;
-if (!PyArg_ParseTuple(args, "i:getgrgid", &gid))
+if (!PyArg_ParseTuple(args, "I:getgrgid", &gid))
return NULL;
if ((p = getgrgid(gid)) == NULL) {
PyErr_Format(PyExc_KeyError, "getgrgid(): gid not
found: %d", gid);
diff -Naur Python-2.4.orig/Modules/pwdmodule.c Python-
2.4/Modules/pwdmodule.c
--- Python-2.4.orig/Modules/pwdmodule.c 2004-01-20
16:07:23.0 -0500
+++ Python-2.4/Modules/pwdmodule.c 2005-08-11
13:36:27.0 -0400
@@ -104,7 +104,7 @@
{
int uid;
struct passwd *p;
- if (!PyArg_ParseTuple(args, "i:getpwuid", &uid))
+ if (!PyArg_ParseTuple(args, "I:getpwuid", &uid))
return NULL;
if ((p = getpwuid(uid)) == NULL) {
PyErr_Format(PyExc_KeyError,
Hopefully, someone from the python project can verify my
patch and get it incorporated into a future release.
--
Comment By: Clark Mobarry (cmobarry)
Date: 2005-08-03 11:40
Message:
Logged In: YES
user_id=1035073
The same error occurs for an Intel P4-521 processor running
RedHat Enterprise Linux WS v4 Intel EM64T 64bit.
$ cat /proc/version
Linux version 2.6.9-5.ELsmp ([EMAIL PROTECTED])
(gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)) #1 SMP
Wed Jan 5 19:29:47 EST 2005
test test_grp failed -- Traceback (most recent call last):
File
"/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_grp.py",
line 29, in test_values
e2 = grp.getgrgid(e.gr_gid)
OverflowError: signed integer is greater than maximum
test test_pwd failed -- Traceback (most recent call last):
File
"/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_pwd.py",
line 42, in test_values
self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum
--
Comment By: Miki Tebeka (tebeka)
Date: 2005-03-17 01:20
Message:
Logged In: YES
user_id=358087
I've tried the patch - no luck :-(
I'm stealing time on these machines since they belong to
another group.
H
[ python-Bugs-1284341 ] re nested conditional matching (?()) doesn't work
Bugs item #1284341, was opened at 2005-09-07 18:36
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=1284341&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: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re nested conditional matching (?()) doesn't work
Initial Comment:
Here is a simple regular expression that should match
\o, \{o}, {\o}, and \{o}}: (This example arose as
a simplification of a general accent matcher for
LaTeX/BibTeX.)
r = re.compile(r'(\{)?\"(\{)?(.)(?(2)\})(?(1)\})')
However, it fails on two out of four of the desired
matches:
r.search(r'\o) ## returns None (WRONG)
r.search(r\{o}').group() ## returns '\"{o}"' (CORRECT)
r.search(r'{\o).group() ## returns \"o} (WRONG)
r.search(r{\{o}}').group() ## returns '{\"{o}}'
(CORRECT)
The third case is particularly bizarre. Incidentally,
the behavior is different if '(.)' is replaced by '.'
(incorrect in different ways).
I have tested this on Python 2.4.1 on Windows and a CVS
version on Linux. I do not believe it is a platform issue.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284341&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1284341 ] re nested conditional matching (?()) doesn't work
Bugs item #1284341, was opened at 2005-09-07 18:36
Message generated for change (Comment added) made by edemaine
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284341&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: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re nested conditional matching (?()) doesn't work
Initial Comment:
Here is a simple regular expression that should match
\o, \{o}, {\o}, and \{o}}: (This example arose as
a simplification of a general accent matcher for
LaTeX/BibTeX.)
r = re.compile(r'(\{)?\"(\{)?(.)(?(2)\})(?(1)\})')
However, it fails on two out of four of the desired
matches:
r.search(r'\o) ## returns None (WRONG)
r.search(r\{o}').group() ## returns '\"{o}"' (CORRECT)
r.search(r'{\o).group() ## returns \"o} (WRONG)
r.search(r{\{o}}').group() ## returns '{\"{o}}'
(CORRECT)
The third case is particularly bizarre. Incidentally,
the behavior is different if '(.)' is replaced by '.'
(incorrect in different ways).
I have tested this on Python 2.4.1 on Windows and a CVS
version on Linux. I do not believe it is a platform issue.
--
>Comment By: Erik Demaine (edemaine)
Date: 2005-09-07 19:09
Message:
Logged In: YES
user_id=265183
Whoops, I just updated CVS to the latest HEAD and discovered
that the problem has already been solved. Nice work! Sorry
about the extraneous report, but let me turn this into a
request that the fix go into 2.4.2, not just 2.5.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284341&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1283491 ] nit for builtin sum doc
Bugs item #1283491, was opened at 2005-09-06 19:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&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: 4 Submitted By: daishi harada (daishiharada) Assigned to: Nobody/Anonymous (nobody) Summary: nit for builtin sum doc Initial Comment: the docstring signature for sum in bltinmodule.c should be changed from: sum(sequence, start=0) to: sum(sequence[, start]) to reflect the current implementation in builtin_sum. (or else the implementation should be changed to accept kwargs.) -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-07 21:37 Message: Logged In: YES user_id=80475 """ >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? """ FYI, the answer is no. The requirement for parenthesis cannot change. To see why, parse this: f(g(t) for t in a, b). -- Comment By: daishi harada (daishiharada) Date: 2005-09-07 14:02 Message: Logged In: YES user_id=493197 This is relatively minor so I don't mean to push particularly hard, but I'd like to at least show how the docstring made me stray: >>> sum([x] for x in xrange(10)) Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'list' >>> help(sum) Help on built-in function sum in module __builtin__: sum(...) sum(sequence, start=0) -> value Returns the sum of a sequence of numbers (NOT strings) plus the value of parameter 'start'. When the sequence is empty, returns start. >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? >>> sum(([x] for x in xrange(10)), start=[]) Traceback (most recent call last): File "", line 1, in ? TypeError: sum() takes no keyword arguments # examine lib docs, which give the signature: # sum(sequence[, start]) >>> sum(([x] for x in xrange(10)), []) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> # examine bltinmodule.c to confirm that # sum doesn't accept kwargs. -- Comment By: daishi harada (daishiharada) Date: 2005-09-07 14:02 Message: Logged In: YES user_id=493197 This is relatively minor so I don't mean to push particularly hard, but I'd like to at least show how the docstring made me stray: >>> sum([x] for x in xrange(10)) Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'list' >>> help(sum) Help on built-in function sum in module __builtin__: sum(...) sum(sequence, start=0) -> value Returns the sum of a sequence of numbers (NOT strings) plus the value of parameter 'start'. When the sequence is empty, returns start. >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? >>> sum(([x] for x in xrange(10)), start=[]) Traceback (most recent call last): File "", line 1, in ? TypeError: sum() takes no keyword arguments # examine lib docs, which give the signature: # sum(sequence[, start]) >>> sum(([x] for x in xrange(10)), []) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> # examine bltinmodule.c to confirm that # sum doesn't accept kwargs. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-06 22:11 Message: Logged In: YES user_id=80475 While the proposed change is technically correct, I find the original to be more informative. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1284496 ] traceback module can return undecodable byte strings
Bugs item #1284496, was opened at 2005-09-08 15:26
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=1284496&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: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: traceback module can return undecodable byte strings
Initial Comment:
The traceback module does not attempt to validate the
string representation of exceptions or enforce any
character set restrictions. It implements garbage in,
garbage out:
>>> import traceback
>>> try:
... value = u'hello'.encode('utf16')
... raise ValueError('Invalid value %s' % value)
... except:
... traceback.format_exc()
...
'Traceback (most recent call last):\n File "",
line 2, in ?\nValueError: Invalid value
\xff\xfeh\x00e\x00l\x00l\x00o\x00\n'
So if an exception is raised that is not pure ASCII, we
end up with a traceback in an unknown encoding, and
possibly in no valid encoding at all.
This is problematic to applications which work with
Unicode strings internally, as when they try to report
the error they need to convert the traceback to ASCII
and they will get an encoding exception (non Unicode
applications tend to just spit out the byte stream and
let the user deal with it). Raising an exception that
resets your xterm's title is left as an excercise to
the reader ;)
Should the traceback module sanitize tracebacks it
returns, or is the burden on the application (eg. the
Python interactive interpreter, cgitb etc.) to sanitize
tracebacks using something like:
traceback = traceback.decode('ascii',
'replace').encode('ascii', 'backslashreplace')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284496&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1281383 ] array.arrays are not unpickleable
Bugs item #1281383, was opened at 2005-09-03 13:16
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&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: Closed
Resolution: Invalid
Priority: 6
Submitted By: Reinhold Birkenfeld (birkenfeld)
Assigned to: Raymond Hettinger (rhettinger)
Summary: array.arrays are not unpickleable
Initial Comment:
Credits to John Machin for discovering this.
"""
Googling for "pickle array" in comp.lang.python yields
old messages that
show a PickleError -- plus one message where Alex
Martelli writes "I am
but an egg" :O)
Looks like arrays are NOW (2.4.1) pickleable but not
unpickleable -- see
below.
I appreciate that arrays are inherently not pickleable
because of the
type code.
However:
(1) Anyone know why/when the world changed?
(2) If we had alternative constructors like
array.iarray(contents) in
parallel to array.array('i', contents), those objects
could be
pickled/unpickled -- yes/no?
Cheers,
John
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310
32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import pickle, array
>>> class Foo(object):
...pass
...
>>> foo = Foo()
>>> foo.ia = array.array('i', [3,2,1])
>>> foo.ia
array('i', [3, 2, 1])
>>> s = pickle.dumps(foo, -1)
>>> bar = pickle.loads(s)
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python24\lib\pickle.py", line 1394, in loads
return Unpickler(file).load()
File "C:\Python24\lib\pickle.py", line 872, in load
dispatch[key](self)
File "C:\Python24\lib\pickle.py", line 1097, in
load_newobj
obj = cls.__new__(cls, *args)
TypeError: array() takes at least 1 argument (0 given)
===
"""
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-09-07 23:04
Message:
Logged In: YES
user_id=341410
Raymond, they seem to be asking for Pickle and cPickle to
raise an exception when someone attempts to pickle arrays in
a future Python 2.4.2 release. I don't think that is a new
feature.
As for 2.5, real pickle support seems reasonable.
--
Comment By: John Machin (sjmachin)
Date: 2005-09-04 03:41
Message:
Logged In: YES
user_id=480138
Please fix the bug in Python 2.4: if array objects are not
pickleable in 2.4, then pickle and cPickle should raise a
PickleError [like they used to in earlier versions] --
instead of guessing wrongly and misleading callers into
thinking that the objects can be pickled.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-03 16:20
Message:
Logged In: YES
user_id=80475
In Py2.4, array's became copyable, weak-referencable, and
got support for iterator arguments. Real pickle support
wasn't added until Py2.5. The above code fragment is a
by-product of pickle making an incorrect guess at how to
pickle arrays before real pickel support was added. It is
not really a bug; rather, it begs for a feature that wasn't
added to later.
If it weren't a new feature, I would just backport the 2.5
pickle support.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-968430 ] error flattening complex smime signed message
Bugs item #968430, was opened at 2004-06-07 20:34 Message generated for change (Comment added) made by hta You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ludovico Magnocavallo (ludo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: error flattening complex smime signed message Initial Comment: Python 2.3.3 [GCC 3.2.2] on linux2 email version 2.5.5 Complex SMIME signed messages parsed and flattened again do not pass SMIME verification. I have noticed this with messages that have as message/rfc822 attachment another SMIME signed message. A diff between an "original" SMIME signed messaged passign openssl smime -verify verification and the same message parsed (message_from_file) and flattened (as_string(False)) by the email library: diff -bB bugmsg_signed.eml bugmsg_signed_parsed.eml 2c2,3 < Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="381546B4549948B9F93D885A82884C49" --- > Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; > micalg=sha1; boundary="381546B4549948B9F93D885A82884C49" The email-parsed message splits the signature header into two lines, thus rendering the message non-valid. Attached to this bug a .zip archive with: - msg #1: the non-signed message (with a signed message as attachment) - msg #2: message #1 signed by openssl - msg #3: message #2 parsed and flattened as described above - the CA certificate file used for smime verification openssl command used to verify #2 and #3: openssl smime -verify -in bugmsg_signed.eml -CAfile cacert.pem openssl smime -verify -in bugmsg_signed_parsed.eml -CAfile cacert.pem -- Comment By: Harald Tveit Alvestrand (hta) Date: 2005-09-08 06:16 Message: Logged In: YES user_id=12193 Adding my voice that the bug is important. This is now the chief culprit in breaking signed messages in my usage of signed email on the net; that "signtures are so often broken" is one argument people often use against using signed email. -- Comment By: Bas Wijnen (shevek) Date: 2005-01-25 09:37 Message: Logged In: YES user_id=42389 In case it is any help, I tried to find the problem in the source. I don't speak python, so I can't fix anything, but I do speak C, so it's quite readable. :-) It seems to me that the problem is in Lib/email/Message.py, in particular in _parseparam and _get_params_preserve. Both these functions call strip() on the object several times (which seems a bit overdone anyway ;-) ), which I presume removes all whitespace around them. I think the whitespace should somehow be saved (not stripping will probably break many programs, so that's not a good idea), so it can be used again when the header is written. set_param should of course also fill this value, so new params get a defined separation (although the empty string is quite acceptable). How this should be implemented I gladly leave to someone who actually speaks Python. :-) -- Comment By: Bas Wijnen (shevek) Date: 2005-01-24 11:43 Message: Logged In: YES user_id=42389 I would like to add that I think this bug is quite important, as mailman uses python. This means that many mailing lists invalidate signatures when signed e-mails with attachments are sent through them. As attachments are often code patches, it is quite important that the signatures are working correctly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1281692 ] urllib violates rfc 959
Bugs item #1281692, was opened at 2005-09-04 10:30 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281692&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: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib violates rfc 959 Initial Comment: [forwarded from http://bugs.debian.org/324023] python's urllib does the following things "on the line" when retrieving a file by ftp: send(3, "PASV\r\n", 6, 0) = 6 send(3, "NLST ftp-master.debian.org\r\n", 28, 0) = 28 But RFC 959 states: This command [NLST] causes a directory listing to be sent from server to user site. The pathname should specify a directory or other system-specific file group descriptor So, according to the robustness principle, it is wrong that python aborts file transfer if the server refuses to support NLST on files. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-07 23:18 Message: Logged In: YES user_id=341410 "The pathname should specify a directory or other system-specific file group descriptor." If the system (ftp server) does not support a particular 'file name' as a 'file group descriptor', it seems to me that the system (ftp server) is braindead. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281692&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1281383 ] array.arrays are not unpickleable
Bugs item #1281383, was opened at 2005-09-03 15:16
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&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: Closed
Resolution: Invalid
Priority: 6
Submitted By: Reinhold Birkenfeld (birkenfeld)
>Assigned to: Nobody/Anonymous (nobody)
Summary: array.arrays are not unpickleable
Initial Comment:
Credits to John Machin for discovering this.
"""
Googling for "pickle array" in comp.lang.python yields
old messages that
show a PickleError -- plus one message where Alex
Martelli writes "I am
but an egg" :O)
Looks like arrays are NOW (2.4.1) pickleable but not
unpickleable -- see
below.
I appreciate that arrays are inherently not pickleable
because of the
type code.
However:
(1) Anyone know why/when the world changed?
(2) If we had alternative constructors like
array.iarray(contents) in
parallel to array.array('i', contents), those objects
could be
pickled/unpickled -- yes/no?
Cheers,
John
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310
32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import pickle, array
>>> class Foo(object):
...pass
...
>>> foo = Foo()
>>> foo.ia = array.array('i', [3,2,1])
>>> foo.ia
array('i', [3, 2, 1])
>>> s = pickle.dumps(foo, -1)
>>> bar = pickle.loads(s)
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python24\lib\pickle.py", line 1394, in loads
return Unpickler(file).load()
File "C:\Python24\lib\pickle.py", line 872, in load
dispatch[key](self)
File "C:\Python24\lib\pickle.py", line 1097, in
load_newobj
obj = cls.__new__(cls, *args)
TypeError: array() takes at least 1 argument (0 given)
===
"""
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-08 01:36
Message:
Logged In: YES
user_id=80475
I think you're misunderstanding. Direct pickling of arrays
does raise a TypeError. It would be nice if it also did as
an object attribute; however, I'm not bothered by it enough
to spend development time tracing down the issue and then
altering otherwise correct Py2.4 code just to generate a
prettier message. It is enough for me that the docs do not
promise pickling, that a message is generated by a direct
attempt to pickle, that the OP's buggy code eventually
errors out, and that everything works fine in Py2.5.
I have no objections to someone finding a way to generate a
better error message but think the time would better be
spent elsewhere.
>>> from array import array
>>> from pickle import dumps, loads
>>> ia = array('i', [3,2,1])
>>> ib = loads(dumps(ia))
Traceback (most recent call last):
. . .
TypeError: can't pickle array objects
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-09-08 01:04
Message:
Logged In: YES
user_id=341410
Raymond, they seem to be asking for Pickle and cPickle to
raise an exception when someone attempts to pickle arrays in
a future Python 2.4.2 release. I don't think that is a new
feature.
As for 2.5, real pickle support seems reasonable.
--
Comment By: John Machin (sjmachin)
Date: 2005-09-04 05:41
Message:
Logged In: YES
user_id=480138
Please fix the bug in Python 2.4: if array objects are not
pickleable in 2.4, then pickle and cPickle should raise a
PickleError [like they used to in earlier versions] --
instead of guessing wrongly and misleading callers into
thinking that the objects can be pickled.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-03 18:20
Message:
Logged In: YES
user_id=80475
In Py2.4, array's became copyable, weak-referencable, and
got support for iterator arguments. Real pickle support
wasn't added until Py2.5. The above code fragment is a
by-product of pickle making an incorrect guess at how to
pickle arrays before real pickel support was added. It is
not really a bug; rather, it begs for a feature that wasn't
added to later.
If it weren't a new feature, I would just backport the 2.5
pickle support.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
