[ python-Bugs-1510580 ] Setting category fails with -W switch
Bugs item #1510580, was opened at 2006-06-22 08:20
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=1510580&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Brett Cannon (bcannon)
Summary: Setting category fails with -W switch
Initial Comment:
This command reports an "invalid warning category"
error, but it shouldn't.
./python -W'ignore:Not importing directory:ImportWarning'
I think the change to new-style exceptions exposed this
problem. warnings.py contains the following code to
trigger this error:
if (not isinstance(cat, types.ClassType) or
not issubclass(cat, Warning)):
raise _OptionError("invalid warning category:
%r" % (category,))
The new-style exceptions mean that the first
isinstance() now returns False. I think there may be
two fixes needed. First, I think it should be
"isinstance(cat, types.ClassType) or isinstance(cat,
type)".
Second issue: hould the warnings.py code use "and"
instead of "or"? Surely if issubclass(cat, Warning) is
True, the category is certainly OK; no?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1510580 ] Setting category fails with -W switch
Bugs item #1510580, was opened at 2006-06-22 08:20
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Brett Cannon (bcannon)
Summary: Setting category fails with -W switch
Initial Comment:
This command reports an "invalid warning category"
error, but it shouldn't.
./python -W'ignore:Not importing directory:ImportWarning'
I think the change to new-style exceptions exposed this
problem. warnings.py contains the following code to
trigger this error:
if (not isinstance(cat, types.ClassType) or
not issubclass(cat, Warning)):
raise _OptionError("invalid warning category:
%r" % (category,))
The new-style exceptions mean that the first
isinstance() now returns False. I think there may be
two fixes needed. First, I think it should be
"isinstance(cat, types.ClassType) or isinstance(cat,
type)".
Second issue: hould the warnings.py code use "and"
instead of "or"? Surely if issubclass(cat, Warning) is
True, the category is certainly OK; no?
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-22 09:50
Message:
Logged In: YES
user_id=11375
Once the problem is fixed, the attached patch adds some
tests for warning parsing.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1510580 ] Setting category fails with -W switch
Bugs item #1510580, was opened at 2006-06-22 05:20
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Brett Cannon (bcannon)
Summary: Setting category fails with -W switch
Initial Comment:
This command reports an "invalid warning category"
error, but it shouldn't.
./python -W'ignore:Not importing directory:ImportWarning'
I think the change to new-style exceptions exposed this
problem. warnings.py contains the following code to
trigger this error:
if (not isinstance(cat, types.ClassType) or
not issubclass(cat, Warning)):
raise _OptionError("invalid warning category:
%r" % (category,))
The new-style exceptions mean that the first
isinstance() now returns False. I think there may be
two fixes needed. First, I think it should be
"isinstance(cat, types.ClassType) or isinstance(cat,
type)".
Second issue: hould the warnings.py code use "and"
instead of "or"? Surely if issubclass(cat, Warning) is
True, the category is certainly OK; no?
--
>Comment By: Brett Cannon (bcannon)
Date: 2006-06-22 09:05
Message:
Logged In: YES
user_id=357491
Well, the docs for warnings
(http://docs.python.org/dev/lib/warning-categories.html) say
that a category must subclass Warning. So I removed the
ClassType check entirely, and that causes test_exceptions to
segfault. Lovely.
I will try to look at this Friday.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-22 06:50
Message:
Logged In: YES
user_id=11375
Once the problem is fixed, the attached patch adds some
tests for warning parsing.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1510580 ] Setting category fails with -W switch
Bugs item #1510580, was opened at 2006-06-22 05:20
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Brett Cannon (bcannon)
Summary: Setting category fails with -W switch
Initial Comment:
This command reports an "invalid warning category"
error, but it shouldn't.
./python -W'ignore:Not importing directory:ImportWarning'
I think the change to new-style exceptions exposed this
problem. warnings.py contains the following code to
trigger this error:
if (not isinstance(cat, types.ClassType) or
not issubclass(cat, Warning)):
raise _OptionError("invalid warning category:
%r" % (category,))
The new-style exceptions mean that the first
isinstance() now returns False. I think there may be
two fixes needed. First, I think it should be
"isinstance(cat, types.ClassType) or isinstance(cat,
type)".
Second issue: hould the warnings.py code use "and"
instead of "or"? Surely if issubclass(cat, Warning) is
True, the category is certainly OK; no?
--
>Comment By: Brett Cannon (bcannon)
Date: 2006-06-22 09:13
Message:
Logged In: YES
user_id=357491
Turns out Armin's r47061 checkin fixed it; for some reason I
had not rebuilt. Doing a distclean and re-running tests
before committing the change.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-22 09:05
Message:
Logged In: YES
user_id=357491
Well, the docs for warnings
(http://docs.python.org/dev/lib/warning-categories.html) say
that a category must subclass Warning. So I removed the
ClassType check entirely, and that causes test_exceptions to
segfault. Lovely.
I will try to look at this Friday.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-22 06:50
Message:
Logged In: YES
user_id=11375
Once the problem is fixed, the attached patch adds some
tests for warning parsing.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1508253 ] logging fileConfig swallows handler exception
Bugs item #1508253, was opened at 2006-06-18 19:33
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&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: Works For Me
Priority: 5
Submitted By: tdir (tdir)
Assigned to: Vinay Sajip (vsajip)
Summary: logging fileConfig swallows handler exception
Initial Comment:
If you specify a handler such as a RotatingFileHandler
and the path you provide in the args specification
('option') is bad, config.fileConfig() catches the
exception and 'swallows' it. The result is later on,
when that handler is specified for a logger, you get an
exception saying there is no such handler. A much
friendlier behavior would be for fileConfig() to raise
an exception so the real cause of the problem can be
easily identified. Also, if there is a bug in the code
itself, it would also get swallowed in similar fashion.
In general, silently swallowing exceptions is rarely
the best choice IMHO.
Example ini with bad path (assuming /bad/path does not
exist):
[handler_defaultrotatingfile]
class=handlers.RotatingFileHandler
args=("/bad/path/logdir/my_log.log", 'w', 10, 10)
formatter=std
--
>Comment By: Vinay Sajip (vsajip)
Date: 2006-06-22 16:37
Message:
Logged In: YES
user_id=308438
Can you give some more details? I don't get the problem: see
the transcript below.
ActivePython 2.4 Build 243 (ActiveState Corp.) based on
Python 2.4 (#60, Nov 30 2004, 09:34:21) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import logging.config
>>> logging.config.fileConfig("junk.ini")
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python\lib\logging\config.py", line 83, in fileConfig
handlers = _install_handlers(cp, formatters)
File "C:\Python\lib\logging\config.py", line 151, in
_install_handlers
h = apply(klass, args)
File "C:\Python\lib\logging\handlers.py", line 109, in
__init__
BaseRotatingHandler.__init__(self, filename, mode, encoding)
File "C:\Python\lib\logging\handlers.py", line 61, in __init__
logging.FileHandler.__init__(self, filename, mode, encoding)
File "C:\Python\lib\logging\__init__.py", line 770, in
__init__
stream = open(filename, mode)
IOError: [Errno 2] No such file or directory:
'/bad/path/junk.log'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470422 ] Logging doesn't report the correct filename or line numbers
Bugs item #1470422, was opened at 2006-04-14 15:48
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470422&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: Postponed
Priority: 5
Submitted By: Michael Tsai (michaeltsai)
Assigned to: Vinay Sajip (vsajip)
Summary: Logging doesn't report the correct filename or line numbers
Initial Comment:
I have a logger that prints out %(filename)s:%(lineno)d along with the
message. Instead of printing the file and line in my code where I call the
logger, it prints out a location in logging/__init__.py.
I was able to fix this, at least for my purposes, by changing
logging.currentframe from sys._getframe to lambda:sys._getframe(3).
--
>Comment By: Vinay Sajip (vsajip)
Date: 2006-06-22 16:39
Message:
Logged In: YES
user_id=308438
Michael,
I'll close this now, please feel free to re-open and
reassign to me when you can reproduce the problem more
predictably.
--
Comment By: Michael Tsai (michaeltsai)
Date: 2006-04-21 19:04
Message:
Logged In: YES
user_id=817528
I'm running on Mac OS X 10.4.6.
Here's a simple script:
"""#!/usr/local/bin/python2.4
import logging
logging.basicConfig(format=u"%(filename)s:%(lineno)d %(message)s")
log = logging.getLogger("test")
log.error(u"this is an error")
"""
Unfortunately, it doesn't reliably fail; most of the time it works. I haven't
figured out how to trigger it.
It does reliably fail when I use a frozen system created with "py2app -A" in
which the Python libraries are symlinked in (rather than in a Zip). Then,
logging._srcfile is "logging/__init__.py", but __file__ is something like "/
System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/
logging/__init__.py" Maybe py2app shouldn't set sys.frozen in this case?
Anyway, I don't think that's the real problem, because I've seen this happen
when not using py2app (but, sorry, I'm not able to reliably duplicate it at
this
time).
My patch isn't really the right fix, but I do think it works because, at least
with
the current logging module, currentframe() is always called with the same
sequence of frames on the top of the stack.
--
Comment By: Vinay Sajip (vsajip)
Date: 2006-04-21 18:20
Message:
Logged In: YES
user_id=308438
Please can you provide a small script which demonstrates the
problem? Which platform are you running on? Is there
anything unusual about your setup (e.g. running from a
frozen system)?
I'm not sure your patch is the correct solution. The system
looks up the call stack until a file is found which is not
the source file of the logging module itself - that is
presumed to be the caller. However, determining the source
file of the logging module can come unstuck in scenarios
such as py2exe-ified programs.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470422&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1501699 ] method format of logging.Formatter caches incorrectly
Bugs item #1501699, was opened at 2006-06-06 15:14 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501699&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Boris Lorbeer (blorbeer) Assigned to: Vinay Sajip (vsajip) Summary: method format of logging.Formatter caches incorrectly Initial Comment: The format method of logging.Formatter is buggy in that it doesn't call the method formatException if the cache record.exc_text is set. If you have two Formatters that should format the same log record differently (i.e. each has its own overriding formatException method), the formatException method of the second formatter will never be called because the cache has been set by the first formatter. The proper way of using the cache is IMHO to check the cache only in the method formatException of logging.Formatter. -- >Comment By: Vinay Sajip (vsajip) Date: 2006-06-22 16:46 Message: Logged In: YES user_id=308438 It's not a bug, it's by design. The formatException method only takes the exception info as a parameter, and to change the method signature now could break some people's code, right? A solution would be for you to also override the format method in your custom formatter classes and set record.exc_text to None if you want to invalidate the cache before calling the base class implementation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501699&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1510580 ] Setting category fails with -W switch
Bugs item #1510580, was opened at 2006-06-22 05:20
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Brett Cannon (bcannon)
Summary: Setting category fails with -W switch
Initial Comment:
This command reports an "invalid warning category"
error, but it shouldn't.
./python -W'ignore:Not importing directory:ImportWarning'
I think the change to new-style exceptions exposed this
problem. warnings.py contains the following code to
trigger this error:
if (not isinstance(cat, types.ClassType) or
not issubclass(cat, Warning)):
raise _OptionError("invalid warning category:
%r" % (category,))
The new-style exceptions mean that the first
isinstance() now returns False. I think there may be
two fixes needed. First, I think it should be
"isinstance(cat, types.ClassType) or isinstance(cat,
type)".
Second issue: hould the warnings.py code use "and"
instead of "or"? Surely if issubclass(cat, Warning) is
True, the category is certainly OK; no?
--
>Comment By: Brett Cannon (bcannon)
Date: 2006-06-22 09:49
Message:
Logged In: YES
user_id=357491
r47072 has just the check for the subclass of Warning and
added your tests. Thanks, Andrew.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-22 09:13
Message:
Logged In: YES
user_id=357491
Turns out Armin's r47061 checkin fixed it; for some reason I
had not rebuilt. Doing a distclean and re-running tests
before committing the change.
--
Comment By: Brett Cannon (bcannon)
Date: 2006-06-22 09:05
Message:
Logged In: YES
user_id=357491
Well, the docs for warnings
(http://docs.python.org/dev/lib/warning-categories.html) say
that a category must subclass Warning. So I removed the
ClassType check entirely, and that causes test_exceptions to
segfault. Lovely.
I will try to look at this Friday.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-22 06:50
Message:
Logged In: YES
user_id=11375
Once the problem is fixed, the attached patch adds some
tests for warning parsing.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510580&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells
Bugs item #1465014, was opened at 2006-04-05 11:14 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&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 Submitted By: David Goodger (goodger) Assigned to: Andrew McNamara (andrewmcnamara) Summary: CSV regression in 2.5a1: multi-line cells Initial Comment: Running the attached csv_test.py under Python 2.4.2 (Windows XP SP1) produces: >c:\apps\python24\python.exe ./csv_test.py ['one', '2', 'three (line 1)\n(line 2)'] Note that the third item in the row contains a newline between "(line 1)" and "(line 2)". With Python 2.5a1, I get: >c:\apps\python25\python.exe ./csv_test.py ['one', '2', 'three (line 1)(line 2)'] Notice the missing newline, which is significant. The CSV module under 2.5a1 seems to lose data. -- >Comment By: David Goodger (goodger) Date: 2006-06-22 14:17 Message: Logged In: YES user_id=7733 I see what you're saying, but I disagree. In Python 2.4, csv.reader did not require newlines, but in Python 2.5 it does. That's a significant behavioral change. In the stdlib csv "Module Contents" docs for csv.reader, it says: "csvfile can be any object which supports the iterator protocol and returns a string each time its next method is called." It doesn't mention newline-terminated strings. In any case, the behavior is inconsistent: newlines are not required to terminate row-ending strings, but only strings which end inside cells split across rows. Why the discrepancy? -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-20 19:17 Message: Logged In: YES user_id=698599 I think your problem is with str.splitlines(), rather than the csv.reader: splitlines ate the newline. If you pass it True as an argument, it will retain the end-of-line character in the resulting strings. -- Comment By: David Goodger (goodger) Date: 2006-05-02 17:04 Message: Logged In: YES user_id=7733 Assigned to Andrew McNamara, since his change appears to have caused this regression (revision 38290 on Modules/_csv.c). -- Comment By: David Goodger (goodger) Date: 2006-05-02 16:58 Message: Logged In: YES user_id=7733 Further investigation has revealed that the regression only affects iterator I/O, not file I/O. The attached csv_test.py demonstrates. Run with Python 2.5 to get: results from file I/O: [['one', '2', 'three (line 1)\n(line 2)']] results from iterator I/O: [['one', '2', 'three (line 1)(line 2)']] -- Comment By: David Goodger (goodger) Date: 2006-04-05 11:44 Message: Logged In: YES user_id=7733 This bug seems to be a side effect of revision 38290 on Modules/_csv.c, which was prompted by bug 967934 (http://www.python.org/sf/967934). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&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-1510853 ] Add Windows 9x/ME (lack of) support information to README.TX
Feature Requests item #1510853, was opened at 2006-06-22 15:36 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=1510853&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: ajaksu (ajaksu2) Assigned to: Nobody/Anonymous (nobody) Summary: Add Windows 9x/ME (lack of) support information to README.TX Initial Comment: I suggest that following informative note should be added as a new sub-section in README.TXT's "Unsupported systems" (which really needs mentioning MacOS 9). The sub-section idea regards README.TXT only talking about already unsupported platforms. Motivation: As one of the few Windows 98 users that program in Python AND installed the 2.5 beta1, I was greeted by Tools/msi/msi.py's warning message. However, no further information was available in the downloaded release or in the online beta documents (What's New, release notes, etc.). Best regards, Daniel Diniz - Warning on install in Windows 98 and Windows Me Following Microsoft's closing of Extended Support for Windows 98/ME (July 11, 2006), Python 2.6 will stop supporting these platforms. Python development and maintainability becomes easier (and more reliable) when platform specific code targeting OSes with few users and no dedicated expert developers is taken out. The vendor also warns that the OS versions listed above "can expose customers to security risks" and recommends upgrade. For a more detailed discussion regarding no-longer-supported and resupporting platforms, as well as a list of platforms that became or will be unsupported, see PEP 11. Current behavior The Python 2.5 installer presents a warning message on those systems: "Warning: Python 2.5.x is the last Python release for Windows 9x." Suggested readings PEP 11: Removing support for little used platforms (http://www.python.org/dev/peps/pep-0011) End of support for Windows 98, Windows Me, and Windows XP Service Pack 1 (http://www.microsoft.com/windows/support/endofsupport.mspx) Copyright This document has been placed in the public domain. -- -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1510853&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-1510853 ] Add Windows 9x/ME (lack of) support information to README.TX
Feature Requests item #1510853, was opened at 2006-06-22 18:36 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1510853&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: ajaksu (ajaksu2) >Assigned to: A.M. Kuchling (akuchling) Summary: Add Windows 9x/ME (lack of) support information to README.TX Initial Comment: I suggest that following informative note should be added as a new sub-section in README.TXT's "Unsupported systems" (which really needs mentioning MacOS 9). The sub-section idea regards README.TXT only talking about already unsupported platforms. Motivation: As one of the few Windows 98 users that program in Python AND installed the 2.5 beta1, I was greeted by Tools/msi/msi.py's warning message. However, no further information was available in the downloaded release or in the online beta documents (What's New, release notes, etc.). Best regards, Daniel Diniz - Warning on install in Windows 98 and Windows Me Following Microsoft's closing of Extended Support for Windows 98/ME (July 11, 2006), Python 2.6 will stop supporting these platforms. Python development and maintainability becomes easier (and more reliable) when platform specific code targeting OSes with few users and no dedicated expert developers is taken out. The vendor also warns that the OS versions listed above "can expose customers to security risks" and recommends upgrade. For a more detailed discussion regarding no-longer-supported and resupporting platforms, as well as a list of platforms that became or will be unsupported, see PEP 11. Current behavior The Python 2.5 installer presents a warning message on those systems: "Warning: Python 2.5.x is the last Python release for Windows 9x." Suggested readings PEP 11: Removing support for little used platforms (http://www.python.org/dev/peps/pep-0011) End of support for Windows 98, Windows Me, and Windows XP Service Pack 1 (http://www.microsoft.com/windows/support/endofsupport.mspx) Copyright This document has been placed in the public domain. -- -- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-22 18:59 Message: Logged In: YES user_id=849994 Andrew? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1510853&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1508253 ] logging fileConfig swallows handler exception
Bugs item #1508253, was opened at 2006-06-18 19:33
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&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: Pending
Resolution: Works For Me
Priority: 5
Submitted By: tdir (tdir)
Assigned to: Vinay Sajip (vsajip)
Summary: logging fileConfig swallows handler exception
Initial Comment:
If you specify a handler such as a RotatingFileHandler
and the path you provide in the args specification
('option') is bad, config.fileConfig() catches the
exception and 'swallows' it. The result is later on,
when that handler is specified for a logger, you get an
exception saying there is no such handler. A much
friendlier behavior would be for fileConfig() to raise
an exception so the real cause of the problem can be
easily identified. Also, if there is a bug in the code
itself, it would also get swallowed in similar fashion.
In general, silently swallowing exceptions is rarely
the best choice IMHO.
Example ini with bad path (assuming /bad/path does not
exist):
[handler_defaultrotatingfile]
class=handlers.RotatingFileHandler
args=("/bad/path/logdir/my_log.log", 'w', 10, 10)
formatter=std
--
Comment By: Vinay Sajip (vsajip)
Date: 2006-06-22 16:37
Message:
Logged In: YES
user_id=308438
Can you give some more details? I don't get the problem: see
the transcript below.
ActivePython 2.4 Build 243 (ActiveState Corp.) based on
Python 2.4 (#60, Nov 30 2004, 09:34:21) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import logging.config
>>> logging.config.fileConfig("junk.ini")
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python\lib\logging\config.py", line 83, in fileConfig
handlers = _install_handlers(cp, formatters)
File "C:\Python\lib\logging\config.py", line 151, in
_install_handlers
h = apply(klass, args)
File "C:\Python\lib\logging\handlers.py", line 109, in
__init__
BaseRotatingHandler.__init__(self, filename, mode, encoding)
File "C:\Python\lib\logging\handlers.py", line 61, in __init__
logging.FileHandler.__init__(self, filename, mode, encoding)
File "C:\Python\lib\logging\__init__.py", line 770, in
__init__
stream = open(filename, mode)
IOError: [Errno 2] No such file or directory:
'/bad/path/junk.log'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1507224 ] sys.path issue if sys.prefix contains a colon
Bugs item #1507224, was opened at 2006-06-16 11:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) >Assigned to: Martin v. Löwis (loewis) Summary: sys.path issue if sys.prefix contains a colon Initial Comment: If you install python in a directory whose path contains a colon sys.path will be wrong, the installation directory will be split into two strings and both of them are added to sys.path. The following session demonstrates the problem: bump:~/src/python/:colon bob$ ./python.exe -c "import sys; print sys.path" 'import site' failed; use -v for traceback ['', '/usr/local/lib/python25.zip', '/Users/bob/src/python/', 'colon/../ Lib/', '/Users/bob/src/python/', 'colon/../Lib/plat-darwin', '/Users/bob/ src/python/', 'colon/../Lib/plat-mac', '/Users/bob/src/python/', 'colon/../ Lib/plat-mac/lib-scriptpackages', '/Users/bob/src/python/', 'colon/../ Lib/lib-tk', '/Users/bob/src/python/', 'colon/Modules'] -- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-22 19:08 Message: Logged In: YES user_id=849994 I don't know if something can be done here. A possibility would be, if one path segment doesn't exist, add the colon and the next segment and try again. Martin, do you have an opinion? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1507224&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1506758 ] If MAXFD too high, popen2/subprocess produce MemoryErrors
Bugs item #1506758, was opened at 2006-06-15 18:06 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506758&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 Submitted By: Peter Vetere (pav3901) >Assigned to: Peter à strand (astrand) Summary: If MAXFD too high, popen2/subprocess produce MemoryErrors Initial Comment: Both the subprocess and the popen2 modules use the range(...) function to iterate over and close inherited file descriptors when a subprocess is spawned. In the OS environment, it possible (using ulimit -n) to set SC_OPEN_MAX (and thus MAXFD in these modules) to a very high value. This can exhaust the limitations of the range() function, producing a MemoryError. The better thing to do would be to use xrange() instead. In particular, this bug occurs in subprocess._close_fds() and popen2._run_child(). -- >Comment By: Peter à strand (astrand) Date: 2006-06-22 22:32 Message: Logged In: YES user_id=344921 Patch 1506760 has been applied. -- Comment By: Peter Vetere (pav3901) Date: 2006-06-15 21:31 Message: Logged In: YES user_id=652852 I've submitted a patch against release24-maint for this bug: 1506760 -- Comment By: Peter Vetere (pav3901) Date: 2006-06-15 18:15 Message: Logged In: YES user_id=652852 I've submitted a patch against release24-maint for this bug: 1506760 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506758&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1510984 ] 2.5b1 windows won't install or admit failure
Bugs item #1510984, was opened at 2006-06-22 18:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5b1 windows won't install or admit failure Initial Comment: I downloaded the Windows 2.5b1, and then tried to install following all defaults. I had previously installed 2.5a2, and it is possible that I switched between "install for all users" and "install just for me". The install offered me a finish button, and no protest when I clicked it -- but after that, the shortcuts did not start python (nor did they protest; they just went into never neverland). Starting python at the command line did work. Reinstall with a repair did not fix anything. Uninstall, then uninstall 2.5a, then install on a "clean" system did work. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1510984&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1508253 ] logging fileConfig swallows handler exception
Bugs item #1508253, was opened at 2006-06-18 14:33
Message generated for change (Comment added) made by tdir
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&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: Works For Me
Priority: 5
Submitted By: tdir (tdir)
Assigned to: Vinay Sajip (vsajip)
Summary: logging fileConfig swallows handler exception
Initial Comment:
If you specify a handler such as a RotatingFileHandler
and the path you provide in the args specification
('option') is bad, config.fileConfig() catches the
exception and 'swallows' it. The result is later on,
when that handler is specified for a logger, you get an
exception saying there is no such handler. A much
friendlier behavior would be for fileConfig() to raise
an exception so the real cause of the problem can be
easily identified. Also, if there is a bug in the code
itself, it would also get swallowed in similar fashion.
In general, silently swallowing exceptions is rarely
the best choice IMHO.
Example ini with bad path (assuming /bad/path does not
exist):
[handler_defaultrotatingfile]
class=handlers.RotatingFileHandler
args=("/bad/path/logdir/my_log.log", 'w', 10, 10)
formatter=std
--
>Comment By: tdir (tdir)
Date: 2006-06-22 18:18
Message:
Logged In: YES
user_id=1541624
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit
(Intel)] on win32
ABOVE IS THE PYTHON SIGNON
I HAVE ALSO ATTACHED THE config.py FROM THE INSTALL. IT
CONTAINS NO _install_handlers
APPEARS TO BE A VERY DIFFERENT VERSION FROM YOURS
--
Comment By: Vinay Sajip (vsajip)
Date: 2006-06-22 11:37
Message:
Logged In: YES
user_id=308438
Can you give some more details? I don't get the problem: see
the transcript below.
ActivePython 2.4 Build 243 (ActiveState Corp.) based on
Python 2.4 (#60, Nov 30 2004, 09:34:21) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import logging.config
>>> logging.config.fileConfig("junk.ini")
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python\lib\logging\config.py", line 83, in fileConfig
handlers = _install_handlers(cp, formatters)
File "C:\Python\lib\logging\config.py", line 151, in
_install_handlers
h = apply(klass, args)
File "C:\Python\lib\logging\handlers.py", line 109, in
__init__
BaseRotatingHandler.__init__(self, filename, mode, encoding)
File "C:\Python\lib\logging\handlers.py", line 61, in __init__
logging.FileHandler.__init__(self, filename, mode, encoding)
File "C:\Python\lib\logging\__init__.py", line 770, in
__init__
stream = open(filename, mode)
IOError: [Errno 2] No such file or directory:
'/bad/path/junk.log'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells
Bugs item #1465014, was opened at 2006-04-06 01:14 Message generated for change (Comment added) made by andrewmcnamara You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&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 Submitted By: David Goodger (goodger) Assigned to: Andrew McNamara (andrewmcnamara) Summary: CSV regression in 2.5a1: multi-line cells Initial Comment: Running the attached csv_test.py under Python 2.4.2 (Windows XP SP1) produces: >c:\apps\python24\python.exe ./csv_test.py ['one', '2', 'three (line 1)\n(line 2)'] Note that the third item in the row contains a newline between "(line 1)" and "(line 2)". With Python 2.5a1, I get: >c:\apps\python25\python.exe ./csv_test.py ['one', '2', 'three (line 1)(line 2)'] Notice the missing newline, which is significant. The CSV module under 2.5a1 seems to lose data. -- >Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-23 10:27 Message: Logged In: YES user_id=698599 The previous behaviour caused considerable problems, particularly on platforms that did not use the unix line- ending conventions, or with files that originated on those platforms - users were finding mysterious newlines where they didn't expect them. Quoted fields exist to allow characters that would otherwise be considered part of the syntax to appear within the field. So yes, quoted fields are a special case, and necessarily so. The current behaviour puts the control back in the hands of the user of the module: if literal newlines are important within a field, they need to read their file in a way that preserves the newlines. The old behaviour would introduce spurious characters into quoted fields, with no way for the user to control that behaviour. I'm sorry that the change causes you problems. With a format that's as loosely defined as CSV, it's an unfortunate fact of life that there are going to be conflicting requirements. -- Comment By: David Goodger (goodger) Date: 2006-06-23 04:17 Message: Logged In: YES user_id=7733 I see what you're saying, but I disagree. In Python 2.4, csv.reader did not require newlines, but in Python 2.5 it does. That's a significant behavioral change. In the stdlib csv "Module Contents" docs for csv.reader, it says: "csvfile can be any object which supports the iterator protocol and returns a string each time its next method is called." It doesn't mention newline-terminated strings. In any case, the behavior is inconsistent: newlines are not required to terminate row-ending strings, but only strings which end inside cells split across rows. Why the discrepancy? -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-21 09:17 Message: Logged In: YES user_id=698599 I think your problem is with str.splitlines(), rather than the csv.reader: splitlines ate the newline. If you pass it True as an argument, it will retain the end-of-line character in the resulting strings. -- Comment By: David Goodger (goodger) Date: 2006-05-03 07:04 Message: Logged In: YES user_id=7733 Assigned to Andrew McNamara, since his change appears to have caused this regression (revision 38290 on Modules/_csv.c). -- Comment By: David Goodger (goodger) Date: 2006-05-03 06:58 Message: Logged In: YES user_id=7733 Further investigation has revealed that the regression only affects iterator I/O, not file I/O. The attached csv_test.py demonstrates. Run with Python 2.5 to get: results from file I/O: [['one', '2', 'three (line 1)\n(line 2)']] results from iterator I/O: [['one', '2', 'three (line 1)(line 2)']] -- Comment By: David Goodger (goodger) Date: 2006-04-06 01:44 Message: Logged In: YES user_id=7733 This bug seems to be a side effect of revision 38290 on Modules/_csv.c, which was prompted by bug 967934 (http://www.python.org/sf/967934). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503789 ] Cannot write source code in UTF16
Bugs item #1503789, was opened at 2006-06-09 17:38
Message generated for change (Comment added) made by tungwaiyip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot write source code in UTF16
Initial Comment:
I intend to create some source code in UTF16. I start
the file with the encoding declaration line:
--
# -*- coding: UTF-16LE -*-
print "Hello world"
--
Unfortunately Python does not decode it in UTF16 as
expected. I have found some language in PEP 0263 that
says "It does not include encodings which use two or
more bytes for all characters like e.g. UTF-16." While
I am disappointed. I accepted this limitation is
necessary to make keep the parser simple. So my first
complaint is this fact should be documented in
http://www.python.org/doc/ref/encodings.html
Then I tried to save the source code with BOM. I think
there should be no excuse not to decode it in UTF16 in
that case. Unfortunately Python does not support this
either.
Indeed the only way to get it work is to write the
encoding declaration line in ASCII and the rest of the
file in UTF16 (see u16_hybrid.py). Obviously most text
editor would not support this.
I come up with this because Microsoft adopt UTF16 in
various places.
--
>Comment By: Wai Yip Tung (tungwaiyip)
Date: 2006-06-22 18:31
Message:
Logged In: YES
user_id=561546
Turns out the code is already written but disabled. Simply
turning it on would work.
tokenizer.c(321):
#if 0
/* Disable support for UTF-16 BOMs until a decision
is made whether this needs to be supported. */
} else if (ch == 0xFE) {
ch = get_char(tok); if (ch != 0xFF) goto NON_
BOM;
if (!set_readline(tok, "utf-16-be")) return 0;
tok->decoding_state = -1;
} else if (ch == 0xFF) {
ch = get_char(tok); if (ch != 0xFE) goto NON_
BOM;
if (!set_readline(tok, "utf-16-le")) return 0;
tok->decoding_state = -1;
#endif
Executing an utf-16 text file with BOM file would work.
However if I also include an encoding declaration plus BOM
like this
# -*- coding: UTF-16le -*-
It would result in this error, for some logic in the code
that I couldn't sort out {tokenizer.c(291)}:
g:\bin\py_repos\python-svn\PCbuild>python_d.exe test16le.
py
File "test16le.py", line 1
SyntaxError: encoding problem: utf-8
If you need a justification for checking the UTF-16 BOM, it
is Microsoft. As an early adopter of unicode before UTF-8
is popularized, there is some software that generates UTF-
16 by default. Not a fatal issue. But I see no reason not
to support it either.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-06-13 10:06
Message:
Logged In: YES
user_id=21627
The parser code is in the Parser subdirectory. It would be
good if you could follow the existing parsing strategy, i.e.
convert the input to UTF-8, and then proceed with the normal
parsing procedure.
--
Comment By: Wai Yip Tung (tungwaiyip)
Date: 2006-06-13 09:27
Message:
Logged In: YES
user_id=561546
That sounds good. It is probably a good time to try out the
instructions to build Python on Windows.
http://groups.google.com/group/comp.lang.python/browse_
thread/thread/f09c49f77bf0a578/3e076bfcafb064cd?hl=en#3e076
bfcafb064cd
Can you point me to the relevant source code?
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-06-10 05:27
Message:
Logged In: YES
user_id=21627
Would you like to work on a patch?
There is, of course, a fairly obvious reason that this
doesn't work: nobody has put effort into making it work.
Personally, I suggest that you use some other encoding for
source code, e.g. UTF-8.
--
Comment By: Wai Yip Tung (tungwaiyip)
Date: 2006-06-09 17:39
Message:
Logged In: YES
user_id=561546
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells
Bugs item #1465014, was opened at 2006-04-05 11:14 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 9 Submitted By: David Goodger (goodger) Assigned to: Andrew McNamara (andrewmcnamara) Summary: CSV regression in 2.5a1: multi-line cells Initial Comment: Running the attached csv_test.py under Python 2.4.2 (Windows XP SP1) produces: >c:\apps\python24\python.exe ./csv_test.py ['one', '2', 'three (line 1)\n(line 2)'] Note that the third item in the row contains a newline between "(line 1)" and "(line 2)". With Python 2.5a1, I get: >c:\apps\python25\python.exe ./csv_test.py ['one', '2', 'three (line 1)(line 2)'] Notice the missing newline, which is significant. The CSV module under 2.5a1 seems to lose data. -- >Comment By: David Goodger (goodger) Date: 2006-06-22 23:13 Message: Logged In: YES user_id=7733 I didn't realize that the previous behavior was buggy; I thought that the current behavior was a side-effect. The 2.5 behavior did cause a small problem in Docutils, but it's already been fixed. I just wanted to ensure that no regression was creeping in to 2.5. Thanks for the explanation! Perhaps it could be added to the docs in some form? Marking the bug report closed. -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-22 20:27 Message: Logged In: YES user_id=698599 The previous behaviour caused considerable problems, particularly on platforms that did not use the unix line- ending conventions, or with files that originated on those platforms - users were finding mysterious newlines where they didn't expect them. Quoted fields exist to allow characters that would otherwise be considered part of the syntax to appear within the field. So yes, quoted fields are a special case, and necessarily so. The current behaviour puts the control back in the hands of the user of the module: if literal newlines are important within a field, they need to read their file in a way that preserves the newlines. The old behaviour would introduce spurious characters into quoted fields, with no way for the user to control that behaviour. I'm sorry that the change causes you problems. With a format that's as loosely defined as CSV, it's an unfortunate fact of life that there are going to be conflicting requirements. -- Comment By: David Goodger (goodger) Date: 2006-06-22 14:17 Message: Logged In: YES user_id=7733 I see what you're saying, but I disagree. In Python 2.4, csv.reader did not require newlines, but in Python 2.5 it does. That's a significant behavioral change. In the stdlib csv "Module Contents" docs for csv.reader, it says: "csvfile can be any object which supports the iterator protocol and returns a string each time its next method is called." It doesn't mention newline-terminated strings. In any case, the behavior is inconsistent: newlines are not required to terminate row-ending strings, but only strings which end inside cells split across rows. Why the discrepancy? -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-20 19:17 Message: Logged In: YES user_id=698599 I think your problem is with str.splitlines(), rather than the csv.reader: splitlines ate the newline. If you pass it True as an argument, it will retain the end-of-line character in the resulting strings. -- Comment By: David Goodger (goodger) Date: 2006-05-02 17:04 Message: Logged In: YES user_id=7733 Assigned to Andrew McNamara, since his change appears to have caused this regression (revision 38290 on Modules/_csv.c). -- Comment By: David Goodger (goodger) Date: 2006-05-02 16:58 Message: Logged In: YES user_id=7733 Further investigation has revealed that the regression only affects iterator I/O, not file I/O. The attached csv_test.py demonstrates. Run with Python 2.5 to get: results from file I/O: [['one', '2', 'three (line 1)\n(line 2)']] results from iterator I/O: [['one', '2', 'three (line 1)(line 2)']] -- Comment By: David Goodger (goodger) Date: 2006-04-05 11:44 Message: Logged In: YES user_id=7733 This bug seems to be a side effect of revision 38290 on Modules/_csv.c, which was prompted by bug 967934 (http://ww
[ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells
Bugs item #1465014, was opened at 2006-04-06 01:14 Message generated for change (Settings changed) made by andrewmcnamara You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Documentation Group: Python 2.5 >Status: Open Resolution: Rejected >Priority: 5 Submitted By: David Goodger (goodger) >Assigned to: Skip Montanaro (montanaro) Summary: CSV regression in 2.5a1: multi-line cells Initial Comment: Running the attached csv_test.py under Python 2.4.2 (Windows XP SP1) produces: >c:\apps\python24\python.exe ./csv_test.py ['one', '2', 'three (line 1)\n(line 2)'] Note that the third item in the row contains a newline between "(line 1)" and "(line 2)". With Python 2.5a1, I get: >c:\apps\python25\python.exe ./csv_test.py ['one', '2', 'three (line 1)(line 2)'] Notice the missing newline, which is significant. The CSV module under 2.5a1 seems to lose data. -- >Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-23 13:34 Message: Logged In: YES user_id=698599 Yep, your point about adding a comment to the documentation is fair. Skip, do you want to take my words and massage them into a form suitable for the docs? -- Comment By: David Goodger (goodger) Date: 2006-06-23 13:13 Message: Logged In: YES user_id=7733 I didn't realize that the previous behavior was buggy; I thought that the current behavior was a side-effect. The 2.5 behavior did cause a small problem in Docutils, but it's already been fixed. I just wanted to ensure that no regression was creeping in to 2.5. Thanks for the explanation! Perhaps it could be added to the docs in some form? Marking the bug report closed. -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-23 10:27 Message: Logged In: YES user_id=698599 The previous behaviour caused considerable problems, particularly on platforms that did not use the unix line- ending conventions, or with files that originated on those platforms - users were finding mysterious newlines where they didn't expect them. Quoted fields exist to allow characters that would otherwise be considered part of the syntax to appear within the field. So yes, quoted fields are a special case, and necessarily so. The current behaviour puts the control back in the hands of the user of the module: if literal newlines are important within a field, they need to read their file in a way that preserves the newlines. The old behaviour would introduce spurious characters into quoted fields, with no way for the user to control that behaviour. I'm sorry that the change causes you problems. With a format that's as loosely defined as CSV, it's an unfortunate fact of life that there are going to be conflicting requirements. -- Comment By: David Goodger (goodger) Date: 2006-06-23 04:17 Message: Logged In: YES user_id=7733 I see what you're saying, but I disagree. In Python 2.4, csv.reader did not require newlines, but in Python 2.5 it does. That's a significant behavioral change. In the stdlib csv "Module Contents" docs for csv.reader, it says: "csvfile can be any object which supports the iterator protocol and returns a string each time its next method is called." It doesn't mention newline-terminated strings. In any case, the behavior is inconsistent: newlines are not required to terminate row-ending strings, but only strings which end inside cells split across rows. Why the discrepancy? -- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-21 09:17 Message: Logged In: YES user_id=698599 I think your problem is with str.splitlines(), rather than the csv.reader: splitlines ate the newline. If you pass it True as an argument, it will retain the end-of-line character in the resulting strings. -- Comment By: David Goodger (goodger) Date: 2006-05-03 07:04 Message: Logged In: YES user_id=7733 Assigned to Andrew McNamara, since his change appears to have caused this regression (revision 38290 on Modules/_csv.c). -- Comment By: David Goodger (goodger) Date: 2006-05-03 06:58 Message: Logged In: YES user_id=7733 Further investigation has revealed that the regression only affects iterator I/O, not file I/O. The attached csv_test.py demonstrates. Run with Python 2.5 to get: results from file I/O: [['one', '2', 'three (line 1)\n(line 2)']] results fro
[ python-Bugs-1508253 ] logging fileConfig swallows handler exception
Bugs item #1508253, was opened at 2006-06-18 19:33
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&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
Submitted By: tdir (tdir)
Assigned to: Vinay Sajip (vsajip)
Summary: logging fileConfig swallows handler exception
Initial Comment:
If you specify a handler such as a RotatingFileHandler
and the path you provide in the args specification
('option') is bad, config.fileConfig() catches the
exception and 'swallows' it. The result is later on,
when that handler is specified for a logger, you get an
exception saying there is no such handler. A much
friendlier behavior would be for fileConfig() to raise
an exception so the real cause of the problem can be
easily identified. Also, if there is a bug in the code
itself, it would also get swallowed in similar fashion.
In general, silently swallowing exceptions is rarely
the best choice IMHO.
Example ini with bad path (assuming /bad/path does not
exist):
[handler_defaultrotatingfile]
class=handlers.RotatingFileHandler
args=("/bad/path/logdir/my_log.log", 'w', 10, 10)
formatter=std
--
>Comment By: Vinay Sajip (vsajip)
Date: 2006-06-23 06:10
Message:
Logged In: YES
user_id=308438
Ok, then the bug has already been fixed (or superseded by
changes to the code).
I'll close this report: if you want to use the latest code,
just download it from the Python subversion repository. It
should run without problems in 2.4.2.
--
Comment By: tdir (tdir)
Date: 2006-06-22 23:18
Message:
Logged In: YES
user_id=1541624
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit
(Intel)] on win32
ABOVE IS THE PYTHON SIGNON
I HAVE ALSO ATTACHED THE config.py FROM THE INSTALL. IT
CONTAINS NO _install_handlers
APPEARS TO BE A VERY DIFFERENT VERSION FROM YOURS
--
Comment By: Vinay Sajip (vsajip)
Date: 2006-06-22 16:37
Message:
Logged In: YES
user_id=308438
Can you give some more details? I don't get the problem: see
the transcript below.
ActivePython 2.4 Build 243 (ActiveState Corp.) based on
Python 2.4 (#60, Nov 30 2004, 09:34:21) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import logging.config
>>> logging.config.fileConfig("junk.ini")
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python\lib\logging\config.py", line 83, in fileConfig
handlers = _install_handlers(cp, formatters)
File "C:\Python\lib\logging\config.py", line 151, in
_install_handlers
h = apply(klass, args)
File "C:\Python\lib\logging\handlers.py", line 109, in
__init__
BaseRotatingHandler.__init__(self, filename, mode, encoding)
File "C:\Python\lib\logging\handlers.py", line 61, in __init__
logging.FileHandler.__init__(self, filename, mode, encoding)
File "C:\Python\lib\logging\__init__.py", line 770, in
__init__
stream = open(filename, mode)
IOError: [Errno 2] No such file or directory:
'/bad/path/junk.log'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-853506 ] IP6 address parsing i sgmllib
Bugs item #853506, was opened at 2003-12-03 14:15 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853506&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 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: IP6 address parsing i sgmllib Initial Comment: The sgmllib.attrfind regex excludes [ and ]. http://www.ietf.org/rfc/rfc2732.txt uses these in the host portion to indicate that an address is IP6 rather than IP4. http://[1080::8:800:200C:417A]/foo RFC 2732 is referenced as normative by the xml:base module. I grouped the issue as 2.3, on the assumption that it isn't a bug until IP6 is used. -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-23 02:13 Message: Logged In: YES user_id=3066 Fixed on the trunk (2.5b2) in revision 47080; on the release24-maint branch (2.4.4) in revision 47081. -- Comment By: Jim Jewett (jimjjewett) Date: 2004-02-20 18:46 Message: Logged In: YES user_id=764593 Assigned to 2.3 when that was development. Moved to 2.4 now, still on the assumption that the bug won't hit with real data until IP6 is more common. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853506&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-745002 ] <> in attrs in sgmllib not handled
Bugs item #745002, was opened at 2003-05-28 12:30 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745002&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: Samuel Bayer (sambayer) Assigned to: Nobody/Anonymous (nobody) Summary: <> in attrs in sgmllib not handled Initial Comment: Hi folks - This bug is noted in the source code for sgmllib.py, and it finally bit me. If you feed the SGMLParser class text such asfoo thewill be processed as a tag, as well as being recognized as part of the attribute. This is because of the way the end index for the opening tag is computed. As far as I can tell from the HTML 4.01 specification, this is legal. The case I encountered was in a value of an "onmouseover" attribute, which was a Javascript call which contained HTML text as one of its arguments. The problem is in SGMLParser.parse_starttag, which attempts to compute the end of the opening tag with a simple regexp [<>], and uses this index even when the attributes have passed it. There's no real need to check this regexp in advance, as far as I can tell. I've attached my proposed modification of SGMLParser.parse_starttag; I've tested this change in 2.2.1, but there are no relevant differences between 2.2.1 and the head of the CVS tree for this method. No guarantees of correctness, but it works on the examples I've tested it on. Cheers - Sam Bayer w_endbracket = re.compile("\s*[<>]") class SGMLParser: # Internal -- handle starttag, return length or -1 if not terminated def parse_starttag(self, i): self.__starttag_text = None start_pos = i rawdata = self.rawdata if shorttagopen.match(rawdata, i): # SGML shorthand: data # XXX Can data contain &... (entity or char refs)? # XXX Can data contain < or > (tag characters)? # XXX Can there be whitespace before the first /? match = shorttag.match(rawdata, i) if not match: return -1 tag, data = match.group(1, 2) self.__starttag_text = '<%s/' % tag tag = tag.lower() k = match.end(0) self.finish_shorttag(tag, data) self.__starttag_text = rawdata[start_pos:match.end(1) + 1] return k # Now parse the data between i+1 and the end of the tag into a tag and attrs attrs = [] if rawdata[i:i+2] == '<>': # SGML shorthand: <> ==k = i + 1 tag = self.lasttag else: match = tagfind.match(rawdata, i+1) if not match: self.error('unexpected call to parse_starttag') k = match.end(0) tag = rawdata[i+1:k].lower() self.lasttag = tag while w_endbracket.match(rawdata, k) is None: match = attrfind.match(rawdata, k) if not match: break attrname, rest, attrvalue = match.group(1, 2, 3) if not rest: attrvalue = attrname elif attrvalue[:1] == '\'' == attrvalue[-1:] or \ attrvalue[:1] == '"' == attrvalue[-1:]: attrvalue = attrvalue[1:-1] attrs.append((attrname.lower(), attrvalue)) k = match.end(0) match = endbracket.search(rawdata, k) if not match: return -1 j = match.start(0) if rawdata[j] == '>': j = j+1 self.__starttag_text = rawdata[start_pos:j] self.finish_starttag(tag, attrs) return j -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-23 02:16 Message: Logged In: YES user_id=3066 See also: http://www.python.org/sf/803422 -- Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 11:23 Message: Logged In: YES user_id=21627 I see. Can you please attach the fix as a context or unified diff to this report? I can't follow your changes above at all. -- Comment By: Samuel Bayer (sambayer) Date: 2003-06-14 09:35 Message: Logged In: YES user_id=40146 I'm reporting it because (a) it's not in the bug queue, and (b) it's broken The fact that it's noted as a bug in the source code doesn't strike me as relevant. Especially since I attached a fix. -- Comment By: Martin v. Löwis (loewis) Date
