[ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G"
Bugs item #1673757, was opened at 2007-03-05 12:34 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. -- >Comment By: Nick Coghlan (ncoghlan) Date: 2007-03-06 20:55 Message: Logged In: YES user_id=1038590 Originator: NO Behaviour is definitely present in the current 2.6 trunk, so I expect it to be present in the 2.5 maintenance branch too. On platforms which provide a correct implementation of vsnprintf, this won't cause a buffer overflow (but can give an incorrect result). As far as I can tell, the limited precision of C doubles saves you on platforms without vsnprintf (then again, I may not be abusing it correctly after forcing my dev tree to use the vsnprintf emulation, or else the behaviour of the emulation may vary with platform vagaries in vsprintf implementations). The patch doesn't currently apply cleanly - it needs to be regenerated using svn diff from the main python directory so that the filenames are correct. We also need a test case to make sure the problem never comes back (the string tests are a little confusing though, since the same tests are used for str, unicode & UserString). -- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-05 12:47 Message: Logged In: YES user_id=411198 Originator: YES Patch for 3.0 is at http://python.org/sf/1673759 This should be checked in 2.5 and 2.6, but I don't have an environment to compile those. -- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-05 12:42 Message: Logged In: YES user_id=411198 Originator: YES This is the correct behavior: >>> '%200.200g' % 1.0 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) But 'G' is handled differently: >>> '%200.200G' % 1.0 ' 1' 'G' should give the same OverflowError as 'g'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G"
Bugs item #1673757, was opened at 2007-03-04 21:34 Message generated for change (Comment added) made by ericvsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. -- >Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 05:57 Message: Logged In: YES user_id=411198 Originator: YES Yes, my bad on not having tests and the diff being fubar. I've already started writing the tests, I should be done in the next 30 minutes. Expect a new patch. -- Comment By: Nick Coghlan (ncoghlan) Date: 2007-03-06 05:55 Message: Logged In: YES user_id=1038590 Originator: NO Behaviour is definitely present in the current 2.6 trunk, so I expect it to be present in the 2.5 maintenance branch too. On platforms which provide a correct implementation of vsnprintf, this won't cause a buffer overflow (but can give an incorrect result). As far as I can tell, the limited precision of C doubles saves you on platforms without vsnprintf (then again, I may not be abusing it correctly after forcing my dev tree to use the vsnprintf emulation, or else the behaviour of the emulation may vary with platform vagaries in vsprintf implementations). The patch doesn't currently apply cleanly - it needs to be regenerated using svn diff from the main python directory so that the filenames are correct. We also need a test case to make sure the problem never comes back (the string tests are a little confusing though, since the same tests are used for str, unicode & UserString). -- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:47 Message: Logged In: YES user_id=411198 Originator: YES Patch for 3.0 is at http://python.org/sf/1673759 This should be checked in 2.5 and 2.6, but I don't have an environment to compile those. -- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:42 Message: Logged In: YES user_id=411198 Originator: YES This is the correct behavior: >>> '%200.200g' % 1.0 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) But 'G' is handled differently: >>> '%200.200G' % 1.0 ' 1' 'G' should give the same OverflowError as 'g'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G"
Bugs item #1673757, was opened at 2007-03-04 21:34 Message generated for change (Comment added) made by ericvsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: string and unicode formatting are missing a test for "G" Initial Comment: In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 'F', 'g', and 'G' all get routed to formatfloat(). formatfloat() is essentially identical in stringobject.c and unicodeobject.c. 'F' is mapped to 'f'. There is a test for excess precision for 'f' and 'g', but not one for 'G'. The "type == 'g'" test should be "(type == 'g' || type == 'G')". I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, yet. -- >Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 06:10 Message: Logged In: YES user_id=411198 Originator: YES The patch was corrected, and tests added. -- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 05:57 Message: Logged In: YES user_id=411198 Originator: YES Yes, my bad on not having tests and the diff being fubar. I've already started writing the tests, I should be done in the next 30 minutes. Expect a new patch. -- Comment By: Nick Coghlan (ncoghlan) Date: 2007-03-06 05:55 Message: Logged In: YES user_id=1038590 Originator: NO Behaviour is definitely present in the current 2.6 trunk, so I expect it to be present in the 2.5 maintenance branch too. On platforms which provide a correct implementation of vsnprintf, this won't cause a buffer overflow (but can give an incorrect result). As far as I can tell, the limited precision of C doubles saves you on platforms without vsnprintf (then again, I may not be abusing it correctly after forcing my dev tree to use the vsnprintf emulation, or else the behaviour of the emulation may vary with platform vagaries in vsprintf implementations). The patch doesn't currently apply cleanly - it needs to be regenerated using svn diff from the main python directory so that the filenames are correct. We also need a test case to make sure the problem never comes back (the string tests are a little confusing though, since the same tests are used for str, unicode & UserString). -- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:47 Message: Logged In: YES user_id=411198 Originator: YES Patch for 3.0 is at http://python.org/sf/1673759 This should be checked in 2.5 and 2.6, but I don't have an environment to compile those. -- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-04 21:42 Message: Logged In: YES user_id=411198 Originator: YES This is the correct behavior: >>> '%200.200g' % 1.0 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) But 'G' is handled differently: >>> '%200.200G' % 1.0 ' 1' 'G' should give the same OverflowError as 'g'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1674503 ] execfile() response to syntax errors
Bugs item #1674503, was opened at 2007-03-05 23:38
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674503&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: Closed
>Resolution: Fixed
Priority: 3
Private: No
Submitted By: Jonathan Griffitts (jcgriffitts)
Assigned to: Nobody/Anonymous (nobody)
Summary: execfile() response to syntax errors
Initial Comment:
Python 2.5 seems to have an anomaly when execfile() encounters syntax errors.
If I use execfile() to execute a file that contains a syntax error, it throws
the expected SyntaxError exception but does not close the source file. Since
the file is still open, an external program can't modify it to fix the syntax
error.
I have noticed this problem in Python 2.5 on Windows 2000 and Windows XP. I
tried to reproduce it on Python 2.3 on BSD Unix but it didn't seem to happen
there.
spam.py -
[intentional-syntax-error)
--
The following is my console session:
--
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> execfile('spam.py')
Traceback (most recent call last):
File "", line 1, in
File "spam.py", line 1
[intentional-syntax-error)
^
SyntaxError: invalid syntax
>>>
--
At this point file spam.py remains open until Python exits. There's no obvious
way to close the file from within the script because there is no file object.
Under Windows, this prevents spam.py from being edited,
renamed, or deleted.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-06 12:18
Message:
Logged In: YES
user_id=849994
Originator: NO
Indeed PyRun_FileEx only closed the file if compilation was successful,
fixed in rev. 54159, 54158 (2.5).
--
Comment By: Jonathan Griffitts (jcgriffitts)
Date: 2007-03-06 01:17
Message:
Logged In: YES
user_id=796443
Originator: YES
Easy work-around: use exec(file('spam.py')) instead of execfile('spam.py')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1674503&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-947380 ] sys.path is wrong in some cases
Bugs item #947380, was opened at 2004-05-04 02:46 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947380&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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ori Berger (orib) Assigned to: Nobody/Anonymous (nobody) Summary: sys.path is wrong in some cases Initial Comment: Python version tested: 2.3.3 (But if I read the cvs annotate correctly, this goes all the way back to 2.0) OS Version tested: Win2K (but any win32 version should behave the same). On Windows, sys,path sometimes contains the 'current working directory', in which the Python process was started, while the interpreter is still initializing; it shouldn't be there until after the interpreter had completed initializing and is ready for batch or interactive execution. How to reproduce: Use plain-vanilla 2.3.3 Python, without _any_ additional module installed. The HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath registry key must NOT have any subkey (this is true for a fresh install, but might not be true if packages were installed earlier). Go to a subdirectory of your choice, e.g., C:\HoverCraft\Eels, and run (assuming Python is in c:\python23) > c:\python23\python -c "import sys; print sys.path" The first entry should be the current directory or ''. That's ok - it was added at the end of initialization. The second entry will be a .zip file where the .dll is; That's also ok. The third entry should be the current directory (or '') again. THIS IS NOT OK. How this was discovered: To give credit where credit is due, my friend Oren Gampel created a file called 'stat.py' in a directory, and from that moment on, Python started complaining about failing to import site. The reason is that 'site' imports 'ntpath', which imports 'stat', which unfortunately imported the new 'stat' rather than the library 'stat'. In some convoluted settings, this might have security implications - e.g., if an administrator starts a Python script in a directory to which a user has write permissions, this could result in a privelege escalation (even if the script has no import statements at all - the implicit "import site" is sufficient). I'm submitting a 2-line patch to the patch tracker (and one of them is a comment!) that seems to solve this problem. -- Comment By: Žiga Seilnacht (zseil) Date: 2007-03-06 14:21 Message: Logged In: YES user_id=1326842 Originator: NO This was fixed in Python 2.5 with patch #1232023: http://www.python.org/sf/1232023 -- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-21 02:06 Message: Logged In: YES user_id=341410 This is the old "module in current path shadows standard library module" issue which will be fixed in Python 2.4 via absolute and relative imports as stated in PEP 328: http://python.org/peps/pep-0328.html -- Comment By: Ori Berger (orib) Date: 2004-05-04 02:59 Message: Logged In: YES user_id=67862 Patch uploaded to http://python.org/sf/947386 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947380&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times
Bugs item #1646728, was opened at 2007-01-28 21:21 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&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: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..99 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 10:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 19:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-05 13:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 05:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 11:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675026 ] Redirect cause invalid descriptor error
Bugs item #1675026, was opened at 2007-03-06 15:58
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=1675026&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jean-Marc Ranger (jmranger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Redirect cause invalid descriptor error
Initial Comment:
Test setup:
- Windows 2000 (french)
- Python 2.5 (reproducible with 2.4.2 and 2.4.4)
One python source file, test.py:
---
import os
print os.system("echo test")
---
Console output:
---
C:\test>test.py
test
0
C:\test>test.py > test.log
Descripteur non valide
C:\test>type test.log
0
C:\test>c:\python25\python test.py
test
0
C:\test>c:\python25\python test.py > test.log
C:\test>type test.log
test
0
C:\test>
---
The "Descripteur non valide" error would translate to "invalid file descriptor".
I would expect the 2nd call to perform the same way the 4th does.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675026&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times
Bugs item #1646728, was opened at 2007-01-28 21:21 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&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 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..99 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 12:59 Message: Logged In: YES user_id=6380 Originator: NO Georgbot backported this to 2.5. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 10:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 19:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-05 13:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 05:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 11:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-947380 ] sys.path is wrong in some cases
Bugs item #947380, was opened at 2004-05-04 00:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947380&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: Platform-specific >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Ori Berger (orib) Assigned to: Nobody/Anonymous (nobody) Summary: sys.path is wrong in some cases Initial Comment: Python version tested: 2.3.3 (But if I read the cvs annotate correctly, this goes all the way back to 2.0) OS Version tested: Win2K (but any win32 version should behave the same). On Windows, sys,path sometimes contains the 'current working directory', in which the Python process was started, while the interpreter is still initializing; it shouldn't be there until after the interpreter had completed initializing and is ready for batch or interactive execution. How to reproduce: Use plain-vanilla 2.3.3 Python, without _any_ additional module installed. The HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath registry key must NOT have any subkey (this is true for a fresh install, but might not be true if packages were installed earlier). Go to a subdirectory of your choice, e.g., C:\HoverCraft\Eels, and run (assuming Python is in c:\python23) > c:\python23\python -c "import sys; print sys.path" The first entry should be the current directory or ''. That's ok - it was added at the end of initialization. The second entry will be a .zip file where the .dll is; That's also ok. The third entry should be the current directory (or '') again. THIS IS NOT OK. How this was discovered: To give credit where credit is due, my friend Oren Gampel created a file called 'stat.py' in a directory, and from that moment on, Python started complaining about failing to import site. The reason is that 'site' imports 'ntpath', which imports 'stat', which unfortunately imported the new 'stat' rather than the library 'stat'. In some convoluted settings, this might have security implications - e.g., if an administrator starts a Python script in a directory to which a user has write permissions, this could result in a privelege escalation (even if the script has no import statements at all - the implicit "import site" is sufficient). I'm submitting a 2-line patch to the patch tracker (and one of them is a comment!) that seems to solve this problem. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:06 Message: Logged In: YES user_id=849994 Originator: NO Closing accordingly. -- Comment By: Žiga Seilnacht (zseil) Date: 2007-03-06 13:21 Message: Logged In: YES user_id=1326842 Originator: NO This was fixed in Python 2.5 with patch #1232023: http://www.python.org/sf/1232023 -- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-21 00:06 Message: Logged In: YES user_id=341410 This is the old "module in current path shadows standard library module" issue which will be fixed in Python 2.4 via absolute and relative imports as stated in PEP 328: http://python.org/peps/pep-0328.html -- Comment By: Ori Berger (orib) Date: 2004-05-04 00:59 Message: Logged In: YES user_id=67862 Patch uploaded to http://python.org/sf/947386 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947380&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times
Bugs item #1646728, was opened at 2007-01-29 02:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&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 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..99 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:15 Message: Logged In: YES user_id=849994 Originator: NO Though, the new tests seem to fail on Windows (I noticed that only after backporting, since most other buildbot failures were due to the cmp/key problem in setup.py). -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 17:59 Message: Logged In: YES user_id=6380 Originator: NO Georgbot backported this to 2.5. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 15:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-06 00:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-05 18:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 10:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1631394 ] sre module has misleading docs
Bugs item #1631394, was opened at 2007-01-09 11:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1631394&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.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tom Lynn (tlynn) Assigned to: Nobody/Anonymous (nobody) Summary: sre module has misleading docs Initial Comment: >>> help(sre) ... "$" Matches the end of the string. ... \Z Matches only at the end of the string. ... M MULTILINE "^" matches the beginning of lines as well as the string. "$" matches the end of lines as well as the string. The docs for "$" are misleading - it actually matches in newline-specific ways which the module's built-in docs don't hint at. The MULTILINE docs don't clarify this. I'd also like to see "from sre import __doc__" added to the end of re.py; lack of "help(re)" is a bigger problem than having slightly wrong auto-generated docs for the re module itself. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:34 Message: Logged In: YES user_id=849994 Originator: NO Doesn't seem so. Note that the sre.__doc__ problem doesn't exist in 2.5 anymore since re is now what sre was before. -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-09 18:22 Message: Logged In: YES user_id=21627 Originator: NO Did you mean to include a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1631394&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times
Bugs item #1646728, was opened at 2007-01-28 21:21 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&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: Fixed Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..99 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 13:34 Message: Logged In: YES user_id=6380 Originator: NO That's too bad. More details? -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:15 Message: Logged In: YES user_id=849994 Originator: NO Though, the new tests seem to fail on Windows (I noticed that only after backporting, since most other buildbot failures were due to the cmp/key problem in setup.py). -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 12:59 Message: Logged In: YES user_id=6380 Originator: NO Georgbot backported this to 2.5. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 10:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 19:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-05 13:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 05:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 11:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times
Bugs item #1646728, was opened at 2007-01-29 02:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&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: Fixed Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..99 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:45 Message: Logged In: YES user_id=849994 Originator: NO Not from me, no Windows around. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 18:34 Message: Logged In: YES user_id=6380 Originator: NO That's too bad. More details? -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:15 Message: Logged In: YES user_id=849994 Originator: NO Though, the new tests seem to fail on Windows (I noticed that only after backporting, since most other buildbot failures were due to the cmp/key problem in setup.py). -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 17:59 Message: Logged In: YES user_id=6380 Originator: NO Georgbot backported this to 2.5. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 15:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-06 00:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-05 18:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 10:23 Message: Logged In: YES user_id=146903 Originator: YES The problem seems to be in datetime_from_timestamp() from datetimemodule.c. It should probably be checking to see whether the microseconds value it calculates is negative, and adjust "timet" and "us" accordingly if so. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:05 Message: Logged In: YES user_id=6380 Originator: NO Looks like a bug in the conversion from floats to ints. Anyone care to track it down more precisely? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1650903 ] PyFloat_FromString deprecated form
Bugs item #1650903, was opened at 2007-02-02 19:41 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: PyFloat_FromString deprecated form Initial Comment: PyFloat_FromString takes two arguments, and the only purpose of the second is to avoid changing the API. Extracts from Tim's 2000 comment: Since we can't change the interface of a public API function, pend is still supported but now *officially* useless: if pend is not NULL, *pend is set to NULL. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:53 Message: Logged In: YES user_id=849994 Originator: NO What do you propose to do? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1650903 ] PyFloat_FromString deprecated form
Bugs item #1650903, was opened at 2007-02-02 19:41 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: PyFloat_FromString deprecated form Initial Comment: PyFloat_FromString takes two arguments, and the only purpose of the second is to avoid changing the API. Extracts from Tim's 2000 comment: Since we can't change the interface of a public API function, pend is still supported but now *officially* useless: if pend is not NULL, *pend is set to NULL. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:54 Message: Logged In: YES user_id=849994 Originator: NO (cont'd) C API functions shouldn't even change signature in Py 3000. Therefore, a new name would be needed... -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:53 Message: Logged In: YES user_id=849994 Originator: NO What do you propose to do? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668565 ] inspect.getargspec() fails with keyword-only arguments
Bugs item #1668565, was opened at 2007-02-25 13:12 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668565&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 3000 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getargspec() fails with keyword-only arguments Initial Comment: If a function's signature includes both keyword-only arguments and *args or **kwargs then inspect.getargspec() assigns the name for the * and ** arguments to the first one or two keyword-only arguments. -- >Comment By: Brett Cannon (bcannon) Date: 2007-03-06 11:32 Message: Logged In: YES user_id=357491 Originator: YES Fixed by r54043. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668565&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633621 ] curses should reset curses.{COLS, LINES} when term. resized
Bugs item #1633621, was opened at 2007-01-12 00:38
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633621&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: 3
Private: No
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses should reset curses.{COLS,LINES} when term. resized
Initial Comment:
[forwarded from http://bugs.debian.org/366698]
The curses module does not reset curses.COLS and curses.LINES when the terminal
is resized.
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2007-03-06 21:47
Message:
Logged In: YES
user_id=89016
Originator: NO
Checked in as revision 54180 and 54181 (2.5)
--
Comment By: Scott Dial (geekmug)
Date: 2007-03-05 23:14
Message:
Logged In: YES
user_id=383208
Originator: NO
I've reviewed this patch and I believe it to be the correct patch. I
believe it would be prudent to add a test case for this. I'm unable to
attach, but here is a link to a patch for that:
http://scottdial.com/python-dev/curses-test.patch
--
Comment By: Walter Dörwald (doerwalter)
Date: 2007-02-12 19:59
Message:
Logged In: YES
user_id=89016
Originator: NO
Here's a patch that implements the requested changes.
File Added: diff.txt
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633621&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1631394 ] sre module has misleading docs
Bugs item #1631394, was opened at 2007-01-09 12:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1631394&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Regular Expressions >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tom Lynn (tlynn) >Assigned to: Fredrik Lundh (effbot) Summary: sre module has misleading docs Initial Comment: >>> help(sre) ... "$" Matches the end of the string. ... \Z Matches only at the end of the string. ... M MULTILINE "^" matches the beginning of lines as well as the string. "$" matches the end of lines as well as the string. The docs for "$" are misleading - it actually matches in newline-specific ways which the module's built-in docs don't hint at. The MULTILINE docs don't clarify this. I'd also like to see "from sre import __doc__" added to the end of re.py; lack of "help(re)" is a bigger problem than having slightly wrong auto-generated docs for the re module itself. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-06 21:55 Message: Logged In: YES user_id=21627 Originator: NO The re.__doc__ problem is gone; the problem that the $ documentation doesn't give a complete specification persists. Fredrik, do you have an opinion on this? If not, please unassign. -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 19:34 Message: Logged In: YES user_id=849994 Originator: NO Doesn't seem so. Note that the sre.__doc__ problem doesn't exist in 2.5 anymore since re is now what sre was before. -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-09 19:22 Message: Logged In: YES user_id=21627 Originator: NO Did you mean to include a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1631394&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1647654 ] No obvious and correct way to get the time zone offset
Bugs item #1647654, was opened at 2007-01-30 00:48 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647654&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: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: No obvious and correct way to get the time zone offset Initial Comment: It would be nice if the Python time module provided an obvious way to get the local time UTC offset for an arbitrary time stamp. The existing constants included in the module are not sufficient to correctly determine this value. As context, the Bazaar version control system (written in Python), the local time UTC offset is recorded in a commit. The method used in releases prior to 0.14 made use of the "daylight", "timezone" and "altzone" constants from the time module like this: if time.localtime(t).tm_isdst and time.daylight: return -time.altzone else: return -time.timezone This worked most of the time, but would occasionally give incorrect results. On Linux, the local time system can handle different daylight saving rules for different spans of years. For years where the rules change, these constants can provide incorrect data. Furthermore, they may be incorrect for time stamps in the past. I personally ran into this problem last December when Western Australia adopted daylight saving -- time.altzone gave an incorrect value until the start of 2007. Having a function in the standard library to calculate this offset would solve the problem. The implementation we ended up with for Bazaar was: offset = datetime.fromtimestamp(t) - datetime.utcfromtimestamp(t) return offset.days * 86400 + offset.seconds Another alternative would be to expose tm_gmtoff on time tuples (perhaps using the above code to synthesise it on platforms that don't have the field). -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 17:39 Message: Logged In: YES user_id=6380 Originator: NO I see. There is code to decide the values for time.timezone, time.altzone and time.daylight that compares tm_gmtoff for Jan 1st of the current year to tm_gmtoff for July 1st; it uses this to decide whether DST is in effect and on which hemisphere you're on. I don't know why I didn't think of checking the tm_isdst flag instead, but either way the code would have failed for you prior to Jan 1st 07, because it could not have seen a difference if your timezone database was correct. You're just lucky you weren't running CYGWIN; the code inside #ifdef __CYGWIN__ doesn't even entertain the possibility that there's life possible on the Southern hemisphere. ;-) I think we should do two things; (a) export tm_zone and tm_gmtoff if they exist; (b) change the code that probes Jan 1st and Jul 1st of the current year to instead probe 4-6 spots starting today and covering the year forward. Unfortunately tm_zone and tm_gmtoff appear glibc inventions, so for supporting Solaris, Windows etc. I think we still need these. We really could use a module that accesses the entire timezone database but that's even more platform specific. If you want this to happen, please lobby for someone to help out on python-dev or c.l.py; I'm kind of overcommitted. :-) -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-05 05:03 Message: Logged In: YES user_id=146903 Originator: YES In Western Australia, a 3 year daylight saving trial was introduced starting on 3rd December 2006. Prior to that, we had no daylight saving shifts (the previous time we had daylight saving was 15 years ago in another trial). Since there was no daylight savings for 1st January 2006 and 1st July 2006, time.timezone and time.altzone were both equal to -28800 (UTC+8) for Python interpreters run in 2006. I am sure that I had the tzdata updates installed: my computer displayed the correct time, and listed the UTC offset as +0900 in December. Creating a time tuple for a date in December 2006 had the tm_isdst flag set to 1. If I was programming this in C, I'd use the tm_gmtoff field of "struct tm" if it was available. On platforms that don't provide tm_gmtoff, other platform specific methods would be needed (e.g. using timezone/altzone). The other alternative is to do date arithmetic on the results of localtime() and gmtime(), as you say. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 10:48 Message: Logged In: YES user_id=6380 Originator: NO Hm I'm not sure I understand why th
[ python-Bugs-1115886 ] os.path.splitext don't handle unix hidden file correctly
Bugs item #1115886, was opened at 2005-02-03 20:27
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jeong-Min Lee (falsetru)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.splitext don't handle unix hidden file correctly
Initial Comment:
I expected this.
>>> os.path.splitext('/path/to/.Hiddenfile')
('/path/to/.Hiddenfile', '')
but got this.
>>> os.path.splitext('/path/to/.Hiddenfile')
('/path/to/', '.Hiddenfile')
--
Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-06 18:20
Message:
Logged In: YES
user_id=764593
Originator: NO
1462106 is a patch, though perhaps not the latest.
python-dev is currently debating whether to fix this behavior or maintain
backwards-compatibility.
That suggests that it at least won't be changed in a bugfix version (like
2.4.x), and the group should be changed to 2.6.
--
Comment By: John J Lee (jjlee)
Date: 2005-12-04 09:44
Message:
Logged In: YES
user_id=261020
-1
I hate to be a stick-in-the-mud, but the existing behaviour
is what I would expect, and seems to be regular -- always
picks the last dot:
>>> os.path.splitext('a/b/c/foo.bar')
('a/b/c/foo', '.bar')
>>> os.path.splitext('a/b/c/f.oo.bar')
('a/b/c/f.oo', '.bar')
>>> os.path.splitext('a/b/c/.foo')
('a/b/c/', '.foo')
>>> os.path.splitext('a/b/c/.foo.txt')
('a/b/c/.foo', '.txt')
Changing it would surely break somebody's code too, of course.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2005-06-18 17:05
Message:
Logged In: YES
user_id=1188172
Interestingly, altering the behaviour of splitext in such a
way does not contradict the documentation, which is:
"""
Split the pathname path into a pair (root, ext) such that
root + ext == path, and ext is empty or begins with a period
and contains at most one period.
"""
Personally I'm in favour of this change (on Unix it makes
sense, while on Windows you can hardly find an
"extension-only" file).
--
Comment By: engelbert gruber (grubert)
Date: 2005-06-13 10:12
Message:
Logged In: YES
user_id=147070
from test_posixpath.py ::
self.assertEqual(posixpath.splitext(".ext"), ("", ".ext"))
IMHO should then return (".ext",""). if this is desired ::
if i<=p.rfind('/'):
return p, ''
else:
return p[:i], p[i:]
should do
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115886&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-1656675 ] Drop-Handler for Python files
Feature Requests item #1656675, was opened at 2007-02-10 06:36
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1656675&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marek Kubica (leonidasxiv)
Assigned to: Martin v. Löwis (loewis)
Summary: Drop-Handler for Python files
Initial Comment:
Hi!
We had a dscussion about what happens when one drops a file on a python
sourcecode-file in the python-forum [1]. It turned out, that nothing happens at
all. So someone brought up a solution. It is not really a problem with Python
but it would be nice to add this to the Windows Installer.
The proposed solution was to add the following to the registry (this is the
format of the registry editor):
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Python.File\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"
[HKEY_CLASSES_ROOT\Python.NoConFile\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"
[HKEY_CLASSES_ROOT\Python.CompiledFile\shellex\DropHandler]
@="{86C86720-42A0-1069-A2E8-08002B30309D}"
That should be simple thing to do using the MSI-Installer.
[1] only in german, sorry: http://www.python-forum.de/topic-7493.html
--
Comment By: Jim Jewett (jimjjewett)
Date: 2007-03-06 18:50
Message:
Logged In: YES
user_id=764593
Originator: NO
What would happen then? For example, should it cause python to start up,
running with that file, and the dropped file as stdin?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1656675&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1650903 ] PyFloat_FromString deprecated form
Bugs item #1650903, was opened at 2007-02-02 14:41 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&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 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: PyFloat_FromString deprecated form Initial Comment: PyFloat_FromString takes two arguments, and the only purpose of the second is to avoid changing the API. Extracts from Tim's 2000 comment: Since we can't change the interface of a public API function, pend is still supported but now *officially* useless: if pend is not NULL, *pend is set to NULL. -- >Comment By: Jim Jewett (jimjjewett) Date: 2007-03-06 19:06 Message: Logged In: YES user_id=764593 Originator: YES I didn't realize that a decision had been made about the C API stability. I would indeed propose changing it, but probably not if it the rest of the API (even for strings and unicode?) is supposed to stay stable. -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:54 Message: Logged In: YES user_id=849994 Originator: NO (cont'd) C API functions shouldn't even change signature in Py 3000. Therefore, a new name would be needed... -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:53 Message: Logged In: YES user_id=849994 Originator: NO What do you propose to do? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650903&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-670311 ] sys.exit and PYTHONINSPECT
Bugs item #670311, was opened at 2003-01-18 16:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670311&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Kevin Altis (kasplat) Assigned to: Nobody/Anonymous (nobody) Summary: sys.exit and PYTHONINSPECT Initial Comment: If you invoke the Python interpreter with -i, then even sys.exit shouldn't kill the interpreter, especially since sys.exit generates a SystemExit exception which can be caught. I can't think of any other case where -i fails to keep the interpreter alive after a script exits, whether because of an syntax or runtime error or normal termination. I started a thread on python-dev about this issue: http://mail.python.org/pipermail/python-dev/2003- January/032217.html ka -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 00:35 Message: Logged In: YES user_id=849994 Originator: NO This was now fixed in rev. 54188. -- Comment By: Michael Stone (mbrierst) Date: 2003-03-04 23:26 Message: Logged In: YES user_id=670441 See patch 697613 for a possible fix. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670311&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1646728 ] datetime.fromtimestamp fails with negative fractional times
Bugs item #1646728, was opened at 2007-01-29 11:21 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1646728&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: Fixed Priority: 5 Private: No Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.fromtimestamp fails with negative fractional times Initial Comment: The datetime.fromtimestamp() function works fine with integer timestamps and positive fractional timestamps, but fails if I pass a negative fractional timestamp. For example: >>> import datetime >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: microsecond must be in 0..99 It should return the same result as datetime.fromtimestamp(-1) - timedelta(seconds=.5). The same bug can be triggered in datetime.utcfromtimestamp(). I have been able to reproduce this bug in Python 2.4.4 and Python 2.5 on Linux. -- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2007-03-07 16:34 Message: Logged In: YES user_id=1200846 Originator: NO Hello, I'm user of Windows (Now building Python2.5 with VC6) I heard localtime() can only handle positive time_t on windows, so datetime.fromtimestamp() also fails for negative value. >>> datetime.datetime.fromtimestamp(-1.05) Traceback (most recent call last): File "", line 1, in ValueError: timestamp out of range for platform localtime()/gmtime() function >>> datetime.datetime.fromtimestamp(-1) Traceback (most recent call last): File "", line 1, in ValueError: timestamp out of range for platform localtime()/gmtime() function I'll attach workaround for unittest. Probably there is better way skip this test on non-negative platform though :-) Index: Lib/test/test_datetime.py === --- Lib/test/test_datetime.py (revision 54194) +++ Lib/test/test_datetime.py (working copy) @@ -1428,9 +1428,17 @@ def test_negative_float_fromtimestamp(self): # The result is tz-dependent; at least test that this doesn't # fail (like it did before bug 1646728 was fixed). +try: +self.theclass.fromtimestamp(-1) +except ValueError: # cannot handle negative value +return self.theclass.fromtimestamp(-1.05) def test_negative_float_utcfromtimestamp(self): +try: +self.theclass.utcfromtimestamp(-1) +except ValueError: # cannot handle negative value +return d = self.theclass.utcfromtimestamp(-1.05) self.assertEquals(d, self.theclass(1969, 12, 31, 23, 59, 58, 95)) -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 03:45 Message: Logged In: YES user_id=849994 Originator: NO Not from me, no Windows around. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 03:34 Message: Logged In: YES user_id=6380 Originator: NO That's too bad. More details? -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 03:15 Message: Logged In: YES user_id=849994 Originator: NO Though, the new tests seem to fail on Windows (I noticed that only after backporting, since most other buildbot failures were due to the cmp/key problem in setup.py). -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 02:59 Message: Logged In: YES user_id=6380 Originator: NO Georgbot backported this to 2.5. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 00:50 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54167. I'm leaving this open until it's been backported to the 2.5 branch. -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-06 09:03 Message: Logged In: YES user_id=146903 Originator: YES I just tried the patch, and can confirm that it fixes the problem with datetime.fromtimestamp() and datetime.utcfromtimestamp(). The logic in the patch looks correct. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 03:38 Message: Logged In: YES user_id=6380 Originator: NO Attached is a fix. If this is to your liking I'll check it in. File Added: datetime.patch ---
[ python-Bugs-1675511 ] Python still uses broken -xcode option on Solaris/x86
Bugs item #1675511, was opened at 2007-03-07 02:54 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=1675511&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carson Gaspar (cgaspar) Assigned to: Nobody/Anonymous (nobody) Summary: Python still uses broken -xcode option on Solaris/x86 Initial Comment: Bug 1561333 was submitted against Python 2.4 with no action, so I'm submitting a new bug against 2.5 in the hopes that someone will read it... text updated with minor corrections. Python 2.5, Solaris x86 10 Update 3, Sun Studio 11 xcode=pic32 option is not supported on Solaris x86 Sun C . Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when any compiler other than gcc is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates an error that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675511&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
