[ python-Bugs-1729742 ] missing int->Py_ssize_t in documentation
Bugs item #1729742, was opened at 2007-06-02 01:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729742&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Wellington (bwelling) Assigned to: Nobody/Anonymous (nobody) Summary: missing int->Py_ssize_t in documentation Initial Comment: The "Parsing arguments and building values" section of the Python/C API Reference Manual describes the "s#" format unit as requiring a [const char *, int]. This should presumably be a Py_ssize_t, as that's what the code appears to expect. The same problem also occurs elsewhere in this page; pretty much everywhere the # format modifier is described. I'm seeing this in both the 2.5.1 and development versions of the docs on docs.python.org. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-06-02 09:27 Message: Logged In: YES user_id=21627 Originator: NO It's more complicated than that, see PEP 353: It's Py_ssize_t if the module defines PY_SSIZE_T_CLEAN, else it's int. Would you like to work on a patch fixing the documentation? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729742&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ 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: Open
Resolution: None
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
Last Wr
[ python-Bugs-1729929 ] test_bsddb3 malloc corruption bug #1721309 broken in 2.6
Bugs item #1729929, was opened at 2007-06-02 09:50 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=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: Open Resolution: None Priority: 5 Private: No Submitted By: David Favor (dfavor) Assigned to: Nobody/Anonymous (nobody) Summary: test_bsddb3 malloc corruption bug #1721309 broken in 2.6 Initial Comment: Bug fix #1721309 should be rolled into 2.6 tree. -- 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-1729930 ] 2.5.1 latest svn fails test_curses and test_timeout
Bugs item #1729930, was opened at 2007-06-02 09:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=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 -- 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-1720241 ] Compiler is not thread safe?
Bugs item #1720241, was opened at 2007-05-16 14:38 Message generated for change (Comment added) made by dfavor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ‹‹PC›› (zpcz) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler is not thread safe? Initial Comment: r = ''' a(b(c[d])) ''' from threading import Thread from compiler import parse Thread(target = parse, args = (r,)).start() leads to Bus error (core dumped) When runs not in thread everything is OK. OS FreeBSD 5.4. Python 2.5.1 (seems that 2.5 also has this error) (Runs perfectly on Linux, and on FreeBSD with Python 2.4) -- Comment By: David Favor (dfavor) Date: 2007-06-02 09:53 Message: Logged In: YES user_id=370230 Originator: NO This works on Fedora 6 and Python 2.5.1 -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-18 18:14 Message: Logged In: YES user_id=80475 Originator: NO FWIW, I cannot get the OP's script to fail on Py2.5.1 on either Windows XP or on Gentoo Linux. -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 04:37 Message: Logged In: YES user_id=849994 Originator: NO > The compiler package is written in pure Python, so no matter what > statements it makes, it should not crash the interpreter. This is not entirely true, it uses the C-written parser module to parse its input. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 01:52 Message: Logged In: YES user_id=21627 Originator: NO The compiler package is written in pure Python, so no matter what statements it makes, it should not crash the interpreter. Given that this is not easily reproducable on other systems, chances are high that this is indeed an operating system bug or limitation. -- Comment By: ‹‹PC›› (zpcz) Date: 2007-05-17 10:59 Message: Logged In: YES user_id=1395738 Originator: YES Actually here is the simpler test cases: r = '(((a)))' or r = '[[[a]]]' info threads in GDB prints folowing: 4 Thread 2 (LWP 100196) 0x281a02fb in pthread_testcancel () from /usr/lib/libpthread.so.1 * 3 Thread 3 (LWP 100119) 0x28195aca in _pthread_mutex_lock () from /usr/lib/libpthread.so.1 2 Thread 1 (runnable) 0x28198207 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 I can also attach traceback if it can help. Does it means that something wrong with libpthread? -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-16 18:30 Message: Logged In: YES user_id=479790 Originator: NO No problem either on Windows with 2.4.3 and 2.5 (2.5.1 untested) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&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 09:51 Message generated for change (Comment added) made by dfavor 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: David Favor (dfavor) Date: 2007-06-02 09: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-1720241 ] Compiler is not thread safe?
Bugs item #1720241, was opened at 2007-05-16 21:38 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: ‹‹PC›› (zpcz) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler is not thread safe? Initial Comment: r = ''' a(b(c[d])) ''' from threading import Thread from compiler import parse Thread(target = parse, args = (r,)).start() leads to Bus error (core dumped) When runs not in thread everything is OK. OS FreeBSD 5.4. Python 2.5.1 (seems that 2.5 also has this error) (Runs perfectly on Linux, and on FreeBSD with Python 2.4) -- Comment By: David Favor (dfavor) Date: 2007-06-02 16:53 Message: Logged In: YES user_id=370230 Originator: NO This works on Fedora 6 and Python 2.5.1 -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-05-19 01:14 Message: Logged In: YES user_id=80475 Originator: NO FWIW, I cannot get the OP's script to fail on Py2.5.1 on either Windows XP or on Gentoo Linux. -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 11:37 Message: Logged In: YES user_id=849994 Originator: NO > The compiler package is written in pure Python, so no matter what > statements it makes, it should not crash the interpreter. This is not entirely true, it uses the C-written parser module to parse its input. -- Comment By: Martin v. Löwis (loewis) Date: 2007-05-18 08:52 Message: Logged In: YES user_id=21627 Originator: NO The compiler package is written in pure Python, so no matter what statements it makes, it should not crash the interpreter. Given that this is not easily reproducable on other systems, chances are high that this is indeed an operating system bug or limitation. -- Comment By: ‹‹PC›› (zpcz) Date: 2007-05-17 17:59 Message: Logged In: YES user_id=1395738 Originator: YES Actually here is the simpler test cases: r = '(((a)))' or r = '[[[a]]]' info threads in GDB prints folowing: 4 Thread 2 (LWP 100196) 0x281a02fb in pthread_testcancel () from /usr/lib/libpthread.so.1 * 3 Thread 3 (LWP 100119) 0x28195aca in _pthread_mutex_lock () from /usr/lib/libpthread.so.1 2 Thread 1 (runnable) 0x28198207 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 I can also attach traceback if it can help. Does it means that something wrong with libpthread? -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-17 01:30 Message: Logged In: YES user_id=479790 Originator: NO No problem either on Windows with 2.4.3 and 2.5 (2.5.1 untested) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720241&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1668596 ] distutils chops the first character of filenames
Bugs item #1668596, was opened at 2007-02-25 14:15
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668596&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: Distutils
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Sam Pointon (freecondiments)
Assigned to: Neal Norwitz (nnorwitz)
Summary: distutils chops the first character of filenames
Initial Comment:
Python 2.5c1, Windows XP SP2.
distutils chops the first character from some filenames if the package_data key
is ''.
Minimal example:
The setup.py attached, and a directory named 'doc' in the same directory as
setup.py with files in it. Running "python setup.py bdist" triggers the error.
On my box, this fails with:
running bdist
running bdist_dumb
running build
running build_py
error: can't copy 'oc\architecture.rst': doesn't exist or not a regular file
http://mail.python.org/pipermail/distutils-sig/2005-April/004453.html
describes the same problem, and
http://mail.python.org/pipermail/distutils-sig/2005-April/004458.html has a
commentary on the code in distutils/commands/build_py.py which causes the error.
On lines 117-122, it tries to chop the directory path from the files it has
found, using len() and slicing. This job is better done by os.path.split (and
is probably more portable, too).
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-06-02 11:53
Message:
Logged In: YES
user_id=33168
Originator: NO
Committed revision 55747. (2.5)
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-06-01 00:32
Message:
Logged In: YES
user_id=33168
Originator: NO
Committed revision 55731. (2.6)
Still needs to be backported.
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-17 11:21
Message:
Logged In: YES
user_id=984087
Originator: NO
It appears that I misunderstood the problem. Also, the attached setup.py
has a typo. Instead of
package_data = {'': ['doc/*']}
it should read
package_data = {'foobar': ['doc/*']}
Any way, I reproduced the problem and created a patch (1720897).
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-05-16 08:47
Message:
Logged In: YES
user_id=984087
Originator: NO
After reading the distutils example section today, I did find one example
using null string as package_dir value. So there may be something to this
bug after all.
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-03-27 09:19
Message:
Logged In: YES
user_id=984087
Originator: NO
Hi,
I reproduced the problem with the latest build on linux. The "fix" may be
trivial but I am not entirely sure if there is a problem in the first
place. The distutils document does not mention about having null value for
package_dir as is the case in your setup.py. I may be missing something
here but can you please explain the conclusion that "" is a perfectly valid
value for package_dir (as mentioned in one of the threads in mailing list)?
I am assuming that you mean "distribution root" directory by "". If this is
found to be valid usage, the document should be updated along with the
code fix. Otherwise, a check can be put in to disallow null values.
Raghu.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1668596&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730114 ] cStringIO no loonger accepts array.array objects
Bugs item #1730114, was opened at 2007-06-02 20:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&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: reedobrien (reedobrien)
Assigned to: Nobody/Anonymous (nobody)
Summary: cStringIO no loonger accepts array.array objects
Initial Comment:
It worked fine in 2.5 and 2.4.4
Python 2.5.1 (r251:54863, Jun 2 2007, 19:09:15)
Type "copyright", "credits" or "license" for more information.
In [1]: from cStringIO import StringIO
In [2]: from array import array
In [3]: a = array('B', [0,1,2])
In [4]: StringIO(a)
---
Traceback (most recent call last)
/Users/reedobrien/ in ()
: expected a character buffer object
Recompiling with the 2.5 cStringIO.c it works.
Python 2.5.1 (r251:54863, Jun 2 2007, 20:06:12)
Type "copyright", "credits" or "license" for more information.
In [1]: from array import array
In [2]: from cStringIO import StringIO
In [3]: a = array('B', [0,1,2])
In [4]: StringIO(a)
Out[4]:
I blame Visual Studio.
I don't know enough c to fix it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730114 ] cStringIO no longer accepts array.array objects
Bugs item #1730114, was opened at 2007-06-02 20:01
Message generated for change (Settings changed) made by reedobrien
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&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: reedobrien (reedobrien)
Assigned to: Nobody/Anonymous (nobody)
>Summary: cStringIO no longer accepts array.array objects
Initial Comment:
It worked fine in 2.5 and 2.4.4
Python 2.5.1 (r251:54863, Jun 2 2007, 19:09:15)
Type "copyright", "credits" or "license" for more information.
In [1]: from cStringIO import StringIO
In [2]: from array import array
In [3]: a = array('B', [0,1,2])
In [4]: StringIO(a)
---
Traceback (most recent call last)
/Users/reedobrien/ in ()
: expected a character buffer object
Recompiling with the 2.5 cStringIO.c it works.
Python 2.5.1 (r251:54863, Jun 2 2007, 20:06:12)
Type "copyright", "credits" or "license" for more information.
In [1]: from array import array
In [2]: from cStringIO import StringIO
In [3]: a = array('B', [0,1,2])
In [4]: StringIO(a)
Out[4]:
I blame Visual Studio.
I don't know enough c to fix it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-802310 ] tkFont may reuse font names
Bugs item #802310, was opened at 2003-09-08 00:52
Message generated for change (Comment added) made by lpd
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802310&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: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: Fredrik Lundh (effbot)
Assigned to: Nobody/Anonymous (nobody)
Summary: tkFont may reuse font names
Initial Comment:
(sent to me instead of to the bug manager; note that
the tkFont naming approach is also used for widgets and
callbacks /F)
The class tkFont has a problem name it chooses if no
name is
given. The choosen method 'name = "font" + str(id
(self))' isn't safe
because the name may exists longer than the Font
object and so another
Font object may be created with a different font but the
same
id() and so the same name. id() says
Return the identity of an object. This is guaranteed
to be unique
among simultaneously existing objects.
^^^
Note that this bug doesn't strike if you hold a reference
to the Font
object and so the GC can't reclaim the space.
To reproduce run the attached program. It produces
something like:
previously: ('Times', 15, 'bold')
now: ('Times', 18, 'bold')
iterations: 8
mapping: {'font136494612': ('Times',
14, 'bold'), 'font136499772': ('Times',
15, 'bold'), 'font136545468': ('Times',
17, 'bold'), 'font136483156': ('Times',
11, 'bold'), 'font136502700': ('Times',
12, 'bold'), 'font136510460': ('Times',
13, 'bold'), 'font136515228': ('Times',
16, 'bold'), 'font136365348': ('Times', 10, 'bold')}
Traceback (most recent call last):
File "tkfont_bug.py", line 20, in ?
assert 0
AssertionError
Raimar
--
Comment By: L. Peter Deutsch (lpd)
Date: 2007-06-02 22:16
Message:
Logged In: YES
user_id=8861
Originator: NO
This bug has bitten me too, in a real program.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=802310&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730136 ] tkFont.__eq__ gives type error
Bugs item #1730136, was opened at 2007-06-02 22:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730136&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: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Martin v. Löwis (loewis) Summary: tkFont.__eq__ gives type error Initial Comment: The current definition is: def __eq__(self, other): return self.name == other.name and isinstance(other, Font) This can get an AttributeError if other isn't a Font. The code should be: def __eq__(self, other): return isinstance(other, Font) and self.name == other.name -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730136&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730114 ] cStringIO no longer accepts array.array objects
Bugs item #1730114, was opened at 2007-06-02 20:01
Message generated for change (Comment added) made by reedobrien
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&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: reedobrien (reedobrien)
Assigned to: Nobody/Anonymous (nobody)
Summary: cStringIO no longer accepts array.array objects
Initial Comment:
It worked fine in 2.5 and 2.4.4
Python 2.5.1 (r251:54863, Jun 2 2007, 19:09:15)
Type "copyright", "credits" or "license" for more information.
In [1]: from cStringIO import StringIO
In [2]: from array import array
In [3]: a = array('B', [0,1,2])
In [4]: StringIO(a)
---
Traceback (most recent call last)
/Users/reedobrien/ in ()
: expected a character buffer object
Recompiling with the 2.5 cStringIO.c it works.
Python 2.5.1 (r251:54863, Jun 2 2007, 20:06:12)
Type "copyright", "credits" or "license" for more information.
In [1]: from array import array
In [2]: from cStringIO import StringIO
In [3]: a = array('B', [0,1,2])
In [4]: StringIO(a)
Out[4]:
I blame Visual Studio.
I don't know enough c to fix it.
--
>Comment By: reedobrien (reedobrien)
Date: 2007-06-03 00:49
Message:
Logged In: YES
user_id=995094
Originator: YES
It appears this is the change that broke it.
http://svn.python.org/view/python/branches/release25-maint/Modules/cStringIO.c?rev=52302&r1=51333&r2=52302
This is the log entry from that changeset:
Bug #1548891: The cStringIO.StringIO() constructor now encodes unicode
arguments with the system default encoding just like the write()
method does, instead of converting it to a raw buffer.
(backport from rev. 52301)
Perhaps the cPickle module should be used instead...
BUT at first glance the following seems to make both work:
if (PyUnicode_Check(s))
{
if (PyObject_AsCharBuffer(s, (const char **)&buf, &size) != 0)
{
PyErr_Format(PyExc_TypeError, "expected character
buffer, %.200s
found",
s->ob_type->tp_name);
return NULL;
}
}
else
{
if (PyObject_AsReadBuffer(s, (const void **)&buf, &size) != 0)
return NULL;
}
But the more I think about it the more I think cPickle is more appropriate
for this purpose. In that case I should make a blurb for the docs about
not storing arbitrary data in cStringIO.
Either way I am attaching the cStringIO.c file that worked for me...
File Added: cStringIO.c
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730114 ] cStringIO no longer accepts array.array objects
Bugs item #1730114, was opened at 2007-06-02 20:01
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&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: reedobrien (reedobrien)
>Assigned to: Georg Brandl (gbrandl)
Summary: cStringIO no longer accepts array.array objects
Initial Comment:
It worked fine in 2.5 and 2.4.4
Python 2.5.1 (r251:54863, Jun 2 2007, 19:09:15)
Type "copyright", "credits" or "license" for more information.
In [1]: from cStringIO import StringIO
In [2]: from array import array
In [3]: a = array('B', [0,1,2])
In [4]: StringIO(a)
---
Traceback (most recent call last)
/Users/reedobrien/ in ()
: expected a character buffer object
Recompiling with the 2.5 cStringIO.c it works.
Python 2.5.1 (r251:54863, Jun 2 2007, 20:06:12)
Type "copyright", "credits" or "license" for more information.
In [1]: from array import array
In [2]: from cStringIO import StringIO
In [3]: a = array('B', [0,1,2])
In [4]: StringIO(a)
Out[4]:
I blame Visual Studio.
I don't know enough c to fix it.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-06-03 01:40
Message:
Logged In: YES
user_id=80475
Originator: NO
Georgbot, I believe this was your checkin.
--
Comment By: reedobrien (reedobrien)
Date: 2007-06-03 00:49
Message:
Logged In: YES
user_id=995094
Originator: YES
It appears this is the change that broke it.
http://svn.python.org/view/python/branches/release25-maint/Modules/cStringIO.c?rev=52302&r1=51333&r2=52302
This is the log entry from that changeset:
Bug #1548891: The cStringIO.StringIO() constructor now encodes unicode
arguments with the system default encoding just like the write()
method does, instead of converting it to a raw buffer.
(backport from rev. 52301)
Perhaps the cPickle module should be used instead...
BUT at first glance the following seems to make both work:
if (PyUnicode_Check(s))
{
if (PyObject_AsCharBuffer(s, (const char **)&buf, &size) != 0)
{
PyErr_Format(PyExc_TypeError, "expected character
buffer, %.200s
found",
s->ob_type->tp_name);
return NULL;
}
}
else
{
if (PyObject_AsReadBuffer(s, (const void **)&buf, &size) != 0)
return NULL;
}
But the more I think about it the more I think cPickle is more appropriate
for this purpose. In that case I should make a blurb for the docs about
not storing arbitrary data in cStringIO.
Either way I am attaching the cStringIO.c file that worked for me...
File Added: cStringIO.c
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1729014 ] 0.0 and -0.0 end up referring to the same object
Bugs item #1729014, was opened at 2007-05-31 10:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729014&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: Johnnyg (swfiua) Assigned to: Nobody/Anonymous (nobody) Summary: 0.0 and -0.0 end up referring to the same object Initial Comment: I am not really sure whether this is a bug or a feature. The attached code attempts to demonstrate the problem. I had some code that was trying to change -0.0 to 0.0 so that the accountants I work with don't panic. The code was something like this: if n == -0.0: n = 0.0 Regardless of whether n is -0.0 or 0.0 the test passes (which is good). However after the assignment n is actually -0.0 It looks like python is creating a single object for both -0.0 and 0.0. Whichever appears first within the local scope seems to be the value that actually gets stored. Eg changing the code to if n == 0.0: n = 0.0 gets me the behaviour I wanted. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-06-03 01:50 Message: Logged In: YES user_id=80475 Originator: NO I don't see an easy way to make this a defined behavior. FWIW, the OP's code suggests that it makes a more specific test than it does (since -0.0 == 0.0) so the test succeed when n is either -0.0 or 0.0. A quick fix in his code would be to eliminate the -0.0 from the code. def r(n): if n == 0.0: return 0.0 return n or more succinctly: def r(n): return n or 0.0 -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-06-01 00:49 Message: Logged In: YES user_id=33168 Originator: NO This is a regression from 2.4. This seems to always have been undefined behaviour. It looks like it was the result of the compiler changes (code is the same in both versions, but co_consts is diff): Python 2.4.4c1 (#2, Oct 11 2006, 20:00:03) >>> def r(n): ... if n == -0.0: n = 0.0 ... return n ... >>> r.func_code.co_consts (None, 0.0) Python 2.6a0 (trunk, May 30 2007, 21:02:18) >>> def r(n): ... if n == -0.0: n = 0.0 ... return n ... >>> r.func_code.co_consts (None, -0.0) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729014&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
