[ python-Bugs-1729170 ] os.stat producing incorrect / invalid results
Bugs item #1729170, was opened at 2007-05-31 23:24
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729170&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: Invalid
Priority: 5
Private: No
Submitted By: Joe (joesalmeri)
Assigned to: Martin v. Löwis (loewis)
Summary: os.stat producing incorrect / invalid results
Initial Comment:
Python 2.51
Windows XP SP2 + all updates
*** NOTE all code has worked on previous python versions
I just upgraded from Python 2.4.2 to Python 2.5.1 and have found some
unexpected behavior that appears to be a bug in the os.stat module.
My OS is Windows XP SP2 + all updates.
I have several programs that have worked flawlessly on all previous Python
versions for years and they are now producing incorrect results in the code
that uses os.stat.
Searching through the 2.5.1 release notes I found the following:
Use Win32 API to implement os.stat/fstat. As a result, subsecond
timestamps
are reported, the limit on path name lengths is removed, and stat
reports
WindowsError now (instead of OSError).
*
* Overview of the problem:
*
Reviewing my code it seems that it should still work with the 2.5.1 os.stat
changes however that does not appear to be the case.
Timestamps reported by os.stat() are no longer correct and the results are
not even consistent.
In my first test case ALL 3 timestamps reported by Python are 1 hour less
than the actual timestamp on the file.
In my second test case the created and last accessed timestamps reported by
Python are correct but the last write timestamp is 1 hour less than the
actual timestamp on the file.
As a third test I looked at the last write timestamps on approximately
21,000 files.
Python determined wrong last write timestamp on approximately 1581 files.
Assuming there is no error in the following code that prints out the
timestamps using the new return value from os.stat() then it would appear
that the 2.5.1 os.stat changes have a bug.
print 'CreationTime: %s' % time.strftime('%m/%d/%Y %H:%M:%S',
time.localtime(file_stats[stat.ST_CTIME]))
print 'Last Access Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S',
time.localtime(file_stats[stat.ST_ATIME]))
print 'Last Write Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S',
time.localtime(file_stats[stat.ST_MTIME]))
*
* Detailed test results
*
To demonstrate the problem I have created the following test.
Here are the files that will be used in my test and their associated
timestamps as reported the the dir command.
01/02/2003 12:34 PM 0 broke_test
03/06/2007 05:24 PM 3,497,177 broke_test2
05/31/2007 04:35 PM 254 runtest.cmd
05/31/2007 04:31 PM 513 broke.py
The file named broke_test has a timestamp of 01/02/2003 12:34:56 (dir does
not show seconds).
The runtest.cmd script shows the created, last accessed, and last write
timestamps as reported by the dir command (and also verified via right
clicking on the file and selecting properties in Explorer.
-- >>> START runtest.cmd script
@Echo Off
echo Create TimeStamp reported by dir command
dir /tc %1
echo Last Access TimeStamp reported by dir command
dir /ta %1
echo Last Write TimeStamp reported by dir command
dir /tw %1
echo Python 2.5.1 timestamp info
broke.py %1
-- >>> END runtest.cmd script
The broke.py script prints out the created, last accessed, last write
timestamps as Python sees them.
-- >>> START broke.py script
import sys
import os
import stat
import time
file_name = sys.argv[1]
file_stats = os.stat(file_name)
print
print 'File Name : %s' % (file_name)
print
print 'CreationTime: %s' % time.strftime('%m/%d/%Y %H:%M:%S',
time.localtime(file_stats[stat.ST_CTIME]))
print 'Last Access Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S',
time.localtime(file_stats[stat.ST_ATIME]))
print 'Last Write Time: %s' % time.strftime('%m/%d/%Y %H:%M:%S',
time.localtime(file_stats[stat.ST_MTIME]))
print
-- >>> END broke.py script
#
# Test 1 on file broke_test
#
runtest broke_test
Create TimeStamp reported by dir command
01/02/2003 12:34 PM 0 broke_test
Last Access TimeStamp reported by dir command
01/02/2003 12:34 PM 0 broke_test
Last Write TimeStamp reported by dir command
01/02/2003 12:34 PM 0 broke_test
Python 2.5.1 timestamp info
File Name : broke_test
CreationTime: 01/02/2003 11:34:56 -- Python results are WRONG hours
reported are 1 hour short
Last Access Time: 01/02/2003 11:34:56 -- Python results are WRONG hours
reported are 1 hour short
[ python-Bugs-1730322 ] getattr([], '__eq__')(some-object) is NotImplemented
Bugs item #1730322, was opened at 2007-06-03 10:10 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=1730322&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Type/class unification Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: getattr([], '__eq__')(some-object) is NotImplemented Initial Comment: Consider: a = [] class B: pass class C(object): pass print a == B() print a == C() m = getattr(a, '__eq__') print m(B()) print m(C()) I think this should print 'False' 4 times, but it actually prints: False False NotImplemented NotImplemented If this isn't a bug, please explain why. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730322&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721309 ] make testall shows many glibc detected malloc corruptions
Bugs item #1721309, was opened at 2007-05-18 06:42 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1721309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Neal Norwitz (nnorwitz) Summary: make testall shows many glibc detected malloc corruptions Initial Comment: export _MALLOC_CHECK_=1 make testall test_bsddb3 *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** *** glibc detected *** ./python: free(): invalid pointer: 0x40b92de4 *** followed by deadlock errors. malloc: using debugging hooks blattest test_tempfile failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 1 test_timeout test test_timeout failed -- Traceback (most recent call last): File "/build/work/Python-2.5.1/Lib/test/test_timeout.py", line 128, in testConnectTimeout %(_delta, self.fuzz, _timeout)) AssertionError: timeout (8.20631) is more than 2 seconds more than expected (0.001) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 13:33 Message: Logged In: YES user_id=33168 Originator: NO Seems to be really fixed now. 55457 (2.5) Committed revision 55751. (2.6) -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-19 19:19 Message: Logged In: YES user_id=33168 Originator: NO File Added: test_get_both.py -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-19 19:18 Message: Logged In: YES user_id=33168 Originator: NO Sigh, 4.4.20 and 4.5.20 behave differently. I tested on both, but botched it. :-( It seemed like a good idea to have at least one of the buildbots to use 4.5.20. I upgraded the g4 bot to 4.5.20, since that didn't have any version of bsddb on it. I also installed 4.4.20 on the amd64 buildbot. The x86 gentoo bot probably has 4.1, but it's down right now. Martin's machine has 4.2. Both versions (4.4 and 4.5) require the flag DB_DBT_MALLOC (get() returns an error 22 otherwise). However only 4.4 actually allocates memory. 4.5 doesn't. I checked in revs 55457 (2.5) which should handle this better. Could someone please test and verify I really fixed the problem this time. If it's really fixed, close this bug report. The real change is to conditionally free data if it is a different pointer than we pass in (orig_data). Don't free if they are the same pointer. Tested 4.5 memory leaks with the leaks program and 4.4 with valgrind. File Added: db.c -- Comment By: David Favor (dfavor) Date: 2007-05-19 08:05 Message: Logged In: YES user_id=370230 Originator: YES Just built with latest http://svn.python.org/projects/python/branches/release25-maint pull and problem still remains. -- Comment By: David Favor (dfavor) Date: 2007-05-19 08:04 Message: Logged In: YES user_id=370230 Originator: YES My test was done with latest BerkeleyDB 4.5.20 plain (no patches). -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-19 03:31 Message: Logged In: YES user_id=849994 Originator: NO I can confirm that the checkin didn't change anything for me. I use bsddb version 4.5.20_p2 from Gentoo. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 00:08 Message: Logged In: YES user_id=21627 Originator: NO (I'm not convinced that Neal's patch could actually fix anything) Can people who were able to reproduce this please report their bdb version also; I was using 4.4. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-19 00:04 Message: Logged In: YES user_id=21627 Originator: NO dfavor: I see. It is MALLOC_CHECK_, not _MALLOC_CHECK (as I used it), and not _MALLOC_CHECK_ (as you wrote). I now see that debug hooks are used, but I still cannot reproduce the problem... --
[ python-Bugs-1730372 ] When Mesa is built with NPTL support, Python extensions link
Bugs item #1730372, was opened at 2007-06-03 15:35 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=1730372&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gazi Alankus (alanic7) Assigned to: Nobody/Anonymous (nobody) Summary: When Mesa is built with NPTL support, Python extensions link Initial Comment: When Mesa is built with NPTL support, Python extensions linked to libGL segfault when std::cerr is used. Please see the following thread for descriptions, details and sample programs: http://thread.gmane.org/gmane.comp.python.c++/11443/focus=11470 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730372&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730372 ] Mesa with NPTL makes Python extensions crash with std::cerr
Bugs item #1730372, was opened at 2007-06-03 15:35 Message generated for change (Settings changed) made by alanic7 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730372&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gazi Alankus (alanic7) Assigned to: Nobody/Anonymous (nobody) >Summary: Mesa with NPTL makes Python extensions crash with std::cerr Initial Comment: When Mesa is built with NPTL support, Python extensions linked to libGL segfault when std::cerr is used. Please see the following thread for descriptions, details and sample programs: http://thread.gmane.org/gmane.comp.python.c++/11443/focus=11470 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730372&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1729929 ] test_bsddb3 malloc corruption bug #1721309 broken in 2.6
Bugs item #1729929, was opened at 2007-06-02 07:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729929&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.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: David Favor (dfavor) >Assigned to: Neal Norwitz (nnorwitz) Summary: test_bsddb3 malloc corruption bug #1721309 broken in 2.6 Initial Comment: Bug fix #1721309 should be rolled into 2.6 tree. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 14:18 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the reminder. I've applied the correct fix this time, the OS X g4 buildbot doesn't display the error message any longer. Committed revision 55751. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729929&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730389 ] strptime bug in time module
Bugs item #1730389, was opened at 2007-06-03 15:27
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=1730389&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Emma (embirath)
Assigned to: Nobody/Anonymous (nobody)
Summary: strptime bug in time module
Initial Comment:
The strptime function takes 2 arguments:
(1) a time string (like "2007 Jan 17, 10:00"), and
(2) a time format string (like "%Y %b %d, %H:%M")
Normally, a ValueError will be raised when the time string does not match the
format string. The bug I have found is that NO ValueError is raised in the case
below. Instead, and incorrect date is returned (Jan 18th is returned, when
really June 29th should be returned).
> from time import *
> print strptime('2007-180', '%Y-%j %H')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730389&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730389 ] strptime bug in time module
Bugs item #1730389, was opened at 2007-06-03 14:27
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730389&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
>Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Emma (embirath)
>Assigned to: Brett Cannon (bcannon)
Summary: strptime bug in time module
Initial Comment:
The strptime function takes 2 arguments:
(1) a time string (like "2007 Jan 17, 10:00"), and
(2) a time format string (like "%Y %b %d, %H:%M")
Normally, a ValueError will be raised when the time string does not match the
format string. The bug I have found is that NO ValueError is raised in the case
below. Instead, and incorrect date is returned (Jan 18th is returned, when
really June 29th should be returned).
> from time import *
> print strptime('2007-180', '%Y-%j %H')
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-06-03 14:33
Message:
Logged In: YES
user_id=33168
Originator: NO
Brett, could you take a look? I think this is your code. I verified this
on head, but assume 2.5 has the problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730389&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730401 ] __cmp__ present in type but not instance??
Bugs item #1730401, was opened at 2007-06-03 15:04 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=1730401&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: __cmp__ present in type but not instance?? Initial Comment: hasattr(list, '__cmp__') is True, but hasattr([], '__cmp__') is False. Doesn't the Python story about instances and classes forbid this!? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730401&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730372 ] Mesa with NPTL makes Python extensions crash with std::cerr
Bugs item #1730372, was opened at 2007-06-03 13:35
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730372&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Gazi Alankus (alanic7)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mesa with NPTL makes Python extensions crash with std::cerr
Initial Comment:
When Mesa is built with NPTL support, Python extensions linked to libGL
segfault when std::cerr is used. Please see the following thread for
descriptions, details and sample programs:
http://thread.gmane.org/gmane.comp.python.c++/11443/focus=11470
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-06-03 15:17
Message:
Logged In: YES
user_id=33168
Originator: NO
I can't reproduce this error on head with Ubuntu Linux/amd64 gcc 4.1.2.
What are the platform details? OS, compiler, etc.
$ gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-I/usr/include -I/usr/local/include -I./Include -I. -c ../spam.cc -o
spam.o
$ gcc -pthread -shared spam.o -L/usr/lib64 -L/usr/local/lib
-Wl,-R/usr/lib64 -ldb-4.4 -o build/lib.linux-x86_64-2.6/spam.so -lstdc++
$ ./python
>>> import spam
>>> spam.system('ls')
this be cerr
big5.py __db.003libpython2.6.a Objects
python-clean
build __db.004LICENSE Parser
python-fast
config.log__db.005log.01 PC README
config.status DemoMac PCbuildRISCOS
config.status.lineno Doc Makefile PCbuild8
setup.py
configure Grammar Makefile.pre pyconfig.h Tools
configure.in Include Makefile.pre.in pyconfig.h.in
__db.001 install-sh Misc python
__db.002 Lib Modules Python
0
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730372&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1729930 ] 2.5.1 latest svn fails test_curses and test_timeout
Bugs item #1729930, was opened at 2007-06-02 07:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&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: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5.1 latest svn fails test_curses and test_timeout Initial Comment: [EMAIL PROTECTED] ~]# build_python mkdir -p /build/work/Python-2.5.1 cd /build/work/Python-2.5.1 unset CDPATH export TESTOPS='-l -u curses -u network -u urlfetch -u decimal -u compiler -u bsddb -u subprocess' export CFLAGS='-pipe -fwrapv' export MALLOC_CHECK_=0 make distclean ./configure --prefix=/usr/local/pkgs/python-2.5.1 --enable-shared --disable-static --disable-ipv6 make make testall ... ... ... 299 tests OK. 2 tests failed: test_curses test_timeout 20 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_gl test_imgfile test_macfs test_macostools test_nis test_pep277 test_plistlib test_scriptpackages test_startfile test_sunaudiodev test_unicode_file test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. warning: DBTxn aborted in destructor. No prior commit() or abort(). make: *** [testall] Error 1 exp=0, got ec=2, abort=1 -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 15:19 Message: Logged In: YES user_id=33168 Originator: NO test_timeout often fails depending on if the system the test connects to is available or not (ie, the test sucks). How does test_curses fail? What platform? BTW, you can use -u all. -- Comment By: David Favor (dfavor) Date: 2007-06-02 07:54 Message: Logged In: YES user_id=370230 Originator: YES These fixes should also be dropped into the 2.6 tree. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729930&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730389 ] strptime bug in time module
Bugs item #1730389, was opened at 2007-06-03 14:27
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730389&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: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Emma (embirath)
Assigned to: Brett Cannon (bcannon)
Summary: strptime bug in time module
Initial Comment:
The strptime function takes 2 arguments:
(1) a time string (like "2007 Jan 17, 10:00"), and
(2) a time format string (like "%Y %b %d, %H:%M")
Normally, a ValueError will be raised when the time string does not match the
format string. The bug I have found is that NO ValueError is raised in the case
below. Instead, and incorrect date is returned (Jan 18th is returned, when
really June 29th should be returned).
> from time import *
> print strptime('2007-180', '%Y-%j %H')
--
>Comment By: Brett Cannon (bcannon)
Date: 2007-06-03 15:43
Message:
Logged In: YES
user_id=357491
Originator: NO
Found the problem. The regex being compiled is using ``\s*`` for the
space separator. So when you match against '2007-180' it is matching %Y
fine, but it matches %j to 18 and %H to 0 in order to make the regex match.
Changing the regex creation algorithm to use ``\s+`` solved the problem.
I am running the test suite now to make sure this doesn't break anything.
Once its done (assuming it passes) I will commit and backport to 2.5.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-06-03 14:33
Message:
Logged In: YES
user_id=33168
Originator: NO
Brett, could you take a look? I think this is your code. I verified this
on head, but assume 2.5 has the problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730389&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730401 ] __cmp__ present in type but not instance??
Bugs item #1730401, was opened at 2007-06-03 15:04 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730401&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: __cmp__ present in type but not instance?? Initial Comment: hasattr(list, '__cmp__') is True, but hasattr([], '__cmp__') is False. Doesn't the Python story about instances and classes forbid this!? -- >Comment By: Brett Cannon (bcannon) Date: 2007-06-03 15:51 Message: Logged In: YES user_id=357491 Originator: NO Do a dir() on list and on [] and you will notice that __cmp__ doesn't show up. The __cmp__ you are seeing is the type instance method of list as received from being a subclass of 'type'. It's more obvious if you print out list.__cmp__ and type.__cmp__. So it does make sense when viewed from the point-of-view of metaclasses; list is an instance of type and you are seeing a metaclass instance method on list. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730401&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730389 ] strptime bug in time module
Bugs item #1730389, was opened at 2007-06-03 14:27
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730389&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: Emma (embirath)
Assigned to: Brett Cannon (bcannon)
Summary: strptime bug in time module
Initial Comment:
The strptime function takes 2 arguments:
(1) a time string (like "2007 Jan 17, 10:00"), and
(2) a time format string (like "%Y %b %d, %H:%M")
Normally, a ValueError will be raised when the time string does not match the
format string. The bug I have found is that NO ValueError is raised in the case
below. Instead, and incorrect date is returned (Jan 18th is returned, when
really June 29th should be returned).
> from time import *
> print strptime('2007-180', '%Y-%j %H')
--
>Comment By: Brett Cannon (bcannon)
Date: 2007-06-03 17:14
Message:
Logged In: YES
user_id=357491
Originator: NO
Committed in r55752 on the trunk and r55753 in 2.5.
--
Comment By: Brett Cannon (bcannon)
Date: 2007-06-03 15:43
Message:
Logged In: YES
user_id=357491
Originator: NO
Found the problem. The regex being compiled is using ``\s*`` for the
space separator. So when you match against '2007-180' it is matching %Y
fine, but it matches %j to 18 and %H to 0 in order to make the regex match.
Changing the regex creation algorithm to use ``\s+`` solved the problem.
I am running the test suite now to make sure this doesn't break anything.
Once its done (assuming it passes) I will commit and backport to 2.5.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-06-03 14:33
Message:
Logged In: YES
user_id=33168
Originator: NO
Brett, could you take a look? I think this is your code. I verified this
on head, but assume 2.5 has the problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730389&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730441 ] os._execvpe raises assignment error in python 3000 svn
Bugs item #1730441, was opened at 2007-06-04 01:17 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=1730441&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: nifan (nifan) Assigned to: Nobody/Anonymous (nobody) Summary: os._execvpe raises assignment error in python 3000 svn Initial Comment: While converting/playing with our project and Python 3000 we hit upon this what we think is a small error in the os.py source. We communicate with mercurial (hg command) and hit the following error: http://qna.nu/paste/cnxx/ Thought it seems that the correct way to call subprocess.Popen is with a list not a string, the error it raises is still an variable referenced before assignment error. Child Exception: http://qna.nu/paste/e5el/ Seems that with Python3000 and _execvpe, the raise statement ending the function uses 'e' before assignment. Python 2.4 and Python 2.5 seems to do the correct thing and raise an OSError: [Errno 2] No such file or directory. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730441&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730441 ] os._execvpe raises assignment error in python 3000 svn
Bugs item #1730441, was opened at 2007-06-04 01:17 Message generated for change (Settings changed) made by nifan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730441&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: Open Resolution: None >Priority: 3 Private: No Submitted By: nifan (nifan) Assigned to: Nobody/Anonymous (nobody) Summary: os._execvpe raises assignment error in python 3000 svn Initial Comment: While converting/playing with our project and Python 3000 we hit upon this what we think is a small error in the os.py source. We communicate with mercurial (hg command) and hit the following error: http://qna.nu/paste/cnxx/ Thought it seems that the correct way to call subprocess.Popen is with a list not a string, the error it raises is still an variable referenced before assignment error. Child Exception: http://qna.nu/paste/e5el/ Seems that with Python3000 and _execvpe, the raise statement ending the function uses 'e' before assignment. Python 2.4 and Python 2.5 seems to do the correct thing and raise an OSError: [Errno 2] No such file or directory. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730441&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730480 ] dict constructor accesses internal items of dict derivative
Bugs item #1730480, was opened at 2007-06-03 20:59
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=1730480&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: Blake Ross (blakeross)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict constructor accesses internal items of dict derivative
Initial Comment:
>>> class MyDict(dict):
... def keys(self): print "keys"
... def __getitem__(self, n): print "__getitem__"
...
>>> myDict = MyDict(a=1, b=2)
>>> dict(myDict)
{'a': 1, 'b': 2}
PyDict_Merge accesses the items of the dict to be merged directly rather than
going through the interface for any dict instance--even a dict derivative--by
virtue of using PyDict_Check rather than PyDict_CheckExact. I believe the logic
needs to be:
if type(d).__getitem__ is dict.__getitem__ and type(d).keys is dict.keys:
...okay to access items directly...
else:
...go through the methods...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730480&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730480 ] dict init/update accesses internal items of dict derivative
Bugs item #1730480, was opened at 2007-06-03 20:59
Message generated for change (Settings changed) made by blakeross
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730480&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: Blake Ross (blakeross)
Assigned to: Nobody/Anonymous (nobody)
>Summary: dict init/update accesses internal items of dict derivative
Initial Comment:
>>> class MyDict(dict):
... def keys(self): print "keys"
... def __getitem__(self, n): print "__getitem__"
...
>>> myDict = MyDict(a=1, b=2)
>>> dict(myDict)
{'a': 1, 'b': 2}
PyDict_Merge accesses the items of the dict to be merged directly rather than
going through the interface for any dict instance--even a dict derivative--by
virtue of using PyDict_Check rather than PyDict_CheckExact. I believe the logic
needs to be:
if type(d).__getitem__ is dict.__getitem__ and type(d).keys is dict.keys:
...okay to access items directly...
else:
...go through the methods...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730480&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730441 ] os._execvpe raises assignment error in python 3000 svn
Bugs item #1730441, was opened at 2007-06-03 18:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730441&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: Open Resolution: None Priority: 3 Private: No Submitted By: nifan (nifan) Assigned to: Nobody/Anonymous (nobody) Summary: os._execvpe raises assignment error in python 3000 svn Initial Comment: While converting/playing with our project and Python 3000 we hit upon this what we think is a small error in the os.py source. We communicate with mercurial (hg command) and hit the following error: http://qna.nu/paste/cnxx/ Thought it seems that the correct way to call subprocess.Popen is with a list not a string, the error it raises is still an variable referenced before assignment error. Child Exception: http://qna.nu/paste/e5el/ Seems that with Python3000 and _execvpe, the raise statement ending the function uses 'e' before assignment. Python 2.4 and Python 2.5 seems to do the correct thing and raise an OSError: [Errno 2] No such file or directory. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 22:59 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report. Can you test the attached patch? The semantics for try/except have changed and this code doesn't look like it was updated. File Added: os-execvpe.patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730441&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730441 ] os._execvpe raises assignment error in python 3000 svn
Bugs item #1730441, was opened at 2007-06-03 18:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730441&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: 3 Private: No Submitted By: nifan (nifan) >Assigned to: Neal Norwitz (nnorwitz) Summary: os._execvpe raises assignment error in python 3000 svn Initial Comment: While converting/playing with our project and Python 3000 we hit upon this what we think is a small error in the os.py source. We communicate with mercurial (hg command) and hit the following error: http://qna.nu/paste/cnxx/ Thought it seems that the correct way to call subprocess.Popen is with a list not a string, the error it raises is still an variable referenced before assignment error. Child Exception: http://qna.nu/paste/e5el/ Seems that with Python3000 and _execvpe, the raise statement ending the function uses 'e' before assignment. Python 2.4 and Python 2.5 seems to do the correct thing and raise an OSError: [Errno 2] No such file or directory. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 23:24 Message: Logged In: YES user_id=33168 Originator: NO Nevermind. I see in the link you have a test and can reproduce the problem. Committed revision 55754. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-03 22:59 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the report. Can you test the attached patch? The semantics for try/except have changed and this code doesn't look like it was updated. File Added: os-execvpe.patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730441&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
