[ python-Feature Requests-1777412 ] Python's strftime dislikes years before 1900
Feature Requests item #1777412, was opened at 2007-08-20 05:36
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1777412&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
Private: No
Submitted By: Benno Rice (benno)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python's strftime dislikes years before 1900
Initial Comment:
Python 2.5 (r25:51918, Sep 19 2006, 08:49:13)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.date(1876, 2, 3).strftime('%Y-%m-%d')
Traceback (most recent call last):
File "", line 1, in
ValueError: year=1876 is before 1900; the datetime strftime() methods require
year >= 1900
Apparently this is due to platform-specific weirdnesses in implementations of
strftime. It is still very annoying however. Perhaps a good implementation of
strftime could be found and incorporated into Python itself?
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-08-21 10:15
Message:
Logged In: YES
user_id=21627
Originator: NO
This is not a bug report, but a feature request. Python works correctly
as-is.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1777412&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1776160 ] Buffer overflow when listing deeply nested directory
Bugs item #1776160, was opened at 2007-08-17 13:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj�rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overflow when listing deeply nested directory Initial Comment: This code: import os import os.path TARGET='C:/code/python/foo' base = TARGET for x in range(200): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base Produces a TypeError (buffer overflow) when run on a to deeply nested directory for windows to handle: .. more output here.. C:code/python/foo\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.p ng\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png Traceback (most recent call last): File "killdir.py", line 6, in subdirs = os.listdir(base) TypeError: listdir() argument 1 must be (buffer overflow), not str -- >Comment By: Martin v. Löwis (loewis) Date: 2007-08-21 10:18 Message: Logged In: YES user_id=21627 Originator: NO To rephrase Skip's comment: Can you please report what operating system and Python version you are using? -- Comment By: Skip Montanaro (montanaro) Date: 2007-08-18 13:38 Message: Logged In: YES user_id=44345 Originator: NO Worked as expected for me on Mac OS X 10.4.10 running from the trunk (you didn't mention what version you were using). In ~/tmp/deep I created a maximally nested directory tree from the shell like so: cd /Users/skip/tmp/deep for i in `range 1000` ; do x=`printf %04d $i` echo $x mkdir $x cd $x done where the range command is analogous to Python's range builtin: % range 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 The for loop barfed after making directory 0205. In Python I then executed these statements: import os.path base = "/Users/skip/tmp/deep" for x in range(210): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base This went until it got to dir 0200 where it raised an OSError: [Errno 63] File name too long: '/Users/skip/tmp/deep//0001/.../0199/0200' which stands to reason since base was 1025 characters long at that point. MAXPATHLEN is defined to be 1024 on my system, so the OSError is to be expected. Skip -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed
Bugs item #1772916, was opened at 2007-08-13 10:15
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&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: lplatypus (ldeller)
>Assigned to: Fredrik Lundh (effbot)
Summary: xmlrpclib crash when PyXML installed
Initial Comment:
The xmlrpclib module in the standard library will use a 3rd party C extension
called "sgmlop" if it is present.
The last version of PyXML (0.8.4) includes this module, but it causes crashes
with Python 2.5 due to the use of mismatched memory allocation/deallocation
functions (PyObject_NEW and PyMem_DEL).
It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained.
Therefore sgmlop support should be removed from xmlrpclib.
(In case you're wondering why anyone would install PyXML with Python 2.5
anyway: there are still some 3rd party libraries which depend upon PyXML, such
as ZSI and twisted).
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-08-21 10:27
Message:
Logged In: YES
user_id=21627
Originator: NO
Fredrik, can you please comment? If not, unassign.
--
Comment By: lplatypus (ldeller)
Date: 2007-08-14 08:23
Message:
Logged In: YES
user_id=1534394
Originator: YES
Yes the standalone sgmlop-1.1.1 looks fine: in its sgmlop.c I can see that
matching allocator and deallocator functions are used.
I installed PyXML-0.8.4 from source ("python setup.py install" on Win32
which picked up the C compiler from MSVS7.1). The cause of the problem is
quite visible in the PyXML source code (see that PyObject_NEW and PyMem_DEL
are used together):
http://pyxml.cvs.sourceforge.net/pyxml/xml/extensions/sgmlop.c?view=markup
Interestingly PyXML-0.8.4 was released more recently than sgmlop-1.1.1. I
guess they weren't keeping in sync with each other.
--
Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-08-14 05:32
Message:
Logged In: YES
user_id=1115903
Originator: NO
I tried out xmlrpclib on the trunk (2.6) with sgmlop-1.1.1 and it works
just fine. At the moment I don't have time to try out PyXML, but seeing
that the most recent sgmlop works with xmlrpclib makes me lean towards not
removing sgmlop support (not that I have a say about it, but still).
How did you install PyXML? If it wasn't from source or from an installer
compiled for 2.5, that might be a problem. If PyXML installed from source
or compiled for 2.5 still causes this problem, it could be that it needs to
be updated to the current sgmlop.
--
Comment By: lplatypus (ldeller)
Date: 2007-08-14 03:07
Message:
Logged In: YES
user_id=1534394
Originator: YES
Choice of XML parser is an implementation detail of xmlrpclib not visible
to users of the module. This change would not affect the behaviour of
xmlrpclib (other than to fix a crash introduced in Python 2.5). Does this
mean that a DeprecationWarning would not be necessary? Does it also mean
that the fix might qualify for the maintenance branch?
Adding a DeprecationWarning in 2.6 without removing use of sgmlop is
pointless, because the DeprecationWarning would be followed by a process
crash anyway.
--
Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-08-13 13:06
Message:
Logged In: YES
user_id=1115903
Originator: NO
I'm assuming that stuff won't be removed from 2.5 because it's in
maintenance, so should this be removed or changed to raise a deprecation
warning in 2.6?
As an aside, how about removing references to _xmlrpclib (which appears to
have been removed long ago) as well?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1778376 ] Segfault.
Bugs item #1778376, was opened at 2007-08-21 10:08
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=1778376&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Maciek Fijalkowski (fijal)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault.
Initial Comment:
On linux box this piece of code segfaults (CPy 2.5.1)
while 1:
f = open("/tmp/dupa", "w")
thread.start_new_thread(f.close, ())
f.close()
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778376&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed
Bugs item #1772916, was opened at 2007-08-13 10:15
Message generated for change (Comment added) made by effbot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&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: lplatypus (ldeller)
>Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib crash when PyXML installed
Initial Comment:
The xmlrpclib module in the standard library will use a 3rd party C extension
called "sgmlop" if it is present.
The last version of PyXML (0.8.4) includes this module, but it causes crashes
with Python 2.5 due to the use of mismatched memory allocation/deallocation
functions (PyObject_NEW and PyMem_DEL).
It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained.
Therefore sgmlop support should be removed from xmlrpclib.
(In case you're wondering why anyone would install PyXML with Python 2.5
anyway: there are still some 3rd party libraries which depend upon PyXML, such
as ZSI and twisted).
--
>Comment By: Fredrik Lundh (effbot)
Date: 2007-08-21 10:43
Message:
Logged In: YES
user_id=38376
Originator: NO
I don't really have an opinion here; the best solution would of course be
to find someone that cares enough about PyXML to cut a bugfix release, it's
probably easiest to just remove it (or disable, with a note that it can be
re-enabled if you have a stable version of sgmlop). I'm tempted to suggest
removing SlowParser as well, but there might be some hackers on very small
devices that rely on that one.
(Ideally, someone should sit down and rewrite the Unmarshaller to use
xml.etree.cElementTree's iterparse function instead. Contact me if you're
interested).
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-08-21 10:27
Message:
Logged In: YES
user_id=21627
Originator: NO
Fredrik, can you please comment? If not, unassign.
--
Comment By: lplatypus (ldeller)
Date: 2007-08-14 08:23
Message:
Logged In: YES
user_id=1534394
Originator: YES
Yes the standalone sgmlop-1.1.1 looks fine: in its sgmlop.c I can see that
matching allocator and deallocator functions are used.
I installed PyXML-0.8.4 from source ("python setup.py install" on Win32
which picked up the C compiler from MSVS7.1). The cause of the problem is
quite visible in the PyXML source code (see that PyObject_NEW and PyMem_DEL
are used together):
http://pyxml.cvs.sourceforge.net/pyxml/xml/extensions/sgmlop.c?view=markup
Interestingly PyXML-0.8.4 was released more recently than sgmlop-1.1.1. I
guess they weren't keeping in sync with each other.
--
Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-08-14 05:32
Message:
Logged In: YES
user_id=1115903
Originator: NO
I tried out xmlrpclib on the trunk (2.6) with sgmlop-1.1.1 and it works
just fine. At the moment I don't have time to try out PyXML, but seeing
that the most recent sgmlop works with xmlrpclib makes me lean towards not
removing sgmlop support (not that I have a say about it, but still).
How did you install PyXML? If it wasn't from source or from an installer
compiled for 2.5, that might be a problem. If PyXML installed from source
or compiled for 2.5 still causes this problem, it could be that it needs to
be updated to the current sgmlop.
--
Comment By: lplatypus (ldeller)
Date: 2007-08-14 03:07
Message:
Logged In: YES
user_id=1534394
Originator: YES
Choice of XML parser is an implementation detail of xmlrpclib not visible
to users of the module. This change would not affect the behaviour of
xmlrpclib (other than to fix a crash introduced in Python 2.5). Does this
mean that a DeprecationWarning would not be necessary? Does it also mean
that the fix might qualify for the maintenance branch?
Adding a DeprecationWarning in 2.6 without removing use of sgmlop is
pointless, because the DeprecationWarning would be followed by a process
crash anyway.
--
Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-08-13 13:06
Message:
Logged In: YES
user_id=1115903
Originator: NO
I'm assuming that stuff won't be removed from 2.5 because it's in
maintenance, so should this be removed or changed to raise a deprecation
warning in 2.6?
As an aside, how about removing references to _xmlrpclib (which appears to
have been removed long ago) as well?
--
You can respon
[ python-Bugs-1772788 ] chr(128) in u'only ascii' -> TypeError with misleading msg
Bugs item #1772788, was opened at 2007-08-13 00:54 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772788&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Laukkanen (laukpe) Assigned to: Nobody/Anonymous (nobody) Summary: chr(128) in u'only ascii' -> TypeError with misleading msg Initial Comment: A test using in format "chr(x) in " raises a TypeError if "x" is in range 128-255 (i.e. non-ascii) and string is unicode. This happens even if the unicode string contains only ascii data as the example below demonstrates. Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> chr(127) in 'hello' False >>> chr(128) in 'hello' False >>> chr(127) in u'hi' False >>> chr(128) in u'hi' Traceback (most recent call last): File "", line 1, in TypeError: 'in ' requires string as left operand This can cause pretty nasty and hard-to-debug bugs in code using "in " format if e.g. user provided data is converted to unicode internally. Most other string operations work nicely between normal and unicode strings and I'd say simply returning False in this situation would be ok too. Issuing a warning similarly as below might be a good idea also. >>> chr(128) == u'' __main__:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal Finally, the error message is somewhat misleading since the left operand is definitely a string. >>> type(chr(128)) A real life example of code where this problem exist is telnetlib. I'll submit a separate bug about it as that problem can obviously be fixed in the library itself. -- >Comment By: Fredrik Lundh (effbot) Date: 2007-08-21 10:48 Message: Logged In: YES user_id=38376 Originator: NO "Most other string operations work nicely between normal and unicode strings" Nope. You *always* get errors if you mix Unicode with NON-ASCII data (unless you've messed up the system's default encoding, which is a bad thing to do if you care about portability). Some examples: >>> chr(128) + u"foo" UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128) >>> u"foo".find(chr(128)) UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128) etc. If there's a bug here, it's that you get a TypeError instead of a ValueError subclass. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772788&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1776160 ] Buffer overflow when listing deeply nested directory
Bugs item #1776160, was opened at 2007-08-17 13:24 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj�rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overflow when listing deeply nested directory Initial Comment: This code: import os import os.path TARGET='C:/code/python/foo' base = TARGET for x in range(200): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base Produces a TypeError (buffer overflow) when run on a to deeply nested directory for windows to handle: .. more output here.. C:code/python/foo\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.p ng\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png Traceback (most recent call last): File "killdir.py", line 6, in subdirs = os.listdir(base) TypeError: listdir() argument 1 must be (buffer overflow), not str -- >Comment By: Bj�rn Lindqvist (sonderblade) Date: 2007-08-21 10:49 Message: Logged In: YES user_id=51702 Originator: YES Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 MS Windows XP, Version 5.1, SP2 -- Comment By: Martin v. Löwis (loewis) Date: 2007-08-21 10:18 Message: Logged In: YES user_id=21627 Originator: NO To rephrase Skip's comment: Can you please report what operating system and Python version you are using? -- Comment By: Skip Montanaro (montanaro) Date: 2007-08-18 13:38 Message: Logged In: YES user_id=44345 Originator: NO Worked as expected for me on Mac OS X 10.4.10 running from the trunk (you didn't mention what version you were using). In ~/tmp/deep I created a maximally nested directory tree from the shell like so: cd /Users/skip/tmp/deep for i in `range 1000` ; do x=`printf %04d $i` echo $x mkdir $x cd $x done where the range command is analogous to Python's range builtin: % range 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 The for loop barfed after making directory 0205. In Python I then executed these statements: import os.path base = "/Users/skip/tmp/deep" for x in range(210): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base This went until it got to dir 0200 where it raised an OSError: [Errno 63] File name too long: '/Users/skip/tmp/deep//0001/.../0199/0200' which stands to reason since base was 1025 characters long at that point. MAXPATHLEN is defined to be 1024 on my system, so the OSError is to be expected. Skip -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1778376 ] Segfault closing a file from concurrent threads
Bugs item #1778376, was opened at 2007-08-21 08:08
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778376&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Maciek Fijalkowski (fijal)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Segfault closing a file from concurrent threads
Initial Comment:
On linux box this piece of code segfaults (CPy 2.5.1)
while 1:
f = open("/tmp/dupa", "w")
thread.start_new_thread(f.close, ())
f.close()
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778376&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772788 ] chr(128) in u'only ascii' -> TypeError with misleading msg
Bugs item #1772788, was opened at 2007-08-13 01:54 Message generated for change (Comment added) made by laukpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772788&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Laukkanen (laukpe) Assigned to: Nobody/Anonymous (nobody) Summary: chr(128) in u'only ascii' -> TypeError with misleading msg Initial Comment: A test using in format "chr(x) in " raises a TypeError if "x" is in range 128-255 (i.e. non-ascii) and string is unicode. This happens even if the unicode string contains only ascii data as the example below demonstrates. Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> chr(127) in 'hello' False >>> chr(128) in 'hello' False >>> chr(127) in u'hi' False >>> chr(128) in u'hi' Traceback (most recent call last): File "", line 1, in TypeError: 'in ' requires string as left operand This can cause pretty nasty and hard-to-debug bugs in code using "in " format if e.g. user provided data is converted to unicode internally. Most other string operations work nicely between normal and unicode strings and I'd say simply returning False in this situation would be ok too. Issuing a warning similarly as below might be a good idea also. >>> chr(128) == u'' __main__:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal Finally, the error message is somewhat misleading since the left operand is definitely a string. >>> type(chr(128)) A real life example of code where this problem exist is telnetlib. I'll submit a separate bug about it as that problem can obviously be fixed in the library itself. -- >Comment By: Pekka Laukkanen (laukpe) Date: 2007-08-21 17:03 Message: Logged In: YES user_id=1379331 Originator: YES Fredrik, you are obviously correct that most operations between normal and unicode strings don't work if the normal string contains non-ascii data. I still do think that a UnicodeWarning like you get from "chr(128) == u'foo'" would be nicer than an exception and prevent problems like the one in telnetlib [1]. If an exception is raised I don't care too much about its type but a better message would make debugging possible problems easier. [1] https://sourceforge.net/tracker/index.php?func=detail&aid=1772794&group_id=5470&atid=105470 -- Comment By: Fredrik Lundh (effbot) Date: 2007-08-21 11:48 Message: Logged In: YES user_id=38376 Originator: NO "Most other string operations work nicely between normal and unicode strings" Nope. You *always* get errors if you mix Unicode with NON-ASCII data (unless you've messed up the system's default encoding, which is a bad thing to do if you care about portability). Some examples: >>> chr(128) + u"foo" UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128) >>> u"foo".find(chr(128)) UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128) etc. If there's a bug here, it's that you get a TypeError instead of a ValueError subclass. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772788&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777458 ] glob doesn't return unicode with unicode parameter
Bugs item #1777458, was opened at 2007-08-20 12:38 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777458&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: Grzegorz Adam Hankiewicz (gradha) Assigned to: Nobody/Anonymous (nobody) Summary: glob doesn't return unicode with unicode parameter Initial Comment: Unless I'm not understanding a previous bug report, I see this is a regression of http://sourceforge.net/tracker/index.php?func=detail&aid=1001604&group_id=5470&atid=305470. Here's an interactive session with 2.5.1 on WXP: In [1]: import sys In [2]: sys.version Out[2]: '2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)]' In [3]: import glob In [4]: glob.glob(u"*txt") Out[4]: ['hola.txt', 'ma\xf1ana.txt'] In [5]: glob.glob(u"./*txt") Out[5]: [u'.\\hola.txt', u'.\\ma\xf1ana.txt'] -- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-21 23:01 Message: Logged In: YES user_id=942711 Originator: NO This seems very much windows specific (someone needs to test on mac/other os as well). On linux, verified that glob unicode-in, unicode-out works fine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1777458&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-839151 ] attempt to access sys.argv when it doesn\'t exist
Bugs item #839151, was opened at 2003-11-10 02:56 Message generated for change (Comment added) made by ngrover You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839151&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Bram Moolenaar (vimboss) Assigned to: Georg Brandl (gbrandl) Summary: attempt to access sys.argv when it doesn\'t exist Initial Comment: When using Python as an extension to another program, giving a warning message attempts to access sys.argv while it doesn't exist. The problem can be reproduced with Vim when compiled with Python 2.3. Use these two commands: :py import sys :py print sys.maxint + 1 The problem is caused by the warnings module. In line 53 it accesses sys.argv[0], but for an embedded interpreter this doesn't exist. The suggested fix does an explicit test for the existence of sys.argv. That seems to be the cleanest solution to me. This problem also existed in Python 2.2. I didn't try other versions. -- Comment By: Nishkar Grover (ngrover) Date: 2007-08-21 18:29 Message: Logged In: YES user_id=1656248 Originator: NO In addition to catching AttributeError in case sys.argv doesn't exist, this should also catch IndexError and TypeError in case sys.argv is an empty list or it is not even a list at all. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-06-26 15:55 Message: Logged In: YES user_id=1188172 Thanks for the report; this is fixed as of Lib/warnings.py r1.27, r1.24.2.2. -- Comment By: Nobody/Anonymous (nobody) Date: 2003-11-18 21:23 Message: Logged In: NO Much simplier test: >>> import sys >>> del sys.argv >>> sys.maxint+1 Traceback (most recent call last): File "", line 1, in ? File "D:\development\python22\lib\warnings.py", line 38, in warn filename = sys.argv[0] AttributeError: 'module' object has no attribute 'argv' -- Comment By: Nobody/Anonymous (nobody) Date: 2003-11-18 21:22 Message: Logged In: NO Much simplier test: >>> import sys >>> del sys.argv >>> sys.maxint+1 Traceback (most recent call last): File " ", line 1, in ? File "D:\development\python22\lib\warnings.py", line 38, in warn filename = sys.argv[0] AttributeError: 'module' object has no attribute 'argv' -- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-10 07:02 Message: Logged In: YES user_id=33168 Just to provide a reference, 839200 was a duplicate of this report. I closed 839200. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839151&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1776160 ] Buffer overflow when listing deeply nested directory
Bugs item #1776160, was opened at 2007-08-17 13:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj�rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overflow when listing deeply nested directory Initial Comment: This code: import os import os.path TARGET='C:/code/python/foo' base = TARGET for x in range(200): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base Produces a TypeError (buffer overflow) when run on a to deeply nested directory for windows to handle: .. more output here.. C:code/python/foo\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.p ng\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png Traceback (most recent call last): File "killdir.py", line 6, in subdirs = os.listdir(base) TypeError: listdir() argument 1 must be (buffer overflow), not str -- >Comment By: Martin v. Löwis (loewis) Date: 2007-08-22 07:56 Message: Logged In: YES user_id=21627 Originator: NO Can you please explain what specifically you consider a bug here? I can see that the error message is confusing, so it could be improved. However, there is nothing we can do to make the error go away. The Microsoft C library simply does not support file names longer than MAX_PATH; you have to use Unicode file names to go beyond this limit. -- Comment By: Bj�rn Lindqvist (sonderblade) Date: 2007-08-21 10:49 Message: Logged In: YES user_id=51702 Originator: YES Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 MS Windows XP, Version 5.1, SP2 -- Comment By: Martin v. Löwis (loewis) Date: 2007-08-21 10:18 Message: Logged In: YES user_id=21627 Originator: NO To rephrase Skip's comment: Can you please report what operating system and Python version you are using? -- Comment By: Skip Montanaro (montanaro) Date: 2007-08-18 13:38 Message: Logged In: YES user_id=44345 Originator: NO Worked as expected for me on Mac OS X 10.4.10 running from the trunk (you didn't mention what version you were using). In ~/tmp/deep I created a maximally nested directory tree from the shell like so: cd /Users/skip/tmp/deep for i in `range 1000` ; do x=`printf %04d $i` echo $x mkdir $x cd $x done where the range command is analogous to Python's range builtin: % range 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 The for loop barfed after making directory 0205. In Python I then executed these statements: import os.path base = "/Users/skip/tmp/deep" for x in range(210): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base This went until it got to dir 0200 where it raised an OSError: [Errno 63] File name too long: '/Users/skip/tmp/deep//0001/.../0199/0200' which stands to reason since base was 1025 characters long at that point. MAXPATHLEN is defined to be 1024 on my system, so the OSError is to be expected. Skip -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1776160&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1778207 ] rounding inconsisntency using string formatting
Bugs item #1778207, was opened at 2007-08-21 01:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778207&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.4 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Jim Hurlburt (jim_hurlburt) Assigned to: Nobody/Anonymous (nobody) Summary: rounding inconsisntency using string formatting Initial Comment: Sirs: Using python to generate a text file for transfer of data between systems, I seem to be getting inconsistent rounding results using a text formatting string Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 print "%9.4f" % (229.0 * .325,)-> 74.4250 correct print "%9.2f" % (round(74.425, 2),)-> 74.43 correct print "%9.2f" % (74.425,) -> 74.42 wrong print "%9.2f" % (167.255,) ->167.26 correct print "%9.2f" % (167.2551,)->167.26 correct print "%9.2f" % (167.2549,)->167.25 correct It appears as if the string formatting code is a bit flakey. Perhaps working in binary with too small a precision? For a bit I thought it might be "Round even up, odd down at the .005 break, but that doesn't appear to be the case. Now that I know it's there, I can do a workaround. Seems as if it deserves a fix or at least a document notation of the problem. Thanks in advance, Jim Hurlburt Atrium Windows and Doors Yakima, WA -- >Comment By: Martin v. Löwis (loewis) Date: 2007-08-22 08:01 Message: Logged In: YES user_id=21627 Originator: NO As marketdickinson explains, this is not a bug - at least the line you consider "wrong" does not show a bug. 74.425 is indeed smaller than 74+425/1000, so it's correct that rounding rounds down. As for documentation, please take a look at http://www.python.org/doc/faq/general/#why-are-floating-point-calculations-so-inaccurate Closing as invalid. -- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-21 03:02 Message: Logged In: YES user_id=703403 Originator: NO This isn't really a bug---it's just one of those unavoidable things that happens when you're representing decimals using binary floating point: take a look at section 4.3 of the General Python FAQ: http://www.python.org/doc/faq/general/ If anything *is* wrong here it's actually the round() result, not the string formatting: 74.425 isn't exactly representable as a binary floating-point number, so Python (like most other languages) approximates it by the closest number that *is* exactly representable, which is (on my machine and probably yours too): 74.42499971578290569595992565155029296875 Since this is less than 74.425, the round function would, in an ideal world, round this down to 74.42 instead of up to 74.43. In the absence of an ideal world, making this sort of thing happen reliably and portably is hard, and I'd guess that round() is unlikely to change. Have you looked at the decimal module in the standard library? It sounds as though you might find it useful. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1778207&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1089974 ] mmap missing offset parameter
Bugs item #1089974, was opened at 2004-12-23 03:22 Message generated for change (Comment added) made by huangpeng You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Y Knight (foom) Assigned to: A.M. Kuchling (akuchling) Summary: mmap missing offset parameter Initial Comment: For some reason, the author of the MMap module didn't see fit to expose the "offset" parameter of the mmap syscall to python. It would be really nice if it had that. Currently, it's always set to 0. m_obj->data = mmap(NULL, map_size, prot, flags, fd, 0); -- Comment By: Huang Peng (huangpeng) Date: 2007-08-22 14:36 Message: Logged In: YES user_id=1767524 Originator: NO I need map a file large than 4G in my program, But it is impossible in an 32bit system. So I need use offset parameter to map specified part of the file. I want to know when python will expose the offset parameter to us. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-05 14:05 Message: Logged In: YES user_id=33168 The patch just needs some attention (testing and possible fixes) on Windows. -- Comment By: George Yoshida (quiver) Date: 2004-12-29 13:54 Message: Logged In: YES user_id=671362 There's already a patch for this request: http://www.python.org/sf/708374 add offset to mmap The rationale is same. It's almost ready to be committed but has been left out for a year now. So give it a second chance. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-29 07:51 Message: Logged In: YES user_id=341410 I would, but I don't know the slightest about the C-level mmap internals on any platform, and spending the last hour looking through Python's mmap.c hasn't made me any more informed. James (or anyone else who reads this), are you able? -- Comment By: A.M. Kuchling (akuchling) Date: 2004-12-29 04:34 Message: Logged In: YES user_id=11375 Would either of you care to provide a patch adding the parameter? I'll review it... -- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-24 00:57 Message: Logged In: YES user_id=341410 I agree. Having access to the offset parameter would be quite convenient, at least to some who use mmap in a nontrivial fashion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1089974 ] mmap missing offset parameter
Bugs item #1089974, was opened at 2004-12-23 03:22 Message generated for change (Comment added) made by huangpeng You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Y Knight (foom) Assigned to: A.M. Kuchling (akuchling) Summary: mmap missing offset parameter Initial Comment: For some reason, the author of the MMap module didn't see fit to expose the "offset" parameter of the mmap syscall to python. It would be really nice if it had that. Currently, it's always set to 0. m_obj->data = mmap(NULL, map_size, prot, flags, fd, 0); -- Comment By: Huang Peng (huangpeng) Date: 2007-08-22 14:38 Message: Logged In: YES user_id=1767524 Originator: NO I need map a file large than 4G in my program, But it is impossible in an 32bit system. So I need use offset parameter to map specified part of the file. I want to know when python will expose the offset parameter to us. -- Comment By: Huang Peng (huangpeng) Date: 2007-08-22 14:36 Message: Logged In: YES user_id=1767524 Originator: NO I need map a file large than 4G in my program, But it is impossible in an 32bit system. So I need use offset parameter to map specified part of the file. I want to know when python will expose the offset parameter to us. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-05 14:05 Message: Logged In: YES user_id=33168 The patch just needs some attention (testing and possible fixes) on Windows. -- Comment By: George Yoshida (quiver) Date: 2004-12-29 13:54 Message: Logged In: YES user_id=671362 There's already a patch for this request: http://www.python.org/sf/708374 add offset to mmap The rationale is same. It's almost ready to be committed but has been left out for a year now. So give it a second chance. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-29 07:51 Message: Logged In: YES user_id=341410 I would, but I don't know the slightest about the C-level mmap internals on any platform, and spending the last hour looking through Python's mmap.c hasn't made me any more informed. James (or anyone else who reads this), are you able? -- Comment By: A.M. Kuchling (akuchling) Date: 2004-12-29 04:34 Message: Logged In: YES user_id=11375 Would either of you care to provide a patch adding the parameter? I'll review it... -- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-24 00:57 Message: Logged In: YES user_id=341410 I agree. Having access to the offset parameter would be quite convenient, at least to some who use mmap in a nontrivial fashion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1089974&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
