[ python-Bugs-1534765 ] logging's fileConfig causes KeyError on shutdown
Bugs item #1534765, was opened at 2006-08-05 05:58 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534765&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: mdbeachy (mdbeachy) Assigned to: Vinay Sajip (vsajip) Summary: logging's fileConfig causes KeyError on shutdown Initial Comment: If logging.config.fileConfig() is called after logging handlers already exist, a KeyError is thrown in the atexit call to logging.shutdown(). This looks like it's fixed in the 2.5 branch but since I've bothered to figure out what was going on I'm sending this in anyway. There still might be a 2.4.4, right? (Also, my fix looks better than what was done for 2.5, but I suppose the flush/close I added may not be necessary.) Attached is a demo and a patch against 2.4.3. Thanks, Mike -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2007-01-12 20:08 Message: Logged In: YES user_id=29957 Originator: NO Note, though, that there's no planned "next release" of 2.4. 2.4 is in "emergency security fix mode" - that is, unless someone finds a critical security problem, I don't plan to make further 2.4.x releases. If someone else wants to volunteer, of course, that's entirely fine. -- Comment By: Vinay Sajip (vsajip) Date: 2007-01-12 07:30 Message: Logged In: YES user_id=308438 Originator: NO Fix for SF #1632328 should cover this - checked into release24-maint. -- Comment By: Matt Fleming (splitscreen) Date: 2006-08-10 00:10 Message: Logged In: YES user_id=1126061 Bug confirmed in release24-maint. Patch looks good to me, although I think the developers prefer unified diffs, not contextual, just to keep in mind for the future. And also, I had to manually patch the Lib/logging/config.py file because for some reason, the paths in your patch all use lowercase letters. Thanks for the patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534765&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467929 ] %-formatting and dicts
Bugs item #1467929, was opened at 2006-04-11 05:39
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&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: 8
Private: No
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: %-formatting and dicts
Initial Comment:
This looks like a bug in the way the %-formatting code
works or is it a feature ?
>>> '%s %(a)s' % {'a': 'xyz'}
"{'a': 'xyz'} xyz"
>>> u'%s %(a)s' % {'a': 'xyz'}
u"{'a': 'xyz'} xyz"
Note that both strings and Unicode are affected.
Python 2.3 and 2.4 also show this behavior.
I would have expected an exception or the %-formatter
simply ignoring the first %s.
--
>Comment By: Anthony Baxter (anthonybaxter)
Date: 2007-01-12 20:10
Message:
Logged In: YES
user_id=29957
Originator: NO
I'm happy for this to be applied for 2.5.1. I don't have time to do it
myself for a few days, though, so feel free to beat me to it.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-19 15:25
Message:
Logged In: YES
user_id=849994
I'd say before 2.5 final...
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-08-19 08:17
Message:
Logged In: YES
user_id=38388
Should this patch be applied to the 2.5 branch ?
And if so, before or after the release of 2.5 ?
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-19 08:01
Message:
Logged In: YES
user_id=764593
Just a bit of encouragement for checking consistency like
this; the explicit error message would have helped with a
mistake I made earlier today. For one of several keys, I
mistyped it as "(%key)s", and a message about "not enough
values" just didn't make sense.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-08-04 23:26
Message:
Logged In: YES
user_id=38388
The patch looks OK.
I'd make it a TypeError and use "cannot use positional and
named formatting parameters at the same time" as message.
Thanks.
--
Comment By: Skip Montanaro (montanaro)
Date: 2006-08-04 23:21
Message:
Logged In: YES
user_id=44345
Looks okay to me, though why is the FORMAT_TYPE_UNKNOWN test
necessary in the second case but not the first?
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-25 22:35
Message:
Logged In: YES
user_id=11375
So, what should '%s' % {} do? Should it be 1) '{}' or 2) an
error because the argument is a mapping but the format
specifier doesn't have a '(key)'?
I've attached a draft patch that fixes stringobject.c; if
the approach is deemed OK, I'll apply it to unicodeobject.c,
too. PyString_Format() records the type of argument being
processed (a tuple or a mapping) and raises ValueError if
you mix them, at the cost of two extra comparisons for each
format specifier processed. This preserves the current
behaviour of '%s' % dictionary.
Questions: 1) is the approach reasonably clear? 2) are the
additional two comparisons unacceptably slow? 3) Is
ValueError the right exception? 4) can someone come up with
a better exception message than "both keyed and unkeyed
format specifiers used"?
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-07-25 06:07
Message:
Logged In: YES
user_id=21627
IMO, it's correct to break backwards compatibility, as the
current behaviour clearly violates the spec; I'm not sure
whether it's good to break the behaviour *now* (i.e. with no
further betas before the release of 2.5).
Deferring to the release manager.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 23:37
Message:
Logged In: YES
user_id=849994
The library ref specifies that if a dict is supplied, the
format specifiers MUST include a mapping key, so the right
thing to do would be to raise an exception.
Is it worth breaking backwards compatibility, Martin?
--
Comment By: Hasan Diwan (hdiwan650)
Date: 2006-04-14 18:33
Message:
Logged In: YES
user_id=1185570
It looks as though it's a feature... The first %s will print
the whole dictionary as a string, the second, only that
value looked up by the key.
---
[ python-Bugs-1633863 ] AIX: configure ignores $CC; problems mit C++ comments
Bugs item #1633863, was opened at 2007-01-12 09:46 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=1633863&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 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: AIX: configure ignores $CC; problems mit C++ comments Initial Comment: CC=xlc_r ./configure does not work on AIX-5.1, because configure unconditionally sets $CC to "cc_r": case $ac_sys_system in AIX*) CC=cc_r without_gcc=;; It would be better to leave $CC and just add "-qthreaded" to $CFLAGS. Furthermore, much of the C source code of Python uses C++ /C99 comments. This is an error with the standard AIX compiler. Please add the compiler flag "-qcpluscmt". An alternative would be to use a default of "xlc_r" for CC on AIX. This calls the compiler in a mode that both accepts C++ comments and generates reentrant code. Regards, Johannes -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633863&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633941 ] for line in sys.stdin: doesn't notice EOF the first time
Bugs item #1633941, was opened at 2007-01-12 11:34 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=1633941&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: for line in sys.stdin: doesn't notice EOF the first time Initial Comment: [forwarded from http://bugs.debian.org/315888] for line in sys.stdin: doesn't notice EOF the first time when reading from tty. The test program: import sys for line in sys.stdin: print line, print "eof" A sample session: [EMAIL PROTECTED] python foo.py foo <--- I pressed Enter and then Ctrl-D foo <--- then this appeared, but not more eof <--- this only came when I pressed Ctrl-D a second time [EMAIL PROTECTED] Seems to me that there is some buffering issue where Python needs to read end-of-file twice to notice it on all levels. Once should be enough. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633941&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633953 ] re.compile("(.*$){1,4}", re.MULTILINE) fails
Bugs item #1633953, was opened at 2007-01-12 11:45
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=1633953&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re.compile("(.*$){1,4}", re.MULTILINE) fails
Initial Comment:
[forwarded from http://bugs.debian.org/289603]
Trying to match 1-4 lines of arbitrary content (as part of a larger regex)
using the expression (.*$){1,4} and re.MULTILINE. This caused the re module to
raise the error "nothing to repeat".
$ python2.5
Python 2.5 (release25-maint, Dec 13 2006, 16:21:45)
[GCC 4.1.2 20061212 (prerelease) (Ubuntu 4.1.1-21ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.compile("(.*$){1,4}", re.MULTILINE)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/re.py", line 180, in compile
return _compile(pattern, flags)
File "/usr/lib/python2.5/re.py", line 233, in _compile
raise error, v # invalid expression
sre_constants.error: nothing to repeat
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633953&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633863 ] AIX: configure ignores $CC; problems with C++ style comments
Bugs item #1633863, was opened at 2007-01-12 09:46 Message generated for change (Settings changed) made by jabt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633863&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 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) >Summary: AIX: configure ignores $CC; problems with C++ style comments Initial Comment: CC=xlc_r ./configure does not work on AIX-5.1, because configure unconditionally sets $CC to "cc_r": case $ac_sys_system in AIX*) CC=cc_r without_gcc=;; It would be better to leave $CC and just add "-qthreaded" to $CFLAGS. Furthermore, much of the C source code of Python uses C++ /C99 comments. This is an error with the standard AIX compiler. Please add the compiler flag "-qcpluscmt". An alternative would be to use a default of "xlc_r" for CC on AIX. This calls the compiler in a mode that both accepts C++ comments and generates reentrant code. Regards, Johannes -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633863&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1634033 ] configure problem for sem_init() on HP-UX
Bugs item #1634033, was opened at 2007-01-12 14:01 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=1634033&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 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: configure problem for sem_init() on HP-UX Initial Comment: On HP-UX 11.00, sem_init is in librt. As configure calls the linker without -lrt, linking the sem_init test program fails. I suggest adding -lrt to the linker flags when linking the sem_init test program in configure on HP-UX. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1634033&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1634034 ] Show "expected" token on syntax error
Feature Requests item #1634034, was opened at 2007-01-12 13:03
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=1634034&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.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Oliver Gramberg (oliver_gramberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Show "expected" token on syntax error
Initial Comment:
I suggest that the parser, when reporting a syntax
error, should make use of its knowlegde of which token
type is expected at the position where the error
occurred. This results in more helpful error messages:
-
>>> for a in (8,9)
File "", line 1
for a in (8,9)
^
SyntaxError: invalid syntax - COLON expected
-
>>> for a in (8,9: print a,
File "", line 1
for a in (8,9: print a,
^
SyntaxError: invalid syntax: RPAR expected
-
I tried the following patch (for pythonrun.c). It works
well in the shell both interactively and in scripts,
as well as in IDLE. But it's not complete:
- It doesn't always print useful messages (only for
fixed-size terminal token types, I assume.)
- There sure are cases where more than one token type
is allowed in a position. I believe I have seen that
this information is available too somewhere in the
parser, but it is not forwarded to the err_input
routine.
It's even nicer to show "')'" instead of "RPAR"...
-
/* Set the error appropriate to the given input error code (see errcode.h) */
static void
err_input(perrdetail *err)
{
PyObject *v, *w, *errtype;
PyObject* u = NULL;
char *msg = NULL;
errtype = PyExc_SyntaxError;
switch (err->error) {
case E_SYNTAX:
errtype = PyExc_IndentationError;
if (err->expected == INDENT)
msg = "expected an indented block";
else if (err->token == INDENT)
msg = "unexpected indent";
else if (err->token == DEDENT)
msg = "unexpected unindent";
else {
char buf[50];
errtype = PyExc_SyntaxError;
if(err->expected != -1) {
snprintf(buf, 48, "invalid syntax - %.16s
expected\0",
_PyParser_TokenNames[err->expected]);
msg = buf;
} else {
msg = "invalid syntax";
}
}
break;
...
-
I am willing to help work on this.
Regards
-Oliver
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1634034&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1634033 ] configure problem for sem_init() on HP-UX
Bugs item #1634033, was opened at 2007-01-12 14:01 Message generated for change (Settings changed) made by jabt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1634033&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: Deleted Resolution: None Priority: 5 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: configure problem for sem_init() on HP-UX Initial Comment: On HP-UX 11.00, sem_init is in librt. As configure calls the linker without -lrt, linking the sem_init test program fails. I suggest adding -lrt to the linker flags when linking the sem_init test program in configure on HP-UX. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1634033&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1634105 ] AIX: wrong flags for ld when linking standard .so modules
Bugs item #1634105, was opened at 2007-01-12 15:51 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=1634105&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: AIX: wrong flags for ld when linking standard .so modules Initial Comment: The build process on my AIX 5.1 (using the native compiler suite) does not work for the standard .so modules (like _locale, unicodedata, fcntl, ...) [..] creating build/lib.hp-ux-B.11.00-9000-785-2.5 ld -b -L/usr/local/python/lib -Wl,+b,/usr/local/python/2.5/lib:/usr/local/ssl/lib,[...]-o build/lib.hp-ux-B.11.00-9000-785-2.5/_struct.sl ld: Unrecognized argument: -Wl,+b[...] ld: Usage: ld [options] [flags] files You can pass "-Wl,+b" to the compiler, but for the linker, you have to drop the "-Wl,". What's even worse: Even though "ld" aborts with an error, the build process ignories this. I have to idea of where to start looking for the bug(s). Bye, Johannes -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1634105&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1467929 ] %-formatting and dicts
Bugs item #1467929, was opened at 2006-04-10 15:39
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&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: 8
Private: No
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: %-formatting and dicts
Initial Comment:
This looks like a bug in the way the %-formatting code
works or is it a feature ?
>>> '%s %(a)s' % {'a': 'xyz'}
"{'a': 'xyz'} xyz"
>>> u'%s %(a)s' % {'a': 'xyz'}
u"{'a': 'xyz'} xyz"
Note that both strings and Unicode are affected.
Python 2.3 and 2.4 also show this behavior.
I would have expected an exception or the %-formatter
simply ignoring the first %s.
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2007-01-12 09:57
Message:
Logged In: YES
user_id=11375
Originator: NO
The patch shouldn't be applied as it stands, though, because it's not
complete; similiar changes need to be made to the Unicode type, for a
start.
To answer Skip's question: I don't remember the logic of the format code.
I think the FORMAT_TYPE_UNKNOWN check may be unnecessary; the code could
just always do format_type = _TUPLE, occasionally doing a redundant
assignment (but who cares)?
I don't think I'll have any chance to work on this; PyCon is keeping me
busy, and the mailbox bugs will take priority for me.
--
Comment By: Anthony Baxter (anthonybaxter)
Date: 2007-01-12 04:10
Message:
Logged In: YES
user_id=29957
Originator: NO
I'm happy for this to be applied for 2.5.1. I don't have time to do it
myself for a few days, though, so feel free to beat me to it.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-19 01:25
Message:
Logged In: YES
user_id=849994
I'd say before 2.5 final...
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-08-18 18:17
Message:
Logged In: YES
user_id=38388
Should this patch be applied to the 2.5 branch ?
And if so, before or after the release of 2.5 ?
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-18 18:01
Message:
Logged In: YES
user_id=764593
Just a bit of encouragement for checking consistency like
this; the explicit error message would have helped with a
mistake I made earlier today. For one of several keys, I
mistyped it as "(%key)s", and a message about "not enough
values" just didn't make sense.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-08-04 09:26
Message:
Logged In: YES
user_id=38388
The patch looks OK.
I'd make it a TypeError and use "cannot use positional and
named formatting parameters at the same time" as message.
Thanks.
--
Comment By: Skip Montanaro (montanaro)
Date: 2006-08-04 09:21
Message:
Logged In: YES
user_id=44345
Looks okay to me, though why is the FORMAT_TYPE_UNKNOWN test
necessary in the second case but not the first?
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-07-25 08:35
Message:
Logged In: YES
user_id=11375
So, what should '%s' % {} do? Should it be 1) '{}' or 2) an
error because the argument is a mapping but the format
specifier doesn't have a '(key)'?
I've attached a draft patch that fixes stringobject.c; if
the approach is deemed OK, I'll apply it to unicodeobject.c,
too. PyString_Format() records the type of argument being
processed (a tuple or a mapping) and raises ValueError if
you mix them, at the cost of two extra comparisons for each
format specifier processed. This preserves the current
behaviour of '%s' % dictionary.
Questions: 1) is the approach reasonably clear? 2) are the
additional two comparisons unacceptably slow? 3) Is
ValueError the right exception? 4) can someone come up with
a better exception message than "both keyed and unkeyed
format specifiers used"?
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-07-24 16:07
Message:
Logged In: YES
user_id=21627
IMO, it's correct to break backwards compatibility, as the
current behaviour clearly violates the spec; I'm not sure
whether it's good to break the behaviour *now* (i.e. with no
further betas before the release of 2.5).
Deferring to the release manager.
--
[ python-Bugs-1634105 ] AIX: wrong flags for ld when linking standard .so modules
Bugs item #1634105, was opened at 2007-01-12 15:51 Message generated for change (Settings changed) made by jabt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1634105&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: None >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: AIX: wrong flags for ld when linking standard .so modules Initial Comment: The build process on my AIX 5.1 (using the native compiler suite) does not work for the standard .so modules (like _locale, unicodedata, fcntl, ...) [..] creating build/lib.hp-ux-B.11.00-9000-785-2.5 ld -b -L/usr/local/python/lib -Wl,+b,/usr/local/python/2.5/lib:/usr/local/ssl/lib,[...]-o build/lib.hp-ux-B.11.00-9000-785-2.5/_struct.sl ld: Unrecognized argument: -Wl,+b[...] ld: Usage: ld [options] [flags] files You can pass "-Wl,+b" to the compiler, but for the linker, you have to drop the "-Wl,". What's even worse: Even though "ld" aborts with an error, the build process ignories this. I have to idea of where to start looking for the bug(s). Bye, Johannes -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1634105&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: 9 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: A.M. Kuchling (akuchling) Date: 2007-01-12 12:12 Message: Logged In: YES user_id=11375 Originator: NO So shall we document flush() as invalidating keys, then? -- Comment By: David Watson (baikie) Date: 2007-01-06 14:57 Message: Logged In: YES user_id=1504904 Originator: YES Oops, length checking had made the first two lines of this patch redundant; update-toc applies OK with fuzz. File Added: mailbox-copy-back-new.diff -- Comment By: David Watson (baikie) Date: 2007-01-06 10:30 Message: Logged In: YES user_id=1504904 Originator: YES File Added: mailbox-copy-back-53287.diff -- Comment By: David Watson (baikie) Date: 2007-01-06 10:24 Message: Logged In: YES user_id=1504904 Originator: YES Aack, yes, that should be _next_user_key. Attaching a fixed version. I've been thinking, though: flush() does in fact invalidate the keys on platforms without a file.truncate(), when the fcntl() lock is momentarily released afterwards. It seems hard to avoid this as, perversely, fcntl() locks are supposed to be released automatically on all file descriptors referring to the file whenever the process closes any one of them - even one the lock was never set on. So, code using mailbox.py such platforms could inadvertently be carrying keys across an unlocked period, which is not made safe by the update-toc patch (as it's only meant to avert disasters resulting from doing this *and* rebuilding the table of contents, *assuming* that another process hasn't deleted or rearranged messages). File Added: mailbox-update-toc-fixed.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 14:51 Message: Logged In: YES user_id=11375 Originator: NO Question about mailbox-update-doc: the add() method still returns self._next_key - 1; should this be self._next_user_key - 1? The keys in _user_toc are the ones returned to external users of the mailbox, right? (A good test case would be to initialize _next_key to 0 and _next_user_key to a different value like 123456.) I'm still staring at the patch, trying to convince myself that it will help -- haven't spotted any problems, but this bug is making me nervous... -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 14:24 Message: Logged In: YES user_id=11375 Originator: NO As a step toward improving matters, I've attached the suggested doc patch (for both 25-maint and trunk). It encourages people to use Maildir :), explicitly states that modifications should be bracketed by lock(), and fixes the examples to match. It does not say that keys are invalidated by doing a flush(), because we're going to try
[ python-Bugs-1633678 ] mailbox.py _fromlinepattern regexp does not support positive
Bugs item #1633678, was opened at 2007-01-11 20:14 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633678&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) >Assigned to: A.M. Kuchling (akuchling) Summary: mailbox.py _fromlinepattern regexp does not support positive Initial Comment: [forwarded from http://bugs.debian.org/254757] mailbox.py _fromlinepattern regexp does not support positive GMT offsets. the pattern didn't change in 2.5. bug submitter writes: archivemail incorrectly splits up messages in my mbox-format mail archvies. I use Squirrelmail, which seems to create mbox lines that look like this: >From [EMAIL PROTECTED] Mon Jan 26 12:29:24 2004 -0400 The "-0400" appears to be throwing it off. If the first message of an mbox file has such a line on it, archivemail flat out stops, saying the file is not mbox. If the later messages in an mbox file are in this style, they are not counted, and archivemail thinks that the preceding message is just kind of long, and the decision to archive or not is broken. I have stumbled on this bug when I wanted to archive my mails on a Sarge system. And since my TZ is positive, the regexp did not work. I think the correct regexp for /usr/lib/python2.3/mailbox.py should be: _fromlinepattern = r"From \s*[^\s]+\s+\w\w\w\s+\w\w\w\s+\d?\d\s+" \ r"\d?\d:\d\d(:\d\d)?(\s+[^\s]+)?\s+\d\d\d\d\s*((\+|-)\d\d\d\d)?\s*$" This should handle positive and negative timezones in From lines. I have tested it successfully with an email beginning with this line: >From [EMAIL PROTECTED] Mon May 31 13:24:50 2004 +0200 as well as one withouth TZ reference. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633678&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1633665 ] file(file) should succeed
Feature Requests item #1633665, was opened at 2007-01-11 19:50
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1633665&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: Closed
>Resolution: Wont Fix
Priority: 3
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: file(file) should succeed
Initial Comment:
[forwarded from http://bugs.debian.org/327060]
Many types in Python are idempotent, so that int(1) works
as expected, float(2.34)==2.34, ''.join('hello')=='hello'
et cetera.
Why not file()? Currently, file(open(something, 'r')) fails
with "TypeError: coercing to Unicode: need string or buffer, file found."
Semantically, file(fd) should be equivalent to os.fdopen(fd.fileno())
or the proposed file.fromfd() (Jp Calderone, Python-dev, 2003).
You should get another independent
file object that accesses the same file.
What would be gained?
Primarily, it would allow you to derive classes from file more easily.
At present, if you want to derive like so, you're class can only work
when passed a file name or buffer.
class file_with_caching(file):
def __init__(self, something):
file.__init__(self, something)
def etcetera...
For instance, you have no way of creating a file_with_caching()
object from the file descriptors returned from os.fork().
Also, you have no way of taking a file that is already open,
and creating a file_with_caching() object from it.So,
you can't use classes derived from file() on the standard input
or standard output.
This breaks the nice Linux OS-level definition of a file descriptor.
At the Linux level, you have a nice uniform interface where all
file descriptors are equally good.At the python level, some
are better than others. It's a case where Python unnecessarily
restricts what you can do.
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2007-01-12 13:31
Message:
Logged In: YES
user_id=11375
Originator: NO
Reclassifying as feature request.
Response from GvR is at
http://mail.python.org/pipermail/python-dev/2007-January/070591.html
This proposal probably won't be implemented; closing as "Won't fix".
Thanks for the suggestion, though.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1633665&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: 9 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: A.M. Kuchling (akuchling) Date: 2007-01-12 13:41 Message: Logged In: YES user_id=11375 Originator: NO I realized that making flush() invalidate keys breaks the final example in the docs, which loops over inbox.iterkeys() and removes messages, doing a pack() after each message. Which platforms lack file.truncate()? Windows has it; POSIX has it, so modern Unix variants should all have it. Maybe mailbox should simply raise an exception (or trigger a warning?) if truncate is missing, and we should then assume that flush() has no effect upon keys. -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-12 12:12 Message: Logged In: YES user_id=11375 Originator: NO So shall we document flush() as invalidating keys, then? -- Comment By: David Watson (baikie) Date: 2007-01-06 14:57 Message: Logged In: YES user_id=1504904 Originator: YES Oops, length checking had made the first two lines of this patch redundant; update-toc applies OK with fuzz. File Added: mailbox-copy-back-new.diff -- Comment By: David Watson (baikie) Date: 2007-01-06 10:30 Message: Logged In: YES user_id=1504904 Originator: YES File Added: mailbox-copy-back-53287.diff -- Comment By: David Watson (baikie) Date: 2007-01-06 10:24 Message: Logged In: YES user_id=1504904 Originator: YES Aack, yes, that should be _next_user_key. Attaching a fixed version. I've been thinking, though: flush() does in fact invalidate the keys on platforms without a file.truncate(), when the fcntl() lock is momentarily released afterwards. It seems hard to avoid this as, perversely, fcntl() locks are supposed to be released automatically on all file descriptors referring to the file whenever the process closes any one of them - even one the lock was never set on. So, code using mailbox.py such platforms could inadvertently be carrying keys across an unlocked period, which is not made safe by the update-toc patch (as it's only meant to avert disasters resulting from doing this *and* rebuilding the table of contents, *assuming* that another process hasn't deleted or rearranged messages). File Added: mailbox-update-toc-fixed.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 14:51 Message: Logged In: YES user_id=11375 Originator: NO Question about mailbox-update-doc: the add() method still returns self._next_key - 1; should this be self._next_user_key - 1? The keys in _user_toc are the ones returned to external users of the mailbox, right? (A good test case would be to initialize _next_key to 0 and _next_user_key to a different value like 123456.) I'm still staring at the patch,
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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: 9 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: A.M. Kuchling (akuchling) Date: 2007-01-12 14:41 Message: Logged In: YES user_id=11375 Originator: NO One OS/2 port lacks truncate(), and so does RISCOS. -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-12 13:41 Message: Logged In: YES user_id=11375 Originator: NO I realized that making flush() invalidate keys breaks the final example in the docs, which loops over inbox.iterkeys() and removes messages, doing a pack() after each message. Which platforms lack file.truncate()? Windows has it; POSIX has it, so modern Unix variants should all have it. Maybe mailbox should simply raise an exception (or trigger a warning?) if truncate is missing, and we should then assume that flush() has no effect upon keys. -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-12 12:12 Message: Logged In: YES user_id=11375 Originator: NO So shall we document flush() as invalidating keys, then? -- Comment By: David Watson (baikie) Date: 2007-01-06 14:57 Message: Logged In: YES user_id=1504904 Originator: YES Oops, length checking had made the first two lines of this patch redundant; update-toc applies OK with fuzz. File Added: mailbox-copy-back-new.diff -- Comment By: David Watson (baikie) Date: 2007-01-06 10:30 Message: Logged In: YES user_id=1504904 Originator: YES File Added: mailbox-copy-back-53287.diff -- Comment By: David Watson (baikie) Date: 2007-01-06 10:24 Message: Logged In: YES user_id=1504904 Originator: YES Aack, yes, that should be _next_user_key. Attaching a fixed version. I've been thinking, though: flush() does in fact invalidate the keys on platforms without a file.truncate(), when the fcntl() lock is momentarily released afterwards. It seems hard to avoid this as, perversely, fcntl() locks are supposed to be released automatically on all file descriptors referring to the file whenever the process closes any one of them - even one the lock was never set on. So, code using mailbox.py such platforms could inadvertently be carrying keys across an unlocked period, which is not made safe by the update-toc patch (as it's only meant to avert disasters resulting from doing this *and* rebuilding the table of contents, *assuming* that another process hasn't deleted or rearranged messages). File Added: mailbox-update-toc-fixed.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-05 14:51 Message: Logged In: YES user_id=11375 Originator: NO Question about mailbox-update-doc: the add() method still returns self._next_key - 1; should this be self._next_us
[ python-Bugs-1634343 ] subprocess swallows empty arguments under win32
Bugs item #1634343, was opened at 2007-01-12 21:40
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=1634343&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Patrick Mézard (pmezard)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess swallows empty arguments under win32
Initial Comment:
Hello,
empty arguments are not quoted by subprocess.list2cmdline. Therefore nothing is
concatenated with other arguments. To reproduce it:
test-empty.py
"""
import sys
print sys.argv
"""
then:
"""
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> p = subprocess.Popen(['python', 'test-empty.py', ''],
>>> stdout=subprocess.PIPE)
>>> p.communicate()
("['test-empty.py']\r\n", None)
"""
To solve it:
"""
--- a\subprocess.py 2007-01-12 21:38:57.734375000 +0100
+++ b\subprocess.py 2007-01-12 21:34:08.40625 +0100
@@ -499,7 +499,7 @@
if result:
result.append(' ')
-needquote = (" " in arg) or ("\t" in arg)
+needquote = (" " in arg) or ("\t" in arg) or not arg
if needquote:
result.append('"')
"""
Regard,
Patrick Mézard
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1634343&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633605 ] logging module / wrong bytecode?
Bugs item #1633605, was opened at 2007-01-11 18:06
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633605&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging module / wrong bytecode?
Initial Comment:
[forwarded from http://bugs.debian.org/390152]
seen with python2.4 and python2.5 on debian unstable
import logging
logging.basicConfig(level=logging.DEBUG,
format='%(pathname)s:%(lineno)d')
logging.info('whoops')
The output when the logging/__init__.pyc file exists is:
logging/__init__.py:1072
and when the __init__.pyc is deleted the output becomes:
tst.py:5
--
Comment By: Jim Jewett (jimjjewett)
Date: 2007-01-12 16:22
Message:
Logged In: YES
user_id=764593
Originator: NO
Does debian by any chance (try to?) store the .py and .pyc files in
different directories?
The second result is correct; the second suggests that it somehow got
confused about which frames to ignore.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633605&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633630 ] class derived from float evaporates under +=
Bugs item #1633630, was opened at 2007-01-11 18:49 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633630&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: Type/class unification Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: class derived from float evaporates under += Initial Comment: [forwarded from http://bugs.debian.org/345373] There seems to be a bug in classes derived from float. For instance, consider the following: >>> class Float(float): ... def __init__(self, v): ... float.__init__(self, v) ... self.x = 1 ... >>> a = Float(2.0) >>> b = Float(3.0) >>> type(a) >>> type(b) >>> a += b >>> type(a) Now, the type of a has silently changed. It was a Float, a derived class with all kinds of properties, and it became a float -- a plain vanilla number. My understanding is that this is incorrect, and certainly unexpected. If it *is* correct, it certainly deserves mention somewhere in the documentation. It seems that Float.__iadd__(a, b) should be called. This defaults to float.__iadd__(a, b), which should increment the float part of the object while leaving the rest intact. A possible explanation for this problem is that float.__iadd__ is not actually defined, and so it falls through to a = float.__add__(a, b), which assigns a float to a. This interpretation seems to be correct, as one can add a destructor to the Float class: >>> class FloatD(float): ... def __init__(self, v): ... float.__init__(self, v) ... self.x = 1 ... def __del__(self): ... print 'Deleting FloatD class, losing x=', self.x ... >>> a = FloatD(2.0) >>> b = FloatD(3.0) >>> a += b Deleting FloatD class, losing x= 1 >>> -- Comment By: Jim Jewett (jimjjewett) Date: 2007-01-12 16:26 Message: Logged In: YES user_id=764593 Originator: NO Python float objects are immutable and can be shared. Therefore, their values cannot be modified -- which is why it falls back to not-in-place assignment. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633630&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1381476 ] csv.reader endless loop
Bugs item #1381476, was opened at 2005-12-15 06:04
Message generated for change (Comment added) made by ironfroggy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381476&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
Private: No
Submitted By: Christian Harms (wwwingman)
Assigned to: Andrew McNamara (andrewmcnamara)
Summary: csv.reader endless loop
Initial Comment:
Hi,
the csv.reader produce a endless loop, ifan parsing
Error is in the last line of the CSV-File. If you put
an "\r" in the last line, cvs.Error is raised and
StopIteration will lost.
import csv, StringIO
fp = StringIO.StringIO("line1\nline2\rerror")
reader = csv.reader(fp)
while 1:
try:
print reader.next()
except csv.Error:
print "Error"
except StopIteration:
break
Die Problem is in python 2.3 AND python 2.4. Other
version are not checked.
--
Comment By: Calvin Spealman (ironfroggy)
Date: 2007-01-13 01:48
Message:
Logged In: YES
user_id=112166
Originator: NO
How do you expect it to handle this? Should it treat \r bytes as a newline
or as content of the field?
--
Comment By: Christian Harms (wwwingman)
Date: 2006-01-03 03:56
Message:
Logged In: YES
user_id=1405594
>birkenfeld: csv.Error would imply a StopIteration/break ...
No, this Error says only: "Can not parse THIS line ...".
This exception is used for reading buggy
outlook-Export-CSV-Files und trying to read some lines (not
all). And if the error is in the last line, the
StopIteration will be forgotten and the Error will be
produced in a endless-loop.
input = StringIO.StringIO("1.\rerror\n2.ok\n3.\rerr")
#insert my while-loop
#Output:
>Error
>2.ok
>Error
>Error
...
--
Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-17 12:02
Message:
Logged In: YES
user_id=1188172
Let the expert judge.
--
Comment By: Thomas Lee (krumms)
Date: 2005-12-17 11:56
Message:
Logged In: YES
user_id=315535
Actually, the problem may not be a problem with the csv
module at all, it may be a misinterpretation of the API on
the submitters part.
Is there any time a non-fatal csv.Error would/could be
raised? Seems to me that a csv.Error would imply a
StopIteration/break ...
--
Comment By: Thomas Lee (krumms)
Date: 2005-12-17 10:17
Message:
Logged In: YES
user_id=315535
I think this may be fixed in subversion:
[EMAIL PROTECTED]:~/work/python$ svn info
Path: .
URL: http://svn.python.org/projects/python/trunk
Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771
Revision: 41731
Node Kind: directory
Schedule: normal
Last Changed Author: fredrik.lundh
Last Changed Rev: 41729
Last Changed Date: 2005-12-17 18:33:21 +1000 (Sat, 17 Dec 2005)
Properties Last Updated: 2005-12-17 21:44:46 +1000 (Sat, 17
Dec 2005)
[EMAIL PROTECTED]:~/work/python$ python -V
Python 2.4.2
[EMAIL PROTECTED]:~/work/python$ python Sandbox/csv_reader_test.py
['line1']
ERROR: newline inside string
[EMAIL PROTECTED]:~/work/python$ ./python -V
Python 2.5a0
[EMAIL PROTECTED]:~/work/python$ ./python Sandbox/csv_reader_test.py
['line1']
ERROR: new-line character seen in unquoted field - do you
need to open the file in universal-newline mode?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381476&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
