[ python-Bugs-1757057 ] IDLE + BeautifulSoup = Error
Bugs item #1757057, was opened at 2007-07-19 20:17
Message generated for change (Comment added) made by altherac
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1757057group_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: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tal Einat (taleinat)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE + BeautifulSoup = Error
Initial Comment:
This bug manifests only when running with a subprocess.
Trying to display an instance of BeautifulSoup's NavigableString class, this is
the result:
RuntimeError: maximum recursion depth exceeded
See http://mail.python.org/pipermail/idle-dev/2007-July/002600.html for details
(including how to recreate the error).
Diagnosis: The problem arises when trying to pickle such instances - pickle
enters an endless loop and reaches the max recursion limit (eventually). This
happens regardless of the protocol used.
IDLE is probably trying to pickle them because their class, NavigableString,
inherits from unicode, so isinstance(NavigableString instance, basestring)
return True.
Possibly related to SF bug #1581183: pickle protocol 2 failure on int subclass
http://sourceforge.net/tracker/index.php?funchttp://sourceforge.net/tracker/index.php?func=detailaid=1581183group_id=5470atid=105470=detailaid=1512695group_id=5470atid=105470
Fix: IDLE should check for any exception when trying to pickle, not just
pickle.PicklingError, to avoid such errors. If pickle doesn't work, for
whatever reason, IDLE can still work around it with str() and repr().
I'll post a bug report for Pickle as well.
--
Comment By: Christophe Michel (altherac)
Date: 2007-08-23 16:00
Message:
Logged In: YES
user_id=562686
Originator: NO
Let's use the following sample code. It's the most minimalistic one, and
isolates the cause of the bug.
--8--8--
#!/usr/bin/env python
import pickle, sys
class EvilString(unicode):
def __unicode__(self):
return self
n = EvilString()
pickle.dump(n, sys.stdout)
--8--8--
The evil recursion proceeds as follows :
File C:\Python25\lib\pickle.py, line 1364, in dump
Pickler(file, protocol).dump(obj)
Initial call to dump(), as intended.
File C:\Python25\lib\pickle.py, line 224, in dump
self.save(obj)
save() calls obj.__reduce_ex(), obj being our EvilString instance.
This function is defined in copyreg.py, line 58 and following my example,
returns a tuple containing three elements:
1) the _reconstructor function, as defined in copyreg.py, line 46
2) a tuple : (class '__main__.EvilString', type 'unicode',
'__main__.EvilString' instance at 0x)
First element is the actual class of obj, second is the base class, and
third is the current instance (known as state).
3) an empty dict {}
File C:\Python25\lib\pickle.py, line 331, in save
self.save_reduce(obj=obj, *rv)
save_reduce() calls self.save() twice:
- first on the func argument, which is the _reconstructor function. This
call works as intended
- next on the tuple (class '__main__.EvilString', type 'unicode',
'__main__.EvilString' instance at 0x)
File C:\Python25\lib\pickle.py, line 403, in save_reduce
save(args)
File C:\Python25\lib\pickle.py, line 286, in save
f(self, obj) # Call unbound method with explicit self
save() finds out its argument is a Tuple, and calls save_tuple()
appropriately
File C:\Python25\lib\pickle.py, line 564, in save_tuple
save(element)
... and save_tuple() calls save() on each element of the tuple.
See what's wrong ?
This means calling save() again on the EvilString instance. Which, in
turn, will call save_reduce() on it, and so on.
The problem lies in _reduce_ex(), in the definition of the state of the
object:
copyreg.py, lines 65 to 70:
if base is object:
state = None
else:
if base is self.__class__:
raise TypeError, can't pickle %s objects % base.__name__
state = base(self)
When this code gets executed on an EvilString instance, base is the type
'unicode'.
Since it's not an object, and since it's not the actual class EvilString
either, the following line gets executed:
state=base(self)
Which corresponds to unicode(self), or self.__unicode__, which returns an
EvilString instance, not a variable of type unicode.
And there starts the recursion.
I don't know if this is flaw in the design of _reduce_ex, or a flaw
inherent to having __unicode__(self) returning self.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1757057group_id=5470
___
Python
[ python-Bugs-1757062 ] Pickle fails on BeautifulSoup's navigableString instances
Bugs item #1757062, was opened at 2007-07-19 20:23
Message generated for change (Comment added) made by altherac
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1757062group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tal Einat (taleinat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickle fails on BeautifulSoup's navigableString instances
Initial Comment:
Trying to pickle an instance of BeautifulSoup's NavigableString class, this is
the result:
RuntimeError: maximum recursion depth exceeded
Diagnosis: The problem arises when trying to pickle such instances - pickle
enters an endless loop and reaches the max recursion limit (eventually). This
happens regardless of the protocol used.
Possibly related to SF bug #1581183: pickle protocol 2 failure on int subclass
http://sourceforge.net/tracker/index.php?funchttp://sourceforge.net/tracker/index.php?func=detailaid=1581183group_id=5470atid=105470=detailaid=1512695group_id=5470atid=105470
See http://mail.python.org/pipermail/idle-dev/2007-July/002600.html (originally
a bug report for IDLE on the IDLE-dev list) for details (including how to
recreate the error).
Related IDLE bug report: #1757057
https://sourceforge.net/tracker/?func=detailatid=105470aid=1757057group_id=5470
--
Comment By: Christophe Michel (altherac)
Date: 2007-08-23 16:02
Message:
Logged In: YES
user_id=562686
Originator: NO
Let's use the following sample code. It's the most minimalistic one, and
isolates the cause of the bug.
--8--8--
#!/usr/bin/env python
import pickle, sys
class EvilString(unicode):
def __unicode__(self):
return self
n = EvilString()
pickle.dump(n, sys.stdout)
--8--8--
The evil recursion proceeds as follows :
File C:\Python25\lib\pickle.py, line 1364, in dump
Pickler(file, protocol).dump(obj)
Initial call to dump(), as intended.
File C:\Python25\lib\pickle.py, line 224, in dump
self.save(obj)
save() calls obj.__reduce_ex(), obj being our EvilString instance.
This function is defined in copyreg.py, line 58 and following my example,
returns a tuple containing three elements:
1) the _reconstructor function, as defined in copyreg.py, line 46
2) a tuple : (class '__main__.EvilString', type 'unicode',
'__main__.EvilString' instance at 0x)
First element is the actual class of obj, second is the base class, and
third is the current instance (known as state).
3) an empty dict {}
File C:\Python25\lib\pickle.py, line 331, in save
self.save_reduce(obj=obj, *rv)
save_reduce() calls self.save() twice:
- first on the func argument, which is the _reconstructor function. This
call works as intended
- next on the tuple (class '__main__.EvilString', type 'unicode',
'__main__.EvilString' instance at 0x)
File C:\Python25\lib\pickle.py, line 403, in save_reduce
save(args)
File C:\Python25\lib\pickle.py, line 286, in save
f(self, obj) # Call unbound method with explicit self
save() finds out its argument is a Tuple, and calls save_tuple()
appropriately
File C:\Python25\lib\pickle.py, line 564, in save_tuple
save(element)
... and save_tuple() calls save() on each element of the tuple.
See what's wrong ?
This means calling save() again on the EvilString instance. Which, in
turn, will call save_reduce() on it, and so on.
The problem lies in _reduce_ex(), in the definition of the state of the
object:
copyreg.py, lines 65 to 70:
if base is object:
state = None
else:
if base is self.__class__:
raise TypeError, can't pickle %s objects % base.__name__
state = base(self)
When this code gets executed on an EvilString instance, base is the type
'unicode'.
Since it's not an object, and since it's not the actual class EvilString
either, the following line gets executed:
state=base(self)
Which corresponds to unicode(self), or self.__unicode__, which returns an
EvilString instance, not a variable of type unicode.
And there starts the recursion.
I don't know if this is flaw in the design of _reduce_ex, or a flaw
inherent to having __unicode__(self) returning self.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1757062group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1778207 ] rounding inconsisntency using string formatting
Bugs item #1778207, was opened at 2007-08-21 01:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1778207group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Jim Hurlburt (jim_hurlburt) Assigned to: Nobody/Anonymous (nobody) Summary: rounding inconsisntency using string formatting Initial Comment: Sirs: Using python to generate a text file for transfer of data between systems, I seem to be getting inconsistent rounding results using a text formatting string Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 print %9.4f % (229.0 * .325,)- 74.4250 correct print %9.2f % (round(74.425, 2),)- 74.43 correct print %9.2f % (74.425,) - 74.42 wrong print %9.2f % (167.255,) -167.26 correct print %9.2f % (167.2551,)-167.26 correct print %9.2f % (167.2549,)-167.25 correct It appears as if the string formatting code is a bit flakey. Perhaps working in binary with too small a precision? For a bit I thought it might be Round even up, odd down at the .005 break, but that doesn't appear to be the case. Now that I know it's there, I can do a workaround. Seems as if it deserves a fix or at least a document notation of the problem. Thanks in advance, Jim Hurlburt Atrium Windows and Doors Yakima, WA -- Comment By: Martin v. Löwis (loewis) Date: 2007-08-22 08:01 Message: Logged In: YES user_id=21627 Originator: NO As marketdickinson explains, this is not a bug - at least the line you consider wrong does not show a bug. 74.425 is indeed smaller than 74+425/1000, so it's correct that rounding rounds down. As for documentation, please take a look at http://www.python.org/doc/faq/general/#why-are-floating-point-calculations-so-inaccurate Closing as invalid. -- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-21 03:02 Message: Logged In: YES user_id=703403 Originator: NO This isn't really a bug---it's just one of those unavoidable things that happens when you're representing decimals using binary floating point: take a look at section 4.3 of the General Python FAQ: http://www.python.org/doc/faq/general/ If anything *is* wrong here it's actually the round() result, not the string formatting: 74.425 isn't exactly representable as a binary floating-point number, so Python (like most other languages) approximates it by the closest number that *is* exactly representable, which is (on my machine and probably yours too): 74.42499971578290569595992565155029296875 Since this is less than 74.425, the round function would, in an ideal world, round this down to 74.42 instead of up to 74.43. In the absence of an ideal world, making this sort of thing happen reliably and portably is hard, and I'd guess that round() is unlikely to change. Have you looked at the decimal module in the standard library? It sounds as though you might find it useful. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1778207group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1089974 ] mmap missing offset parameter
Bugs item #1089974, was opened at 2004-12-23 03:22 Message generated for change (Comment added) made by huangpeng You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1089974group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Y Knight (foom) Assigned to: A.M. Kuchling (akuchling) Summary: mmap missing offset parameter Initial Comment: For some reason, the author of the MMap module didn't see fit to expose the offset parameter of the mmap syscall to python. It would be really nice if it had that. Currently, it's always set to 0. m_obj-data = mmap(NULL, map_size, prot, flags, fd, 0); -- Comment By: Huang Peng (huangpeng) Date: 2007-08-22 14:36 Message: Logged In: YES user_id=1767524 Originator: NO I need map a file large than 4G in my program, But it is impossible in an 32bit system. So I need use offset parameter to map specified part of the file. I want to know when python will expose the offset parameter to us. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-05 14:05 Message: Logged In: YES user_id=33168 The patch just needs some attention (testing and possible fixes) on Windows. -- Comment By: George Yoshida (quiver) Date: 2004-12-29 13:54 Message: Logged In: YES user_id=671362 There's already a patch for this request: http://www.python.org/sf/708374 add offset to mmap The rationale is same. It's almost ready to be committed but has been left out for a year now. So give it a second chance. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-29 07:51 Message: Logged In: YES user_id=341410 I would, but I don't know the slightest about the C-level mmap internals on any platform, and spending the last hour looking through Python's mmap.c hasn't made me any more informed. James (or anyone else who reads this), are you able? -- Comment By: A.M. Kuchling (akuchling) Date: 2004-12-29 04:34 Message: Logged In: YES user_id=11375 Would either of you care to provide a patch adding the parameter? I'll review it... -- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-24 00:57 Message: Logged In: YES user_id=341410 I agree. Having access to the offset parameter would be quite convenient, at least to some who use mmap in a nontrivial fashion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1089974group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1089974 ] mmap missing offset parameter
Bugs item #1089974, was opened at 2004-12-23 03:22 Message generated for change (Comment added) made by huangpeng You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1089974group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Y Knight (foom) Assigned to: A.M. Kuchling (akuchling) Summary: mmap missing offset parameter Initial Comment: For some reason, the author of the MMap module didn't see fit to expose the offset parameter of the mmap syscall to python. It would be really nice if it had that. Currently, it's always set to 0. m_obj-data = mmap(NULL, map_size, prot, flags, fd, 0); -- Comment By: Huang Peng (huangpeng) Date: 2007-08-22 14:38 Message: Logged In: YES user_id=1767524 Originator: NO I need map a file large than 4G in my program, But it is impossible in an 32bit system. So I need use offset parameter to map specified part of the file. I want to know when python will expose the offset parameter to us. -- Comment By: Huang Peng (huangpeng) Date: 2007-08-22 14:36 Message: Logged In: YES user_id=1767524 Originator: NO I need map a file large than 4G in my program, But it is impossible in an 32bit system. So I need use offset parameter to map specified part of the file. I want to know when python will expose the offset parameter to us. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-05 14:05 Message: Logged In: YES user_id=33168 The patch just needs some attention (testing and possible fixes) on Windows. -- Comment By: George Yoshida (quiver) Date: 2004-12-29 13:54 Message: Logged In: YES user_id=671362 There's already a patch for this request: http://www.python.org/sf/708374 add offset to mmap The rationale is same. It's almost ready to be committed but has been left out for a year now. So give it a second chance. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-29 07:51 Message: Logged In: YES user_id=341410 I would, but I don't know the slightest about the C-level mmap internals on any platform, and spending the last hour looking through Python's mmap.c hasn't made me any more informed. James (or anyone else who reads this), are you able? -- Comment By: A.M. Kuchling (akuchling) Date: 2004-12-29 04:34 Message: Logged In: YES user_id=11375 Would either of you care to provide a patch adding the parameter? I'll review it... -- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-12-24 00:57 Message: Logged In: YES user_id=341410 I agree. Having access to the offset parameter would be quite convenient, at least to some who use mmap in a nontrivial fashion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1089974group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1779233 ] PyThreadState_SetAsyncExc and the main thread
Bugs item #1779233, was opened at 2007-08-22 10:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1779233group_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: Threads Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rotem (rotem_yaari) Assigned to: Nobody/Anonymous (nobody) Summary: PyThreadState_SetAsyncExc and the main thread Initial Comment: Hi, The following does not work in python 2.5: ## import ctypes import thread res = ctypes.pythonapi.PyThreadState_SetAsyncExc( thread.get_ident(), ctypes.py_object(SystemExit)) ## Although according to my understanding this should schedule an async exception for the main thread, it does not (res receives the value of 0). When raising exceptions in other threads in this way, it works and the call to PyThreadState_SetAsyncExc returns 1 like it should. Doing so on the main thread doesn't seem to work, even when performed from threads other than the main one. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1779233group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1776160 ] Buffer overflow when listing deeply nested directory
Bugs item #1776160, was opened at 2007-08-17 13:24 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1776160group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj�rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overflow when listing deeply nested directory Initial Comment: This code: import os import os.path TARGET='C:/code/python/foo' base = TARGET for x in range(200): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base Produces a TypeError (buffer overflow) when run on a to deeply nested directory for windows to handle: .. more output here.. C:code/python/foo\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.p ng\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png Traceback (most recent call last): File killdir.py, line 6, in module subdirs = os.listdir(base) TypeError: listdir() argument 1 must be (buffer overflow), not str -- Comment By: Bj�rn Lindqvist (sonderblade) Date: 2007-08-22 12:26 Message: Logged In: YES user_id=51702 Originator: YES Yes, it is the error message and the exception that is the problem. First, it shouldn't raise TypeError (which indicates a programming error), it should raise either IOError, OSError or WindowsError. Second, the exception message is whacky: listdir() argument 1 must be (buffer overflow), not str I realize that it is probably impossible to detect this specific error condition but I still want something more explanatory than what it currently is. -- Comment By: Martin v. Löwis (loewis) Date: 2007-08-22 07:56 Message: Logged In: YES user_id=21627 Originator: NO Can you please explain what specifically you consider a bug here? I can see that the error message is confusing, so it could be improved. However, there is nothing we can do to make the error go away. The Microsoft C library simply does not support file names longer than MAX_PATH; you have to use Unicode file names to go beyond this limit. -- Comment By: Bj�rn Lindqvist (sonderblade) Date: 2007-08-21 10:49 Message: Logged In: YES user_id=51702 Originator: YES Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 MS Windows XP, Version 5.1, SP2 -- Comment By: Martin v. Löwis (loewis) Date: 2007-08-21 10:18 Message: Logged In: YES user_id=21627 Originator: NO To rephrase Skip's comment: Can you please report what operating system and Python version you are using? -- Comment By: Skip Montanaro (montanaro) Date: 2007-08-18 13:38 Message: Logged In: YES user_id=44345 Originator: NO Worked as expected for me on Mac OS X 10.4.10 running from the trunk (you didn't mention what version you were using). In ~/tmp/deep I created a maximally nested directory tree from the shell like so: cd /Users/skip/tmp/deep for i in `range 1000` ; do x=`printf %04d $i` echo $x mkdir $x cd $x done where the range command is analogous to Python's range builtin: % range 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 The for loop barfed after making directory 0205. In Python I then executed these statements: import os.path base = /Users/skip/tmp/deep for x in range(210): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base This went until it got to dir 0200 where it raised an OSError: [Errno 63] File name too long: '/Users/skip/tmp/deep//0001/.../0199/0200' which stands to reason since base was 1025 characters long at that point. MAXPATHLEN is defined to be 1024 on my system, so the OSError is to be expected. Skip -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1776160group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1731717 ] race condition in subprocess module
Bugs item #1731717, was opened at 2007-06-06 00:19 Message generated for change (Comment added) made by gjb1002 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1731717group_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: dsagal (dsagal) Assigned to: Peter Åstrand (astrand) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global _cleanup() function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object foo in one thread, and then a.wait(), and meanwhile I create another Popen object bar in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen((/bin/ls, -a, /tmp), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: Traceback (most recent call last): File /usr/lib/python2.4/threading.py, line 442, in __bootstrap self.run() File /usr/lib/python2.4/threading.py, line 422, in run self.__target(*self.__args, **self.__kwargs) File z.py, line 21, in tt s.communicate()[0] File /usr/lib/python2.4/subprocess.py, line 1083, in communicate self.wait() File /usr/lib/python2.4/subprocess.py, line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. -- Comment By: Geoffrey Bache (gjb1002) Date: 2007-08-22 19:53 Message: Logged In: YES user_id=769182 Originator: NO There should be test cases aplenty - this bug was first reported in March 2006 and this is one of four incarnations of it. See also 1753891, 1754642, 1183780 I think all of these contain testcases (though two roughly coincide) and any fix would be wise to try them all out... -- Comment By: Peter Åstrand (astrand) Date: 2007-08-06 22:02 Message: Logged In: YES user_id=344921 Originator: NO I can create a patch to make current head a bit cleaner, if anyone is interested... Sure, this would be great. I would also love a test case that reproduces this problem. -- Comment By: Donovan Baarda (abo) Date: 2007-08-06 21:45 Message: Logged In: YES user_id=10273 Originator: NO I can create a patch to make current head a bit cleaner, if anyone is interested... -- Comment By: Donovan Baarda (abo) Date: 2007-08-03 23:29 Message: Logged In: YES user_id=10273 Originator: NO I just looked at subprocess in svs trunk and it looks like it might already be fixed in both subprocess.py and popen2.py. The part where __del__() adds abandoned Popen instances to _active and _cleanup() removes them is already there. _cleanup() has been made more thread resistant by catching and ignoring exceptions that arise when two _cleanups() try to remove the same instances. Popen.poll() has been made more robust by having it set self.returncode to an optional _deadstate argument value when poll gets an os.error from os.pidwait() on a child that gets cleaned up by another thread. I think there are still a few minor race conditions around Popen.poll(), but it will only affect what non-zero returncode you get... it's not so much thread safe as thread robust. I think the _deadstate argument approach to try and make Popen.poll() thread-robust is a bit hacky. I would rather see _cleanup() be properly threadsafe by having it remove the inst from _active before processing it and re-adding it back
[ python-Bugs-1779700 ] urlparse.urljoin does not obey current uri rfc (rfc 3986)
Bugs item #1779700, was opened at 2007-08-22 12:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1779700group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Adams (icosine) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse.urljoin does not obey current uri rfc (rfc 3986) Initial Comment: First, there are a lot of RFC's. The latest is RFC3986 (see http://en.wikipedia.org/wiki/Uniform_Resource_Identifier) A base url of the form: http://a/b/c/d;p?q when resolved with a relative link of the form: ?y resolves to: http://a/b/c/?q rather than: http://a/b/c/d;p?q It may seem that this doesn't matter, but try this in firefox or IE and you'll see that they exhibit the up-to-date correct behavior. Thanks! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1779700group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777160 ] Please warn about a subtle trap
Bugs item #1777160, was opened at 2007-08-19 10:25 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777160group_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: Feature Request Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: Please warn about a subtle trap Initial Comment: In python, -1**2 is -1.This will horribly surprise most mathematicians or C programmers where unary - binds very tightly. Such people will expect -1**2 == 1. This problem shows up in scientific contexts, especially Numpy, where an easy way to generate an alternating string of positive and negative numbers is -1**numpy.arange(10). In this example, one expects to produce [1, -1, 1, -1, ...]. So, please put a note in the documentation warning of this problem. It can lead to subtly wrong computations. The appropriate place to put the note is in the Python Reference Manual, section 5.4, The Power operator. Please insert a final line saying: Note: since the minus sign is not part of a numeric literal, powers of negative numeric constants need to be written with parentheses. Be aware that -1**2 == -(1**2), not (-1)**2. -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-21 06:07 Message: Logged In: YES user_id=849994 Originator: NO Thanks, fixed in rev. 57255. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777160group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777168 ] Confusing typography Python Ref 5.9
Bugs item #1777168, was opened at 2007-08-19 10:40 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777168group_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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: Confusing typography Python Ref 5.9 Initial Comment: In the python reference manual, section 5.9, all that stuff with italic opa, opb etc reads rather poorly because of a visually confusing choice of names. The bit about ...then a opa b opb c ... y opy z opz looks more like aopabopbcopc...yopyzopz : in other words a unintelligible string of gibberish. A similar problem occurs slightly below. Note that the spaces *are* really there, but they do not show up well in the italic font used on my Firefox/Debian system, so it's hard to parse. The visual confusion is exacerbated by the similarities in the operator and variable names (e.g. opa and a, then opb then b), and also by the use of a three-character string to mean operator a versus a one-character name for the variable. So, please change opa to A et cetera, or make some other change that makes it easier to read. -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-21 06:12 Message: Logged In: YES user_id=849994 Originator: NO Thanks, fixed in rev. 57256. -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-21 06:12 Message: Logged In: YES user_id=849994 Originator: NO Thanks, fixed in rev. 57256. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777168group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777168 ] Confusing typography Python Ref 5.9
Bugs item #1777168, was opened at 2007-08-19 10:40 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777168group_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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: Confusing typography Python Ref 5.9 Initial Comment: In the python reference manual, section 5.9, all that stuff with italic opa, opb etc reads rather poorly because of a visually confusing choice of names. The bit about ...then a opa b opb c ... y opy z opz looks more like aopabopbcopc...yopyzopz : in other words a unintelligible string of gibberish. A similar problem occurs slightly below. Note that the spaces *are* really there, but they do not show up well in the italic font used on my Firefox/Debian system, so it's hard to parse. The visual confusion is exacerbated by the similarities in the operator and variable names (e.g. opa and a, then opb then b), and also by the use of a three-character string to mean operator a versus a one-character name for the variable. So, please change opa to A et cetera, or make some other change that makes it easier to read. -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-21 06:12 Message: Logged In: YES user_id=849994 Originator: NO Thanks, fixed in rev. 57256. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777168group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1777412 ] Python's strftime dislikes years before 1900
Feature Requests item #1777412, was opened at 2007-08-20 05:36
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=355470aid=1777412group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Benno Rice (benno)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python's strftime dislikes years before 1900
Initial Comment:
Python 2.5 (r25:51918, Sep 19 2006, 08:49:13)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type help, copyright, credits or license for more information.
import datetime
datetime.date(1876, 2, 3).strftime('%Y-%m-%d')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: year=1876 is before 1900; the datetime strftime() methods require
year = 1900
Apparently this is due to platform-specific weirdnesses in implementations of
strftime. It is still very annoying however. Perhaps a good implementation of
strftime could be found and incorporated into Python itself?
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-08-21 10:15
Message:
Logged In: YES
user_id=21627
Originator: NO
This is not a bug report, but a feature request. Python works correctly
as-is.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=355470aid=1777412group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1776160 ] Buffer overflow when listing deeply nested directory
Bugs item #1776160, was opened at 2007-08-17 13:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1776160group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj�rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overflow when listing deeply nested directory Initial Comment: This code: import os import os.path TARGET='C:/code/python/foo' base = TARGET for x in range(200): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base Produces a TypeError (buffer overflow) when run on a to deeply nested directory for windows to handle: .. more output here.. C:code/python/foo\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.p ng\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png Traceback (most recent call last): File killdir.py, line 6, in module subdirs = os.listdir(base) TypeError: listdir() argument 1 must be (buffer overflow), not str -- Comment By: Martin v. Löwis (loewis) Date: 2007-08-21 10:18 Message: Logged In: YES user_id=21627 Originator: NO To rephrase Skip's comment: Can you please report what operating system and Python version you are using? -- Comment By: Skip Montanaro (montanaro) Date: 2007-08-18 13:38 Message: Logged In: YES user_id=44345 Originator: NO Worked as expected for me on Mac OS X 10.4.10 running from the trunk (you didn't mention what version you were using). In ~/tmp/deep I created a maximally nested directory tree from the shell like so: cd /Users/skip/tmp/deep for i in `range 1000` ; do x=`printf %04d $i` echo $x mkdir $x cd $x done where the range command is analogous to Python's range builtin: % range 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 The for loop barfed after making directory 0205. In Python I then executed these statements: import os.path base = /Users/skip/tmp/deep for x in range(210): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base This went until it got to dir 0200 where it raised an OSError: [Errno 63] File name too long: '/Users/skip/tmp/deep//0001/.../0199/0200' which stands to reason since base was 1025 characters long at that point. MAXPATHLEN is defined to be 1024 on my system, so the OSError is to be expected. Skip -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1776160group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed
Bugs item #1772916, was opened at 2007-08-13 10:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772916group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Fredrik Lundh (effbot) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called sgmlop if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). -- Comment By: Martin v. Löwis (loewis) Date: 2007-08-21 10:27 Message: Logged In: YES user_id=21627 Originator: NO Fredrik, can you please comment? If not, unassign. -- Comment By: lplatypus (ldeller) Date: 2007-08-14 08:23 Message: Logged In: YES user_id=1534394 Originator: YES Yes the standalone sgmlop-1.1.1 looks fine: in its sgmlop.c I can see that matching allocator and deallocator functions are used. I installed PyXML-0.8.4 from source (python setup.py install on Win32 which picked up the C compiler from MSVS7.1). The cause of the problem is quite visible in the PyXML source code (see that PyObject_NEW and PyMem_DEL are used together): http://pyxml.cvs.sourceforge.net/pyxml/xml/extensions/sgmlop.c?view=markup Interestingly PyXML-0.8.4 was released more recently than sgmlop-1.1.1. I guess they weren't keeping in sync with each other. -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-14 05:32 Message: Logged In: YES user_id=1115903 Originator: NO I tried out xmlrpclib on the trunk (2.6) with sgmlop-1.1.1 and it works just fine. At the moment I don't have time to try out PyXML, but seeing that the most recent sgmlop works with xmlrpclib makes me lean towards not removing sgmlop support (not that I have a say about it, but still). How did you install PyXML? If it wasn't from source or from an installer compiled for 2.5, that might be a problem. If PyXML installed from source or compiled for 2.5 still causes this problem, it could be that it needs to be updated to the current sgmlop. -- Comment By: lplatypus (ldeller) Date: 2007-08-14 03:07 Message: Logged In: YES user_id=1534394 Originator: YES Choice of XML parser is an implementation detail of xmlrpclib not visible to users of the module. This change would not affect the behaviour of xmlrpclib (other than to fix a crash introduced in Python 2.5). Does this mean that a DeprecationWarning would not be necessary? Does it also mean that the fix might qualify for the maintenance branch? Adding a DeprecationWarning in 2.6 without removing use of sgmlop is pointless, because the DeprecationWarning would be followed by a process crash anyway. -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 13:06 Message: Logged In: YES user_id=1115903 Originator: NO I'm assuming that stuff won't be removed from 2.5 because it's in maintenance, so should this be removed or changed to raise a deprecation warning in 2.6? As an aside, how about removing references to _xmlrpclib (which appears to have been removed long ago) as well? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772916group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1778376 ] Segfault.
Bugs item #1778376, was opened at 2007-08-21 10:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1778376group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Maciek Fijalkowski (fijal) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault. Initial Comment: On linux box this piece of code segfaults (CPy 2.5.1) while 1: f = open(/tmp/dupa, w) thread.start_new_thread(f.close, ()) f.close() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1778376group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed
Bugs item #1772916, was opened at 2007-08-13 10:15 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772916group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called sgmlop if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). -- Comment By: Fredrik Lundh (effbot) Date: 2007-08-21 10:43 Message: Logged In: YES user_id=38376 Originator: NO I don't really have an opinion here; the best solution would of course be to find someone that cares enough about PyXML to cut a bugfix release, it's probably easiest to just remove it (or disable, with a note that it can be re-enabled if you have a stable version of sgmlop). I'm tempted to suggest removing SlowParser as well, but there might be some hackers on very small devices that rely on that one. (Ideally, someone should sit down and rewrite the Unmarshaller to use xml.etree.cElementTree's iterparse function instead. Contact me if you're interested). -- Comment By: Martin v. Löwis (loewis) Date: 2007-08-21 10:27 Message: Logged In: YES user_id=21627 Originator: NO Fredrik, can you please comment? If not, unassign. -- Comment By: lplatypus (ldeller) Date: 2007-08-14 08:23 Message: Logged In: YES user_id=1534394 Originator: YES Yes the standalone sgmlop-1.1.1 looks fine: in its sgmlop.c I can see that matching allocator and deallocator functions are used. I installed PyXML-0.8.4 from source (python setup.py install on Win32 which picked up the C compiler from MSVS7.1). The cause of the problem is quite visible in the PyXML source code (see that PyObject_NEW and PyMem_DEL are used together): http://pyxml.cvs.sourceforge.net/pyxml/xml/extensions/sgmlop.c?view=markup Interestingly PyXML-0.8.4 was released more recently than sgmlop-1.1.1. I guess they weren't keeping in sync with each other. -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-14 05:32 Message: Logged In: YES user_id=1115903 Originator: NO I tried out xmlrpclib on the trunk (2.6) with sgmlop-1.1.1 and it works just fine. At the moment I don't have time to try out PyXML, but seeing that the most recent sgmlop works with xmlrpclib makes me lean towards not removing sgmlop support (not that I have a say about it, but still). How did you install PyXML? If it wasn't from source or from an installer compiled for 2.5, that might be a problem. If PyXML installed from source or compiled for 2.5 still causes this problem, it could be that it needs to be updated to the current sgmlop. -- Comment By: lplatypus (ldeller) Date: 2007-08-14 03:07 Message: Logged In: YES user_id=1534394 Originator: YES Choice of XML parser is an implementation detail of xmlrpclib not visible to users of the module. This change would not affect the behaviour of xmlrpclib (other than to fix a crash introduced in Python 2.5). Does this mean that a DeprecationWarning would not be necessary? Does it also mean that the fix might qualify for the maintenance branch? Adding a DeprecationWarning in 2.6 without removing use of sgmlop is pointless, because the DeprecationWarning would be followed by a process crash anyway. -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 13:06 Message: Logged In: YES user_id=1115903 Originator: NO I'm assuming that stuff won't be removed from 2.5 because it's in maintenance, so should this be removed or changed to raise a deprecation warning in 2.6? As an aside, how about removing references to _xmlrpclib (which appears to have been removed long ago) as well? -- You can respond
[ python-Bugs-1772788 ] chr(128) in u'only ascii' - TypeError with misleading msg
Bugs item #1772788, was opened at 2007-08-13 00:54 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772788group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Laukkanen (laukpe) Assigned to: Nobody/Anonymous (nobody) Summary: chr(128) in u'only ascii' - TypeError with misleading msg Initial Comment: A test using in format chr(x) in string raises a TypeError if x is in range 128-255 (i.e. non-ascii) and string is unicode. This happens even if the unicode string contains only ascii data as the example below demonstrates. Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type help, copyright, credits or license for more information. chr(127) in 'hello' False chr(128) in 'hello' False chr(127) in u'hi' False chr(128) in u'hi' Traceback (most recent call last): File stdin, line 1, in module TypeError: 'in string' requires string as left operand This can cause pretty nasty and hard-to-debug bugs in code using in string format if e.g. user provided data is converted to unicode internally. Most other string operations work nicely between normal and unicode strings and I'd say simply returning False in this situation would be ok too. Issuing a warning similarly as below might be a good idea also. chr(128) == u'' __main__:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal Finally, the error message is somewhat misleading since the left operand is definitely a string. type(chr(128)) type 'str' A real life example of code where this problem exist is telnetlib. I'll submit a separate bug about it as that problem can obviously be fixed in the library itself. -- Comment By: Fredrik Lundh (effbot) Date: 2007-08-21 10:48 Message: Logged In: YES user_id=38376 Originator: NO Most other string operations work nicely between normal and unicode strings Nope. You *always* get errors if you mix Unicode with NON-ASCII data (unless you've messed up the system's default encoding, which is a bad thing to do if you care about portability). Some examples: chr(128) + ufoo UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128) ufoo.find(chr(128)) UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128) etc. If there's a bug here, it's that you get a TypeError instead of a ValueError subclass. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772788group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1776160 ] Buffer overflow when listing deeply nested directory
Bugs item #1776160, was opened at 2007-08-17 13:24 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1776160group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj�rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overflow when listing deeply nested directory Initial Comment: This code: import os import os.path TARGET='C:/code/python/foo' base = TARGET for x in range(200): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base Produces a TypeError (buffer overflow) when run on a to deeply nested directory for windows to handle: .. more output here.. C:code/python/foo\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.p ng\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png Traceback (most recent call last): File killdir.py, line 6, in module subdirs = os.listdir(base) TypeError: listdir() argument 1 must be (buffer overflow), not str -- Comment By: Bj�rn Lindqvist (sonderblade) Date: 2007-08-21 10:49 Message: Logged In: YES user_id=51702 Originator: YES Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 MS Windows XP, Version 5.1, SP2 -- Comment By: Martin v. Löwis (loewis) Date: 2007-08-21 10:18 Message: Logged In: YES user_id=21627 Originator: NO To rephrase Skip's comment: Can you please report what operating system and Python version you are using? -- Comment By: Skip Montanaro (montanaro) Date: 2007-08-18 13:38 Message: Logged In: YES user_id=44345 Originator: NO Worked as expected for me on Mac OS X 10.4.10 running from the trunk (you didn't mention what version you were using). In ~/tmp/deep I created a maximally nested directory tree from the shell like so: cd /Users/skip/tmp/deep for i in `range 1000` ; do x=`printf %04d $i` echo $x mkdir $x cd $x done where the range command is analogous to Python's range builtin: % range 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 The for loop barfed after making directory 0205. In Python I then executed these statements: import os.path base = /Users/skip/tmp/deep for x in range(210): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base This went until it got to dir 0200 where it raised an OSError: [Errno 63] File name too long: '/Users/skip/tmp/deep//0001/.../0199/0200' which stands to reason since base was 1025 characters long at that point. MAXPATHLEN is defined to be 1024 on my system, so the OSError is to be expected. Skip -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1776160group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1778376 ] Segfault closing a file from concurrent threads
Bugs item #1778376, was opened at 2007-08-21 08:08 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1778376group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Maciek Fijalkowski (fijal) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault closing a file from concurrent threads Initial Comment: On linux box this piece of code segfaults (CPy 2.5.1) while 1: f = open(/tmp/dupa, w) thread.start_new_thread(f.close, ()) f.close() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1778376group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772788 ] chr(128) in u'only ascii' - TypeError with misleading msg
Bugs item #1772788, was opened at 2007-08-13 01:54 Message generated for change (Comment added) made by laukpe You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772788group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Laukkanen (laukpe) Assigned to: Nobody/Anonymous (nobody) Summary: chr(128) in u'only ascii' - TypeError with misleading msg Initial Comment: A test using in format chr(x) in string raises a TypeError if x is in range 128-255 (i.e. non-ascii) and string is unicode. This happens even if the unicode string contains only ascii data as the example below demonstrates. Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type help, copyright, credits or license for more information. chr(127) in 'hello' False chr(128) in 'hello' False chr(127) in u'hi' False chr(128) in u'hi' Traceback (most recent call last): File stdin, line 1, in module TypeError: 'in string' requires string as left operand This can cause pretty nasty and hard-to-debug bugs in code using in string format if e.g. user provided data is converted to unicode internally. Most other string operations work nicely between normal and unicode strings and I'd say simply returning False in this situation would be ok too. Issuing a warning similarly as below might be a good idea also. chr(128) == u'' __main__:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal Finally, the error message is somewhat misleading since the left operand is definitely a string. type(chr(128)) type 'str' A real life example of code where this problem exist is telnetlib. I'll submit a separate bug about it as that problem can obviously be fixed in the library itself. -- Comment By: Pekka Laukkanen (laukpe) Date: 2007-08-21 17:03 Message: Logged In: YES user_id=1379331 Originator: YES Fredrik, you are obviously correct that most operations between normal and unicode strings don't work if the normal string contains non-ascii data. I still do think that a UnicodeWarning like you get from chr(128) == u'foo' would be nicer than an exception and prevent problems like the one in telnetlib [1]. If an exception is raised I don't care too much about its type but a better message would make debugging possible problems easier. [1] https://sourceforge.net/tracker/index.php?func=detailaid=1772794group_id=5470atid=105470 -- Comment By: Fredrik Lundh (effbot) Date: 2007-08-21 11:48 Message: Logged In: YES user_id=38376 Originator: NO Most other string operations work nicely between normal and unicode strings Nope. You *always* get errors if you mix Unicode with NON-ASCII data (unless you've messed up the system's default encoding, which is a bad thing to do if you care about portability). Some examples: chr(128) + ufoo UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128) ufoo.find(chr(128)) UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128) etc. If there's a bug here, it's that you get a TypeError instead of a ValueError subclass. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772788group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777458 ] glob doesn't return unicode with unicode parameter
Bugs item #1777458, was opened at 2007-08-20 12:38 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777458group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Grzegorz Adam Hankiewicz (gradha) Assigned to: Nobody/Anonymous (nobody) Summary: glob doesn't return unicode with unicode parameter Initial Comment: Unless I'm not understanding a previous bug report, I see this is a regression of http://sourceforge.net/tracker/index.php?func=detailaid=1001604group_id=5470atid=305470. Here's an interactive session with 2.5.1 on WXP: In [1]: import sys In [2]: sys.version Out[2]: '2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)]' In [3]: import glob In [4]: glob.glob(u*txt) Out[4]: ['hola.txt', 'ma\xf1ana.txt'] In [5]: glob.glob(u./*txt) Out[5]: [u'.\\hola.txt', u'.\\ma\xf1ana.txt'] -- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-21 23:01 Message: Logged In: YES user_id=942711 Originator: NO This seems very much windows specific (someone needs to test on mac/other os as well). On linux, verified that glob unicode-in, unicode-out works fine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777458group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-839151 ] attempt to access sys.argv when it doesn\'t exist
Bugs item #839151, was opened at 2003-11-10 02:56 Message generated for change (Comment added) made by ngrover You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=839151group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Bram Moolenaar (vimboss) Assigned to: Georg Brandl (gbrandl) Summary: attempt to access sys.argv when it doesn\'t exist Initial Comment: When using Python as an extension to another program, giving a warning message attempts to access sys.argv while it doesn't exist. The problem can be reproduced with Vim when compiled with Python 2.3. Use these two commands: :py import sys :py print sys.maxint + 1 The problem is caused by the warnings module. In line 53 it accesses sys.argv[0], but for an embedded interpreter this doesn't exist. The suggested fix does an explicit test for the existence of sys.argv. That seems to be the cleanest solution to me. This problem also existed in Python 2.2. I didn't try other versions. -- Comment By: Nishkar Grover (ngrover) Date: 2007-08-21 18:29 Message: Logged In: YES user_id=1656248 Originator: NO In addition to catching AttributeError in case sys.argv doesn't exist, this should also catch IndexError and TypeError in case sys.argv is an empty list or it is not even a list at all. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-06-26 15:55 Message: Logged In: YES user_id=1188172 Thanks for the report; this is fixed as of Lib/warnings.py r1.27, r1.24.2.2. -- Comment By: Nobody/Anonymous (nobody) Date: 2003-11-18 21:23 Message: Logged In: NO Much simplier test: gt;gt;gt; import sys gt;gt;gt; del sys.argv gt;gt;gt; sys.maxint+1 Traceback (most recent call last): File quot;lt;stdingt;quot;, line 1, in ? File quot;D:\development\python22\lib\warnings.pyquot;, line 38, in warn filename = sys.argv[0] AttributeError: 'module' object has no attribute 'argv' -- Comment By: Nobody/Anonymous (nobody) Date: 2003-11-18 21:22 Message: Logged In: NO Much simplier test: gt;gt;gt; import sys gt;gt;gt; del sys.argv gt;gt;gt; sys.maxint+1 Traceback (most recent call last): File quot;lt;stdingt;quot;, line 1, in ? File quot;D:\development\python22\lib\warnings.pyquot;, line 38, in warn filename = sys.argv[0] AttributeError: 'module' object has no attribute 'argv' -- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-10 07:02 Message: Logged In: YES user_id=33168 Just to provide a reference, 839200 was a duplicate of this report. I closed 839200. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=839151group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1776160 ] Buffer overflow when listing deeply nested directory
Bugs item #1776160, was opened at 2007-08-17 13:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1776160group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj�rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overflow when listing deeply nested directory Initial Comment: This code: import os import os.path TARGET='C:/code/python/foo' base = TARGET for x in range(200): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base Produces a TypeError (buffer overflow) when run on a to deeply nested directory for windows to handle: .. more output here.. C:code/python/foo\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.p ng\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png Traceback (most recent call last): File killdir.py, line 6, in module subdirs = os.listdir(base) TypeError: listdir() argument 1 must be (buffer overflow), not str -- Comment By: Martin v. Löwis (loewis) Date: 2007-08-22 07:56 Message: Logged In: YES user_id=21627 Originator: NO Can you please explain what specifically you consider a bug here? I can see that the error message is confusing, so it could be improved. However, there is nothing we can do to make the error go away. The Microsoft C library simply does not support file names longer than MAX_PATH; you have to use Unicode file names to go beyond this limit. -- Comment By: Bj�rn Lindqvist (sonderblade) Date: 2007-08-21 10:49 Message: Logged In: YES user_id=51702 Originator: YES Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 MS Windows XP, Version 5.1, SP2 -- Comment By: Martin v. Löwis (loewis) Date: 2007-08-21 10:18 Message: Logged In: YES user_id=21627 Originator: NO To rephrase Skip's comment: Can you please report what operating system and Python version you are using? -- Comment By: Skip Montanaro (montanaro) Date: 2007-08-18 13:38 Message: Logged In: YES user_id=44345 Originator: NO Worked as expected for me on Mac OS X 10.4.10 running from the trunk (you didn't mention what version you were using). In ~/tmp/deep I created a maximally nested directory tree from the shell like so: cd /Users/skip/tmp/deep for i in `range 1000` ; do x=`printf %04d $i` echo $x mkdir $x cd $x done where the range command is analogous to Python's range builtin: % range 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 The for loop barfed after making directory 0205. In Python I then executed these statements: import os.path base = /Users/skip/tmp/deep for x in range(210): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base This went until it got to dir 0200 where it raised an OSError: [Errno 63] File name too long: '/Users/skip/tmp/deep//0001/.../0199/0200' which stands to reason since base was 1025 characters long at that point. MAXPATHLEN is defined to be 1024 on my system, so the OSError is to be expected. Skip -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1776160group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777530 ] ctypes on Solaris
Bugs item #1777530, was opened at 2007-08-20 02:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777530group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Aki (akineko) Assigned to: Nobody/Anonymous (nobody) Summary: ctypes on Solaris Initial Comment: This is not really a bug. ctypes uses 'objdump', which is not available by default. (There are reasons not to install binutil on Solaris) There is no 'objdump' but Solaris has 'elfdump', instead. ctypes.util.py can use 'elfdump' instead of 'objdump'. #cmd = objdump -p -j .dynamic 2/dev/null + f cmd = elfdump -d 2/dev/null + f #res = re.search(r'\sSONAME\s+([^\s]+)', os.popen(cmd).read()) res = re.search(r'\sSONAME\s+([^\s]+)\s+([^\s]+)', os.popen(cmd).read())if not res: return None return res.group(2) # --- // ./Modules/_ctypes/libffi/config.guess also uses objdump so that file probably needs to be updated as well. Thank you for your attention. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777530group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777458 ] glob doesn't return unicode with unicode parameter
Bugs item #1777458, was opened at 2007-08-20 09:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777458group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Grzegorz Adam Hankiewicz (gradha) Assigned to: Nobody/Anonymous (nobody) Summary: glob doesn't return unicode with unicode parameter Initial Comment: Unless I'm not understanding a previous bug report, I see this is a regression of http://sourceforge.net/tracker/index.php?func=detailaid=1001604group_id=5470atid=305470. Here's an interactive session with 2.5.1 on WXP: In [1]: import sys In [2]: sys.version Out[2]: '2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)]' In [3]: import glob In [4]: glob.glob(u*txt) Out[4]: ['hola.txt', 'ma\xf1ana.txt'] In [5]: glob.glob(u./*txt) Out[5]: [u'.\\hola.txt', u'.\\ma\xf1ana.txt'] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777458group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1759845 ] subprocess.call fails with unicode strings in command line
Bugs item #1759845, was opened at 2007-07-24 14:24
Message generated for change (Comment added) made by mclausch
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1759845group_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: Matt (mclausch)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.call fails with unicode strings in command line
Initial Comment:
On Windows, subprocess.call() fails with an exception if either the executable
or any of the arguments contain upper level characters. See below:
cmd = [ u'test_\xc5_exec.bat', u'arg1', u'arg2' ]
subprocess.call(cmd)
Traceback (most recent call last):
File stdin, line 1, in module
File C:\Python25\lib\subprocess.py, line 443, in call
return Popen(*popenargs, **kwargs).wait()
File C:\Python25\lib\subprocess.py, line 593, in __init__
errread, errwrite)
File C:\Python25\lib\subprocess.py, line 815, in _execute_child
startupinfo)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xc5' in position 5:
ordinal not in range(128)
--
Comment By: Matt (mclausch)
Date: 2007-08-20 17:12
Message:
Logged In: YES
user_id=1852547
Originator: YES
Sorry, I should have been more specific. I'm looking for a general
solution, not just one for characters in iso-8859-1. For instance, I need
to execute a subprocess where the executable or the arguments may contain
Japanese characters.
So another example would be:
cmd = [ u'test_\u65e5\u672c\u8a9e_exec.bat', u'arg1', u'arg2' ]
subprocess.call(cmd)
--
Comment By: brotchie (brotch)
Date: 2007-08-05 04:36
Message:
Logged In: YES
user_id=1860608
Originator: NO
Python's default character coding is 'ascii' which can't convert unicode
127 into chars.
Forcing the unicode string to encode as 'iso-8859-1'
eg.
subprocess.call(cmd.encode('iso-8859-1'))
resolves the problem and runs the correct command.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1759845group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1778207 ] rounding inconsisntency using string formatting
Bugs item #1778207, was opened at 2007-08-20 16:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1778207group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Hurlburt (jim_hurlburt) Assigned to: Nobody/Anonymous (nobody) Summary: rounding inconsisntency using string formatting Initial Comment: Sirs: Using python to generate a text file for transfer of data between systems, I seem to be getting inconsistent rounding results using a text formatting string Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 print %9.4f % (229.0 * .325,)- 74.4250 correct print %9.2f % (round(74.425, 2),)- 74.43 correct print %9.2f % (74.425,) - 74.42 wrong print %9.2f % (167.255,) -167.26 correct print %9.2f % (167.2551,)-167.26 correct print %9.2f % (167.2549,)-167.25 correct It appears as if the string formatting code is a bit flakey. Perhaps working in binary with too small a precision? For a bit I thought it might be Round even up, odd down at the .005 break, but that doesn't appear to be the case. Now that I know it's there, I can do a workaround. Seems as if it deserves a fix or at least a document notation of the problem. Thanks in advance, Jim Hurlburt Atrium Windows and Doors Yakima, WA -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1778207group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1778207 ] rounding inconsisntency using string formatting
Bugs item #1778207, was opened at 2007-08-20 23:20 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1778207group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Hurlburt (jim_hurlburt) Assigned to: Nobody/Anonymous (nobody) Summary: rounding inconsisntency using string formatting Initial Comment: Sirs: Using python to generate a text file for transfer of data between systems, I seem to be getting inconsistent rounding results using a text formatting string Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 print %9.4f % (229.0 * .325,)- 74.4250 correct print %9.2f % (round(74.425, 2),)- 74.43 correct print %9.2f % (74.425,) - 74.42 wrong print %9.2f % (167.255,) -167.26 correct print %9.2f % (167.2551,)-167.26 correct print %9.2f % (167.2549,)-167.25 correct It appears as if the string formatting code is a bit flakey. Perhaps working in binary with too small a precision? For a bit I thought it might be Round even up, odd down at the .005 break, but that doesn't appear to be the case. Now that I know it's there, I can do a workaround. Seems as if it deserves a fix or at least a document notation of the problem. Thanks in advance, Jim Hurlburt Atrium Windows and Doors Yakima, WA -- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-21 01:02 Message: Logged In: YES user_id=703403 Originator: NO This isn't really a bug---it's just one of those unavoidable things that happens when you're representing decimals using binary floating point: take a look at section 4.3 of the General Python FAQ: http://www.python.org/doc/faq/general/ If anything *is* wrong here it's actually the round() result, not the string formatting: 74.425 isn't exactly representable as a binary floating-point number, so Python (like most other languages) approximates it by the closest number that *is* exactly representable, which is (on my machine and probably yours too): 74.42499971578290569595992565155029296875 Since this is less than 74.425, the round function would, in an ideal world, round this down to 74.42 instead of up to 74.43. In the absence of an ideal world, making this sort of thing happen reliably and portably is hard, and I'd guess that round() is unlikely to change. Have you looked at the decimal module in the standard library? It sounds as though you might find it useful. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1778207group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777530 ] ctypes on Solaris
Bugs item #1777530, was opened at 2007-08-20 02:23 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777530group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Aki (akineko) Assigned to: Thomas Heller (theller) Summary: ctypes on Solaris Initial Comment: This is not really a bug. ctypes uses 'objdump', which is not available by default. (There are reasons not to install binutil on Solaris) There is no 'objdump' but Solaris has 'elfdump', instead. ctypes.util.py can use 'elfdump' instead of 'objdump'. #cmd = objdump -p -j .dynamic 2/dev/null + f cmd = elfdump -d 2/dev/null + f #res = re.search(r'\sSONAME\s+([^\s]+)', os.popen(cmd).read()) res = re.search(r'\sSONAME\s+([^\s]+)\s+([^\s]+)', os.popen(cmd).read())if not res: return None return res.group(2) # --- // ./Modules/_ctypes/libffi/config.guess also uses objdump so that file probably needs to be updated as well. Thank you for your attention. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-20 22:59 Message: Logged In: YES user_id=33168 Originator: NO Thomas, could you take a look? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777530group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777160 ] Please warn about a subtle trap
Bugs item #1777160, was opened at 2007-08-19 10:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777160group_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: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: Please warn about a subtle trap Initial Comment: In python, -1**2 is -1.This will horribly surprise most mathematicians or C programmers where unary - binds very tightly. Such people will expect -1**2 == 1. This problem shows up in scientific contexts, especially Numpy, where an easy way to generate an alternating string of positive and negative numbers is -1**numpy.arange(10). In this example, one expects to produce [1, -1, 1, -1, ...]. So, please put a note in the documentation warning of this problem. It can lead to subtly wrong computations. The appropriate place to put the note is in the Python Reference Manual, section 5.4, The Power operator. Please insert a final line saying: Note: since the minus sign is not part of a numeric literal, powers of negative numeric constants need to be written with parentheses. Be aware that -1**2 == -(1**2), not (-1)**2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777160group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777168 ] Confusing typography Python Ref 5.9
Bugs item #1777168, was opened at 2007-08-19 10:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777168group_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: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: Confusing typography Python Ref 5.9 Initial Comment: In the python reference manual, section 5.9, all that stuff with italic opa, opb etc reads rather poorly because of a visually confusing choice of names. The bit about ...then a opa b opb c ... y opy z opz looks more like aopabopbcopc...yopyzopz : in other words a unintelligible string of gibberish. A similar problem occurs slightly below. Note that the spaces *are* really there, but they do not show up well in the italic font used on my Firefox/Debian system, so it's hard to parse. The visual confusion is exacerbated by the similarities in the operator and variable names (e.g. opa and a, then opb then b), and also by the use of a three-character string to mean operator a versus a one-character name for the variable. So, please change opa to A et cetera, or make some other change that makes it easier to read. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777168group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777057 ] memoryview('test') is causing a segfault
Bugs item #1777057, was opened at 2007-08-19 03:13
Message generated for change (Comment added) made by tiran
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1777057group_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: Fixed
Priority: 8
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Neal Norwitz (nnorwitz)
Summary: memoryview('test') is causing a segfault
Initial Comment:
./python -c memoryview('test')
Segmentation fault
I compiled Python 3.0 with
$ ./configure --with-pydebug --enable-unicode=ucs4
and
$ make EXTRA_CFLAGS=-DPy_REF_DEBUG -DPy_TRACE_REFS -DPy_DEBUG
after a make clean; rm -rf build; svn up
I've used gdb to trace the segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210415424 (LWP 14436)]
0x080f77a0 in PyErr_SetObject (exception=0x81962c0, value=0xb7cee3a8) at
Python/errors.c:55
55 if (exception != NULL
--
Comment By: Christian Heimes (tiran)
Date: 2007-08-19 14:49
Message:
Logged In: YES
user_id=560817
Originator: YES
I've found another bug:
$ ./python -c memoryview('test')
Fatal Python error: UNREF invalid object
Aborted
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-08-19 06:25
Message:
Logged In: YES
user_id=33168
Originator: NO
Committed revision 57193. This problem was due to not initializing the
new BufferError properly. Travis mentioned this in his post to
python-3000.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1777057group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1776696 ] tempfile.TemporaryFile differs between platforms
Bugs item #1776696, was opened at 2007-08-18 04:31 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1776696group_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: Kenneth Loafman (loafman) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile.TemporaryFile differs between platforms Initial Comment: When running the following: import tempfile foo=tempfile.TemporaryFile type(foo) Linux returns: type 'file' Windows and Cygwin return: type 'instance' It should return the same across platforms, or return an undefined indication if not possible. -- Comment By: Christian Heimes (tiran) Date: 2007-08-19 14:54 Message: Logged In: YES user_id=560817 Originator: NO It's not a bug. The interface for both types are equal. Python doesn't guarantee that it uses the same types on every platform. It just guarantees that the behavior of the objects are the same on both platforms. Please study tempfile.py for detailed information. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1776696group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1751598 ] struni: str() doesn't call __str__() of subclasses of str
Bugs item #1751598, was opened at 2007-07-11 03:48
Message generated for change (Settings changed) made by tiran
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1751598group_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: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: str() doesn't call __str__() of subclasses of str
Initial Comment:
In the py3k-struni branch the str() constructor doesn't use __str__ when the
argument is an instance of a subclass of str. A user defined string can't
change __str__().
It works in Python 2.5 and in the p3yk branch.
Python 3.0x (py3k-struni:56245, Jul 10 2007, 23:34:56)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type help, copyright, credits or license for more information.
class Mystr(str):
... def __str__(self): return 'v'
...
s = Mystr('x')
s
'x'
str(s)
'x' # - SHOULD RETURN 'v'
Python 2.5.1 (r251:54863, May 2 2007, 16:56:35)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type help, copyright, credits or license for more information.
class Mystr(str):
... def __str__(self): return 'v'
...
s = Mystr('x')
s
'x'
str(s)
'v'
Python 3.0x (p3yk:56180, Jul 6 2007, 23:35:08)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type help, copyright, credits or license for more information.
class Mystr(str):
... def __str__(self): return 'v'
...
s = Mystr('x')
s
'x'
str(s)
'v'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1751598group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1771260 ] Errors in site.py not reported properly
Bugs item #1771260, was opened at 2007-08-09 23:37 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1771260group_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: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: Errors in site.py not reported properly Initial Comment: (Ignore the p3yk dir name. This has been updated to the py3k branch.) [EMAIL PROTECTED]:~/src/python-p3yk/build$ make object : type: TypeError refcount: 4 address : 0x8239f0c lost sys.stderr make: *** [sharedmods] Error 1 The root cause is that (due to some local modifications) site.py failed to load and gave an error. This can be easily duplicated by opening up Lib/site.py:main and putting 1/0 on the first line. However, the ZeroDivisionError that should cause never gets printed. Python/pythonrun.c:initsite attempts to retrieve sys.stderr, which fails because site.py never got a chance to install it (!), then passes the NULL file object pointer to PyFile_WriteString, which turns that into a new exception (replacing the old one). initsite ignores the return value indicating the exception, instead clearing it, and the interpreter continues to load, no one the wiser. Several other exceptions may happen and get squashed, I'm not sure. Eventually, Python/sysmodule.c:sys_excepthook calls Python/pythonrun.c:PyErr_Display, which attempts to retrieve sys.stderr, and failing that calls _PyObject_Dump() on the exception (explaining the weird message). Oddly, there's a *second* if statement, which then prints the lost sys.stderr line. Possible remedies: 1. PyErr_Display's dump message is not very clear. 2. initsite should go directly to stderr if it can't retrieve sys.stderr. Alternatively, since site.py is now more important, it could be changed into a fatal error. Yet another option is to explicitly check for sys.stderr even on success and make that alone into a fatal error. 3. The error printing APIs could be modified to internalize the stderr retrieval. Upon failure they could print a brief stderr unavailable; original exception was ... message. -- Comment By: Christian Heimes (tiran) Date: 2007-08-19 15:56 Message: Logged In: YES user_id=560817 Originator: NO I run into trouble with stderr myself and I agree that the problem should be resolved somehow by falling back to the file descriptor 2 (stderr). The current implementation makes it unnecessarily hard to debug problems in site.py, io.py and possible also codecs.*. -- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-08-10 20:19 Message: Logged In: YES user_id=12364 Originator: YES Following up on the possible remedies, I'm thinking PySys_WriteStderr could be extended to take file object as the first argument, and if null it writes to low-level stderr instead. That way the callers can add the message about lost sys.stderr themselves, rather than it being interspersed in their output. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1771260group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777057 ] memoryview('test') is causing a segfault
Bugs item #1777057, was opened at 2007-08-18 18:13
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1777057group_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: Closed
Resolution: Fixed
Priority: 8
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Neal Norwitz (nnorwitz)
Summary: memoryview('test') is causing a segfault
Initial Comment:
./python -c memoryview('test')
Segmentation fault
I compiled Python 3.0 with
$ ./configure --with-pydebug --enable-unicode=ucs4
and
$ make EXTRA_CFLAGS=-DPy_REF_DEBUG -DPy_TRACE_REFS -DPy_DEBUG
after a make clean; rm -rf build; svn up
I've used gdb to trace the segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210415424 (LWP 14436)]
0x080f77a0 in PyErr_SetObject (exception=0x81962c0, value=0xb7cee3a8) at
Python/errors.c:55
55 if (exception != NULL
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-08-19 11:39
Message:
Logged In: YES
user_id=33168
Originator: NO
Committed revision 57198 fixes the problem in debug mode. Now a proper
exception is generated.
--
Comment By: Christian Heimes (tiran)
Date: 2007-08-19 05:49
Message:
Logged In: YES
user_id=560817
Originator: YES
I've found another bug:
$ ./python -c memoryview('test')
Fatal Python error: UNREF invalid object
Aborted
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-08-18 21:25
Message:
Logged In: YES
user_id=33168
Originator: NO
Committed revision 57193. This problem was due to not initializing the
new BufferError properly. Travis mentioned this in his post to
python-3000.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1777057group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777398 ] IDLE Freezes After Running Scripts
Bugs item #1777398, was opened at 2007-08-19 21:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777398group_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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ross Peoples (deejross) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE Freezes After Running Scripts Initial Comment: IDLE freezes after running a script in a new window. I'm writing a wxPython script, which runs well until the window is closed, then IDLE freezes (shell and all open windows) and I have to kill the process. It is a tutorial script, so nothing too fancy: import wx class MyFrame(wx.Frame): def __init__(self, parent, id, title): wx.Frame.__init__(self, parent, id, title) menubar = wx.MenuBar() file = wx.Menu() edit = wx.Menu() help = wx.Menu() file.Append(101, New) file.Append(102, Open, Open a new document) fileRecent = wx.Menu() fileRecent.Append(10301, First Item) fileRecent.Append(10302, Second Item) file.AppendMenu(103, Open Recent, fileRecent) file.Append(104, Save, Save the document) file.AppendSeparator() file.Append(105, Exit, Close this window) edit.Append(201, Check 1, Check 1 Tooltip, wx.ITEM_CHECK) edit.Append(202, Check 2, Check 2 Tooltip, wx.ITEM_CHECK) menubar.Append(file, File) menubar.Append(edit, Edit) menubar.Append(help, Help) self.SetMenuBar(menubar) self.CreateStatusBar() class MyApp(wx.App): def OnInit(self): frame = MyFrame(None, -1, My Frame) frame.Center() frame.Show(True) return True app = MyApp(0) app.MainLoop() --- It should be noted that usually it freezes after running the script once, but sometimes I can run it a second time before it freezes IDLE. It doesn't seem to freeze using only core Python, only when using wxWidgets. Here are some versions: Ubuntu Gusty Python version 2.5.1 IDLE version 1.2.1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1777398group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777412 ] Python's strftime dislikes years before 1900
Bugs item #1777412, was opened at 2007-08-20 13:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1777412group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Benno Rice (benno)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python's strftime dislikes years before 1900
Initial Comment:
Python 2.5 (r25:51918, Sep 19 2006, 08:49:13)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type help, copyright, credits or license for more information.
import datetime
datetime.date(1876, 2, 3).strftime('%Y-%m-%d')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: year=1876 is before 1900; the datetime strftime() methods require
year = 1900
Apparently this is due to platform-specific weirdnesses in implementations of
strftime. It is still very annoying however. Perhaps a good implementation of
strftime could be found and incorporated into Python itself?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1777412group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1776160 ] Buffer overflow when listing deeply nested directory
Bugs item #1776160, was opened at 2007-08-17 06:24 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1776160group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj�rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Buffer overflow when listing deeply nested directory Initial Comment: This code: import os import os.path TARGET='C:/code/python/foo' base = TARGET for x in range(200): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base Produces a TypeError (buffer overflow) when run on a to deeply nested directory for windows to handle: .. more output here.. C:code/python/foo\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.p ng\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png\foo bar.png Traceback (most recent call last): File killdir.py, line 6, in module subdirs = os.listdir(base) TypeError: listdir() argument 1 must be (buffer overflow), not str -- Comment By: Skip Montanaro (montanaro) Date: 2007-08-18 06:38 Message: Logged In: YES user_id=44345 Originator: NO Worked as expected for me on Mac OS X 10.4.10 running from the trunk (you didn't mention what version you were using). In ~/tmp/deep I created a maximally nested directory tree from the shell like so: cd /Users/skip/tmp/deep for i in `range 1000` ; do x=`printf %04d $i` echo $x mkdir $x cd $x done where the range command is analogous to Python's range builtin: % range 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 The for loop barfed after making directory 0205. In Python I then executed these statements: import os.path base = /Users/skip/tmp/deep for x in range(210): subdirs = os.listdir(base) base = os.path.join(base, subdirs[0]) print base This went until it got to dir 0200 where it raised an OSError: [Errno 63] File name too long: '/Users/skip/tmp/deep//0001/.../0199/0200' which stands to reason since base was 1025 characters long at that point. MAXPATHLEN is defined to be 1024 on my system, so the OSError is to be expected. Skip -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1776160group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777057 ] memoryview('test') is causing a segfault
Bugs item #1777057, was opened at 2007-08-19 03:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1777057group_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: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: memoryview('test') is causing a segfault
Initial Comment:
./python -c memoryview('test')
Segmentation fault
I compiled Python 3.0 with
$ ./configure --with-pydebug --enable-unicode=ucs4
and
$ make EXTRA_CFLAGS=-DPy_REF_DEBUG -DPy_TRACE_REFS -DPy_DEBUG
after a make clean; rm -rf build; svn up
I've used gdb to trace the segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210415424 (LWP 14436)]
0x080f77a0 in PyErr_SetObject (exception=0x81962c0, value=0xb7cee3a8) at
Python/errors.c:55
55 if (exception != NULL
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1777057group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777057 ] memoryview('test') is causing a segfault
Bugs item #1777057, was opened at 2007-08-19 03:13
Message generated for change (Settings changed) made by tiran
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1777057group_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: 8
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: memoryview('test') is causing a segfault
Initial Comment:
./python -c memoryview('test')
Segmentation fault
I compiled Python 3.0 with
$ ./configure --with-pydebug --enable-unicode=ucs4
and
$ make EXTRA_CFLAGS=-DPy_REF_DEBUG -DPy_TRACE_REFS -DPy_DEBUG
after a make clean; rm -rf build; svn up
I've used gdb to trace the segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210415424 (LWP 14436)]
0x080f77a0 in PyErr_SetObject (exception=0x81962c0, value=0xb7cee3a8) at
Python/errors.c:55
55 if (exception != NULL
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1777057group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1775388 ] Display CallTips for classes using metaclasses.
Bugs item #1775388, was opened at 2007-08-16 08:28 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1775388group_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: IDLE Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Display CallTips for classes using metaclasses. Initial Comment: Hello, Currently, if you write something like this: class MyType(type): pass class MyClass(object): __metaclass__ = MyType def __init__(self, a): pass And write in the shell: MyClass( a calltip won't be displayed. To fix this, replace this line in CallTups.py: if type(ob) in (types.ClassType, types.TypeType): with this one: if issubclass(type(ob), (types.ClassType, types.TypeType)): and now it works. Thanks, Noam -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1775388group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1777057 ] memoryview('test') is causing a segfault
Bugs item #1777057, was opened at 2007-08-18 18:13
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1777057group_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: Closed
Resolution: Fixed
Priority: 8
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Neal Norwitz (nnorwitz)
Summary: memoryview('test') is causing a segfault
Initial Comment:
./python -c memoryview('test')
Segmentation fault
I compiled Python 3.0 with
$ ./configure --with-pydebug --enable-unicode=ucs4
and
$ make EXTRA_CFLAGS=-DPy_REF_DEBUG -DPy_TRACE_REFS -DPy_DEBUG
after a make clean; rm -rf build; svn up
I've used gdb to trace the segfault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210415424 (LWP 14436)]
0x080f77a0 in PyErr_SetObject (exception=0x81962c0, value=0xb7cee3a8) at
Python/errors.c:55
55 if (exception != NULL
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-08-18 21:25
Message:
Logged In: YES
user_id=33168
Originator: NO
Committed revision 57193. This problem was due to not initializing the
new BufferError properly. Travis mentioned this in his post to
python-3000.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1777057group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1698167 ] xml.etree document element.tag
Bugs item #1698167, was opened at 2007-04-11 06:25 Message generated for change (Comment added) made by dlocke You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1698167group_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: paul rubin (phr) Assigned to: Fredrik Lundh (effbot) Summary: xml.etree document element.tag Initial Comment: The xml.etree docs vaguely mention an implementation-dependent Element interface without describing it in any detail. I could not figure out from the docs how to get the tag name of an element returned from (say) the getiterator interface. That is, for an element like foo/, I wanted the string foo. Examining the library source showed that e.tag does the job, at least some of the time, and that was enough to get my app working. Could the actual situation please be documented--thanks. -- Comment By: dlocke (dlocke) Date: 2007-08-17 18:56 Message: Logged In: YES user_id=1525611 Originator: NO I concur that any documentation about the Element object seems to be missing. Is there any timetable for getting this added to the documentation? -- Comment By: Fredrik Lundh (effbot) Date: 2007-04-13 13:32 Message: Logged In: YES user_id=38376 Originator: NO Looks like the entire Element section is missing from the current documentation. Thanks for reporting this; I'll take a look when I find the time. In the meantime, you'll find additional documentation here: http://effbot.org/zone/element.htm -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1698167group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1776696 ] tempfile.TemporaryFile differs between platforms
Bugs item #1776696, was opened at 2007-08-18 02:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1776696group_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: Kenneth Loafman (loafman) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile.TemporaryFile differs between platforms Initial Comment: When running the following: import tempfile foo=tempfile.TemporaryFile type(foo) Linux returns: type 'file' Windows and Cygwin return: type 'instance' It should return the same across platforms, or return an undefined indication if not possible. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1776696group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1774736 ] Binding Control-space fails
Bugs item #1774736, was opened at 2007-08-15 18:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1774736group_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 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. Löwis (loewis)
Summary: Binding Control-space fails
Initial Comment:
In py3k branch r57057, when I run::
import Tkinter
tk = Tkinter.Tk()
text = Tkinter.Text(tk)
def callback(event=None):
return
text.bind('Control-space', callback)
text.pack()
text.focus_set()
tk.mainloop()
when I press C-space I get this exception::
Traceback (most recent call last):
File spacefailure.py, line 13, in module
tk.mainloop()
File /usr/local/lib/python3.0/lib-tk/Tkinter.py, line 1022, in mainloop
self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: illegal
encoding
The strange thing about it is that other bindings work
as expected.
I'm running on ubuntu feisty.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1774736group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770009 ] decimal.Decimal(trash) produces informationless exception
Bugs item #1770009, was opened at 2007-08-08 09:44 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770009group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: John Machin (sjmachin) Assigned to: Facundo Batista (facundobatista) Summary: decimal.Decimal(trash) produces informationless exception Initial Comment: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import decimal decimal.Decimal(-$123,456.78) Traceback (most recent call last): File stdin, line 1, in module File C:\python25\lib\decimal.py, line 614, in __new__ self._sign, self._int, self._exp = context._raise_error(ConversionSyntax) File C:\python25\lib\decimal.py, line 2325, in _raise_error raise error, explanation decimal.InvalidOperation It should do something like float does ... better message, and show the offending arg: float(-$123,456.78) Traceback (most recent call last): File stdin, line 1, in module ValueError: invalid literal for float(): -$123,456.78 -- Comment By: Facundo Batista (facundobatista) Date: 2007-08-15 12:14 Message: Logged In: YES user_id=752496 Originator: NO Fixed, both in trunk and in the decimal-branch: import decimal decimal.Decimal(-$123,456.78) Traceback (most recent call last): ... decimal.InvalidOperation: Invalid literal for Decimal: '-$123,456.78' -- Comment By: Facundo Batista (facundobatista) Date: 2007-08-13 12:17 Message: Logged In: YES user_id=752496 Originator: NO Yes, I will. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-10 00:36 Message: Logged In: YES user_id=33168 Originator: NO Facundo, could you take a look? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770009group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-816725 ] mark deprecated modules in indexes
Bugs item #816725, was opened at 2003-10-02 18:13 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=816725group_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: Feature Request Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Georg Brandl (gbrandl) Summary: mark deprecated modules in indexes Initial Comment: J. David Ibanez (jdavid at itaapy.com) suggested via email: It would be nice if the quot;Global Module Indexquot; showed the deprecated modules clearly separated from the non deprecated modules. -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-15 18:43 Message: Logged In: YES user_id=849994 Originator: NO This is now implemented in Sphinx, committed rev. 57075. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=816725group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed
Bugs item #1772916, was opened at 2007-08-13 18:15 Message generated for change (Comment added) made by ldeller You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772916group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called sgmlop if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). -- Comment By: lplatypus (ldeller) Date: 2007-08-14 16:23 Message: Logged In: YES user_id=1534394 Originator: YES Yes the standalone sgmlop-1.1.1 looks fine: in its sgmlop.c I can see that matching allocator and deallocator functions are used. I installed PyXML-0.8.4 from source (python setup.py install on Win32 which picked up the C compiler from MSVS7.1). The cause of the problem is quite visible in the PyXML source code (see that PyObject_NEW and PyMem_DEL are used together): http://pyxml.cvs.sourceforge.net/pyxml/xml/extensions/sgmlop.c?view=markup Interestingly PyXML-0.8.4 was released more recently than sgmlop-1.1.1. I guess they weren't keeping in sync with each other. -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-14 13:32 Message: Logged In: YES user_id=1115903 Originator: NO I tried out xmlrpclib on the trunk (2.6) with sgmlop-1.1.1 and it works just fine. At the moment I don't have time to try out PyXML, but seeing that the most recent sgmlop works with xmlrpclib makes me lean towards not removing sgmlop support (not that I have a say about it, but still). How did you install PyXML? If it wasn't from source or from an installer compiled for 2.5, that might be a problem. If PyXML installed from source or compiled for 2.5 still causes this problem, it could be that it needs to be updated to the current sgmlop. -- Comment By: lplatypus (ldeller) Date: 2007-08-14 11:07 Message: Logged In: YES user_id=1534394 Originator: YES Choice of XML parser is an implementation detail of xmlrpclib not visible to users of the module. This change would not affect the behaviour of xmlrpclib (other than to fix a crash introduced in Python 2.5). Does this mean that a DeprecationWarning would not be necessary? Does it also mean that the fix might qualify for the maintenance branch? Adding a DeprecationWarning in 2.6 without removing use of sgmlop is pointless, because the DeprecationWarning would be followed by a process crash anyway. -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 21:06 Message: Logged In: YES user_id=1115903 Originator: NO I'm assuming that stuff won't be removed from 2.5 because it's in maintenance, so should this be removed or changed to raise a deprecation warning in 2.6? As an aside, how about removing references to _xmlrpclib (which appears to have been removed long ago) as well? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772916group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1424152 ] urllib/urllib2: HTTPS over (Squid) Proxy fails
Bugs item #1424152, was opened at 2006-02-04 18:50
Message generated for change (Comment added) made by doko
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1424152group_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: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib/urllib2: HTTPS over (Squid) Proxy fails
Initial Comment:
py2.4.2/win32
The proxy mechanism of python fails on https and does
work completely wrong (not using the CONNECT scheme).
(after urlopen some minute(s) freeze then EOF error)
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310
32 bit (Intel)] on win32
Type help, copyright, credits or license for
more information.
import urllib
urllib.getproxies()
{'ftp': 'ftp://vserver:3128', 'http':
'http://vserver:3128', 'gopher': 'gopher:/
/vserver:3128', 'https': 'https://vserver:3128'}
urllib.urlopen('https://www.elster.de')
Traceback (most recent call last):
File stdin, line 1, in ?
File C:\Python24\lib\urllib.py, line 77, in urlopen
return opener.open(url)
File C:\Python24\lib\urllib.py, line 185, in open
return getattr(self, name)(url)
File C:\Python24\lib\urllib.py, line 386, in open_https
h.endheaders()
File C:\Python24\lib\httplib.py, line 795, in
endheaders
self._send_output()
File C:\Python24\lib\httplib.py, line 676, in
_send_output
self.send(msg)
File C:\Python24\lib\httplib.py, line 643, in send
self.connect()
File C:\Python24\lib\httplib.py, line 1071, in connect
ssl = socket.ssl(sock, self.key_file, self.cert_file)
File C:\Python24\lib\socket.py, line 74, in ssl
return _realssl(sock, keyfile, certfile)
IOError: [Errno socket error] (8, 'EOF occurred in
violation of protocol')
no CONNECT even appears in the squid proxy access log.
Robert
--
Comment By: Matthias Klose (doko)
Date: 2007-08-14 14:29
Message:
Logged In: YES
user_id=60903
Originator: NO
seen with urllib2 as well:
https://bugs.launchpad.net/ubuntu/+source/python2.5/+bug/122551
--
Comment By: kxroberto (kxroberto)
Date: 2006-02-11 19:28
Message:
Logged In: YES
user_id=972995
Meanwhile I wrote my own CONNECT quick hack. As indeed
this hack works correct for all proxied environments tested
up to now (30) I wonder how open_https (in urllib and
urllib2) ever in the past managed to come through a proxy,
because there is some differentiation in open_https for the
case, that there is a proxy!? Who has written that
if..else's? Are there proxies which really do
SSL-handshaking directly and make an extra connection to the
target server? I guess that would even make certificate
handling very strange... I cannot immagine and never saw
one. But maybe such proxies exist. I am not a real expert
for such networking questions, but I guess CONNECT is widely
used and in my own proxies I can see in the log file, that
all common browsers use a HTTP CONNECT request for https
proxying. CONNECT should at least be implemented as an
option in urllibX
Robert
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1424152group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1424152 ] urllib/urllib2: HTTPS over (Squid) Proxy fails
Bugs item #1424152, was opened at 2006-02-04 23:20
Message generated for change (Comment added) made by orsenthil
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1424152group_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: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib/urllib2: HTTPS over (Squid) Proxy fails
Initial Comment:
py2.4.2/win32
The proxy mechanism of python fails on https and does
work completely wrong (not using the CONNECT scheme).
(after urlopen some minute(s) freeze then EOF error)
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310
32 bit (Intel)] on win32
Type help, copyright, credits or license for
more information.
import urllib
urllib.getproxies()
{'ftp': 'ftp://vserver:3128', 'http':
'http://vserver:3128', 'gopher': 'gopher:/
/vserver:3128', 'https': 'https://vserver:3128'}
urllib.urlopen('https://www.elster.de')
Traceback (most recent call last):
File stdin, line 1, in ?
File C:\Python24\lib\urllib.py, line 77, in urlopen
return opener.open(url)
File C:\Python24\lib\urllib.py, line 185, in open
return getattr(self, name)(url)
File C:\Python24\lib\urllib.py, line 386, in open_https
h.endheaders()
File C:\Python24\lib\httplib.py, line 795, in
endheaders
self._send_output()
File C:\Python24\lib\httplib.py, line 676, in
_send_output
self.send(msg)
File C:\Python24\lib\httplib.py, line 643, in send
self.connect()
File C:\Python24\lib\httplib.py, line 1071, in connect
ssl = socket.ssl(sock, self.key_file, self.cert_file)
File C:\Python24\lib\socket.py, line 74, in ssl
return _realssl(sock, keyfile, certfile)
IOError: [Errno socket error] (8, 'EOF occurred in
violation of protocol')
no CONNECT even appears in the squid proxy access log.
Robert
--
Comment By: O.R.Senthil Kumaran (orsenthil)
Date: 2007-08-15 01:40
Message:
Logged In: YES
user_id=942711
Originator: NO
Please verify if this recipe is of any help:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/456195
--
Comment By: Matthias Klose (doko)
Date: 2007-08-14 17:59
Message:
Logged In: YES
user_id=60903
Originator: NO
seen with urllib2 as well:
https://bugs.launchpad.net/ubuntu/+source/python2.5/+bug/122551
--
Comment By: kxroberto (kxroberto)
Date: 2006-02-11 23:58
Message:
Logged In: YES
user_id=972995
Meanwhile I wrote my own CONNECT quick hack. As indeed
this hack works correct for all proxied environments tested
up to now (30) I wonder how open_https (in urllib and
urllib2) ever in the past managed to come through a proxy,
because there is some differentiation in open_https for the
case, that there is a proxy!? Who has written that
if..else's? Are there proxies which really do
SSL-handshaking directly and make an extra connection to the
target server? I guess that would even make certificate
handling very strange... I cannot immagine and never saw
one. But maybe such proxies exist. I am not a real expert
for such networking questions, but I guess CONNECT is widely
used and in my own proxies I can see in the log file, that
all common browsers use a HTTP CONNECT request for https
proxying. CONNECT should at least be implemented as an
option in urllibX
Robert
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1424152group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772890 ] Py Lib Ref, 3.6.1 String Methods startswith() typo
Bugs item #1772890, was opened at 2007-08-13 02:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772890group_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: 3rd Party Status: Open Resolution: None Priority: 5 Private: No Submitted By: arxaaron (arxaaron) Assigned to: Nobody/Anonymous (nobody) Summary: Py Lib Ref, 3.6.1 String Methods startswith() typo Initial Comment: Python Library Reference Section 3.6.1 String Methods = startswith(prefix[, start[, end]]) Return True if string starts with the prefix, otherwise return False. prefix can also be a tuple of __suffixes__ to look for. With optional start, test string beginning at that position. With optional end, stop comparing string at that position. = ...Believe suffixes should be corrected to prefixes (Likely a copy and paste oversight from the description for mirror method endswith(suffix[, start[, end]])) Typo report of Jan. 2007 noted as closed, but error is still present. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772890group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed
Bugs item #1772916, was opened at 2007-08-13 18:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772916group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called sgmlop if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772916group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772890 ] Py Lib Ref, 3.6.1 String Methods startswith() typo
Bugs item #1772890, was opened at 2007-08-13 07:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772890group_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: 3rd Party Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: arxaaron (arxaaron) Assigned to: Nobody/Anonymous (nobody) Summary: Py Lib Ref, 3.6.1 String Methods startswith() typo Initial Comment: Python Library Reference Section 3.6.1 String Methods = startswith(prefix[, start[, end]]) Return True if string starts with the prefix, otherwise return False. prefix can also be a tuple of __suffixes__ to look for. With optional start, test string beginning at that position. With optional end, stop comparing string at that position. = ...Believe suffixes should be corrected to prefixes (Likely a copy and paste oversight from the description for mirror method endswith(suffix[, start[, end]])) Typo report of Jan. 2007 noted as closed, but error is still present. -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-13 09:39 Message: Logged In: YES user_id=849994 Originator: NO It is fixed, but in the development docs. The 2.5 docs will get updated with 2.5.2. -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-13 09:39 Message: Logged In: YES user_id=849994 Originator: NO It is fixed, but in the development docs. The 2.5 docs will get updated with 2.5.2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772890group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772890 ] Py Lib Ref, 3.6.1 String Methods startswith() typo
Bugs item #1772890, was opened at 2007-08-13 07:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772890group_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: 3rd Party Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: arxaaron (arxaaron) Assigned to: Nobody/Anonymous (nobody) Summary: Py Lib Ref, 3.6.1 String Methods startswith() typo Initial Comment: Python Library Reference Section 3.6.1 String Methods = startswith(prefix[, start[, end]]) Return True if string starts with the prefix, otherwise return False. prefix can also be a tuple of __suffixes__ to look for. With optional start, test string beginning at that position. With optional end, stop comparing string at that position. = ...Believe suffixes should be corrected to prefixes (Likely a copy and paste oversight from the description for mirror method endswith(suffix[, start[, end]])) Typo report of Jan. 2007 noted as closed, but error is still present. -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-13 09:39 Message: Logged In: YES user_id=849994 Originator: NO It is fixed, but in the development docs. The 2.5 docs will get updated with 2.5.2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772890group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed
Bugs item #1772916, was opened at 2007-08-13 03:15 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772916group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called sgmlop if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 06:06 Message: Logged In: YES user_id=1115903 Originator: NO I'm assuming that stuff won't be removed from 2.5 because it's in maintenance, so should this be removed or changed to raise a deprecation warning in 2.6? As an aside, how about removing references to _xmlrpclib (which appears to have been removed long ago) as well? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772916group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770416 ] Decimal.__int__ overflows for large values
Bugs item #1770416, was opened at 2007-08-08 17:43 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770416group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Facundo Batista (facundobatista) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. from decimal import Decimal as D e = D(1e1234567890987654321) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer e = D(1e1234567890) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. -- Comment By: Facundo Batista (facundobatista) Date: 2007-08-13 12:10 Message: Logged In: YES user_id=752496 Originator: NO hash will NOT be changed as is requested in this bug: import decimal d = decimal.Decimal(1) hash(d) 1 hash(1) 1 hash(d.as_tuple()) -790594979 See this requirement from PEP 327: hash(n) == hash(Decimal(n)) # Only if n is int, long, or Decimal Regarding the overflow, this must to be fixed... I'll take a look to marketdickinson patch... -- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-13 01:50 Message: Logged In: YES user_id=703403 Originator: NO See patch #1772851 -- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-12 16:43 Message: Logged In: YES user_id=703403 Originator: NO Mark Dickinson (marketdickinson) stupidly claimed that: hash(n) == hash(n % (2**32-1)) It's not true. Sorry for the noise. -- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-12 14:57 Message: Logged In: YES user_id=703403 Originator: NO Doesn't using hash(D.as_tuple()) break the principle that if two objects compare equal then they should have equal hash? An alternative to converting to long before hashing is to use the fact that for the current hash implementation for long we have hash(n) == hash(n % (2**32-1)) (except when n is a multiple of 2**32-1). For a Decimal d that's integral, one should be able to compute d % (2**32-1) very quickly: if d = c*10**e then just use (c * pow(10, e, 2**32-1)) % (2**32-1), which should be acceptably fast even when d = 123456789E999. The only tricky bit is that on a 64-bit system all those 2**32-1 need to be replaced by 2**64-1. Though now I come to think of it, since 2**32-1 is a factor of 2**64-1 it would be enough just to do everything modulo 2**64-1 even on a 32-bit system. -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-09 14:37 Message: Logged In: YES user_id=849994 Originator: NO Assigning to Facundo, he's actively working on decimal ATM. -- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 14:21 Message: Logged In: YES user_id=1200609 Originator: NO I see. Inheriting from Decimal and overloading __hash__ is a way to solve your problem, but it's IMHO a shallow bug and worth reporting. I just tried hash(D.as_tuple()) and it is blazing fast. I think that unless the official line is don't touch decimal.py until X, this change to hashing would be useful and (AFAICT) harmless enough to fit in e.g. 2.5.2. To avoid incompatibilities, __hash__ could check for Overflow and only use .as_tuple for values higher than the previous maximum (keeping, unfortunately, __hash__ slow for values below). Could the current status of Decimal be made a bit more clear? Are bug reports/patches welcome? Is bugging Facundo or RHettinger welcome? :) If getting __int__ a bit faster and able to convert sans huge strings is desired, I've updated that old function (see below) and AFAIK it could be used to replace Lib/decimal.py/Decimal.[__int__,__long__]. It gets about ten times faster on best cases and is about as slow on worst cases (could be much worse if long(rint_part + rdec_part)/exponent is a STUPID thing to do, but seems easy to avoid). As the original __int__ optimizes str(Decimal
[ python-Bugs-1770009 ] decimal.Decimal(trash) produces informationless exception
Bugs item #1770009, was opened at 2007-08-08 09:44 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770009group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Machin (sjmachin) Assigned to: Facundo Batista (facundobatista) Summary: decimal.Decimal(trash) produces informationless exception Initial Comment: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import decimal decimal.Decimal(-$123,456.78) Traceback (most recent call last): File stdin, line 1, in module File C:\python25\lib\decimal.py, line 614, in __new__ self._sign, self._int, self._exp = context._raise_error(ConversionSyntax) File C:\python25\lib\decimal.py, line 2325, in _raise_error raise error, explanation decimal.InvalidOperation It should do something like float does ... better message, and show the offending arg: float(-$123,456.78) Traceback (most recent call last): File stdin, line 1, in module ValueError: invalid literal for float(): -$123,456.78 -- Comment By: Facundo Batista (facundobatista) Date: 2007-08-13 12:17 Message: Logged In: YES user_id=752496 Originator: NO Yes, I will. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-10 00:36 Message: Logged In: YES user_id=33168 Originator: NO Facundo, could you take a look? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770009group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed
Bugs item #1772916, was opened at 2007-08-13 18:15 Message generated for change (Comment added) made by ldeller You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772916group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called sgmlop if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). -- Comment By: lplatypus (ldeller) Date: 2007-08-14 11:07 Message: Logged In: YES user_id=1534394 Originator: YES Choice of XML parser is an implementation detail of xmlrpclib not visible to users of the module. This change would not affect the behaviour of xmlrpclib (other than to fix a crash introduced in Python 2.5). Does this mean that a DeprecationWarning would not be necessary? Does it also mean that the fix might qualify for the maintenance branch? Adding a DeprecationWarning in 2.6 without removing use of sgmlop is pointless, because the DeprecationWarning would be followed by a process crash anyway. -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 21:06 Message: Logged In: YES user_id=1115903 Originator: NO I'm assuming that stuff won't be removed from 2.5 because it's in maintenance, so should this be removed or changed to raise a deprecation warning in 2.6? As an aside, how about removing references to _xmlrpclib (which appears to have been removed long ago) as well? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772916group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed
Bugs item #1772916, was opened at 2007-08-13 03:15 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772916group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called sgmlop if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 22:32 Message: Logged In: YES user_id=1115903 Originator: NO I tried out xmlrpclib on the trunk (2.6) with sgmlop-1.1.1 and it works just fine. At the moment I don't have time to try out PyXML, but seeing that the most recent sgmlop works with xmlrpclib makes me lean towards not removing sgmlop support (not that I have a say about it, but still). How did you install PyXML? If it wasn't from source or from an installer compiled for 2.5, that might be a problem. If PyXML installed from source or compiled for 2.5 still causes this problem, it could be that it needs to be updated to the current sgmlop. -- Comment By: lplatypus (ldeller) Date: 2007-08-13 20:07 Message: Logged In: YES user_id=1534394 Originator: YES Choice of XML parser is an implementation detail of xmlrpclib not visible to users of the module. This change would not affect the behaviour of xmlrpclib (other than to fix a crash introduced in Python 2.5). Does this mean that a DeprecationWarning would not be necessary? Does it also mean that the fix might qualify for the maintenance branch? Adding a DeprecationWarning in 2.6 without removing use of sgmlop is pointless, because the DeprecationWarning would be followed by a process crash anyway. -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 06:06 Message: Logged In: YES user_id=1115903 Originator: NO I'm assuming that stuff won't be removed from 2.5 because it's in maintenance, so should this be removed or changed to raise a deprecation warning in 2.6? As an aside, how about removing references to _xmlrpclib (which appears to have been removed long ago) as well? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772916group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770551 ] words able to decode but unable to encode in GB18030
Bugs item #1770551, was opened at 2007-08-09 10:34
Message generated for change (Comment added) made by perky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1770551group_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: Unicode
Group: Python 2.5
Status: Closed
Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Z-flagship (zaex)
Assigned to: Hye-Shik Chang (perky)
Summary: words able to decode but unable to encode in GB18030
Initial Comment:
Here is a list of chinese characters that can be read from a file [in GB18030
encoding], but unable to encode to GB18030 encoding
detailed:
used codecs.open(r'file name', encoding='GB18030') to read the characters from
a file, and try to encode them word by word into GB18030 with
word.encode('GB18030'). The action caused an exception with 'illegal multibyte
sequence'
the attachment is also the list.
list:
䎬䎱䅟䌷䦟䦷䲠㧏㭎㘚㘎㱮䴔䴖䴗䦆㧟䙡䙌䴕䁖䎬䴙䥽䝼䞍䓖䲡䥇䦂䦅䴓㩳㧐㳠䲢䴘㖞䜣䥺䶮䜩䥺䲟䲣䦛䦶㑳㑇㥮㤘䏝䦃
--
Comment By: Hye-Shik Chang (perky)
Date: 2007-08-13 00:18
Message:
Logged In: YES
user_id=55188
Originator: NO
The problem has been fixed about a week ago. (r56727-8)
It will be okay on the forthcoming Python releases. Thank you for
reporting!
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-08-10 12:35
Message:
Logged In: YES
user_id=33168
Originator: NO
This seems like a cjk problem. Hye-Shik, could you take a look?
--
Comment By: Z-flagship (zaex)
Date: 2007-08-09 10:37
Message:
Logged In: YES
user_id=1863611
Originator: YES
The Python is Python2.5 , my OS is windows XP professional sp2 version
2002
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1770551group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770416 ] Decimal.__int__ overflows for large values
Bugs item #1770416, was opened at 2007-08-08 20:43 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770416group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Facundo Batista (facundobatista) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. from decimal import Decimal as D e = D(1e1234567890987654321) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer e = D(1e1234567890) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. -- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-12 17:57 Message: Logged In: YES user_id=703403 Originator: NO Doesn't using hash(D.as_tuple()) break the principle that if two objects compare equal then they should have equal hash? An alternative to converting to long before hashing is to use the fact that for the current hash implementation for long we have hash(n) == hash(n % (2**32-1)) (except when n is a multiple of 2**32-1). For a Decimal d that's integral, one should be able to compute d % (2**32-1) very quickly: if d = c*10**e then just use (c * pow(10, e, 2**32-1)) % (2**32-1), which should be acceptably fast even when d = 123456789E999. The only tricky bit is that on a 64-bit system all those 2**32-1 need to be replaced by 2**64-1. Though now I come to think of it, since 2**32-1 is a factor of 2**64-1 it would be enough just to do everything modulo 2**64-1 even on a 32-bit system. -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-09 17:37 Message: Logged In: YES user_id=849994 Originator: NO Assigning to Facundo, he's actively working on decimal ATM. -- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 17:21 Message: Logged In: YES user_id=1200609 Originator: NO I see. Inheriting from Decimal and overloading __hash__ is a way to solve your problem, but it's IMHO a shallow bug and worth reporting. I just tried hash(D.as_tuple()) and it is blazing fast. I think that unless the official line is don't touch decimal.py until X, this change to hashing would be useful and (AFAICT) harmless enough to fit in e.g. 2.5.2. To avoid incompatibilities, __hash__ could check for Overflow and only use .as_tuple for values higher than the previous maximum (keeping, unfortunately, __hash__ slow for values below). Could the current status of Decimal be made a bit more clear? Are bug reports/patches welcome? Is bugging Facundo or RHettinger welcome? :) If getting __int__ a bit faster and able to convert sans huge strings is desired, I've updated that old function (see below) and AFAIK it could be used to replace Lib/decimal.py/Decimal.[__int__,__long__]. It gets about ten times faster on best cases and is about as slow on worst cases (could be much worse if long(rint_part + rdec_part)/exponent is a STUPID thing to do, but seems easy to avoid). As the original __int__ optimizes str(Decimal._int) and doesn't split/check for substrings, using the same path should speed this up more. I can run the tests and benchmark it (next month...) if there's interest. def dec2long(number): Convert decimal.Decimal to long (abridged, non-checking version) decimal_string = str(number) if e in decimal_string: radix, exponent = decimal_string.split(e) elif E in decimal_string: radix, exponent = decimal_string.split(E) else: radix, exponent = (decimal_string, 0) if exponent: exponent = int(exponent) if . in radix: rint, rdec = radix.split(.) radix_decimal_part_len = long(len(rdec)) if radix_decimal_part_len = exponent: radix_as_long = long(rint + rdec) corrected_exponent = exponent - radix_decimal_part_len result = radix_as_long * 10L** corrected_exponent else: result = long(rint + rdec) / exponent else: radix_as_long = long(radix) result = radix_as_long * 10L**exponent
[ python-Bugs-1772686 ] exec() doesn't take an open file
Bugs item #1772686, was opened at 2007-08-12 10:12
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1772686group_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: Closed
Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: exec() doesn't take an open file
Initial Comment:
exec() is documented to take an open file. The error message also says it
takes one, however:
exec(open('nn.py'))
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: exec() arg 1 must be a string, file, or code object, not
TextIOWrapper
--
Comment By: Brett Cannon (bcannon)
Date: 2007-08-12 12:16
Message:
Logged In: YES
user_id=357491
Originator: NO
This is a duplicate of bug #1762972 which Guido and I have already
discussed how to deal with this.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1772686group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770416 ] Decimal.__int__ overflows for large values
Bugs item #1770416, was opened at 2007-08-08 20:43 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770416group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Facundo Batista (facundobatista) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. from decimal import Decimal as D e = D(1e1234567890987654321) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer e = D(1e1234567890) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. -- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-12 19:43 Message: Logged In: YES user_id=703403 Originator: NO Mark Dickinson (marketdickinson) stupidly claimed that: hash(n) == hash(n % (2**32-1)) It's not true. Sorry for the noise. -- Comment By: Mark Dickinson (marketdickinson) Date: 2007-08-12 17:57 Message: Logged In: YES user_id=703403 Originator: NO Doesn't using hash(D.as_tuple()) break the principle that if two objects compare equal then they should have equal hash? An alternative to converting to long before hashing is to use the fact that for the current hash implementation for long we have hash(n) == hash(n % (2**32-1)) (except when n is a multiple of 2**32-1). For a Decimal d that's integral, one should be able to compute d % (2**32-1) very quickly: if d = c*10**e then just use (c * pow(10, e, 2**32-1)) % (2**32-1), which should be acceptably fast even when d = 123456789E999. The only tricky bit is that on a 64-bit system all those 2**32-1 need to be replaced by 2**64-1. Though now I come to think of it, since 2**32-1 is a factor of 2**64-1 it would be enough just to do everything modulo 2**64-1 even on a 32-bit system. -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-09 17:37 Message: Logged In: YES user_id=849994 Originator: NO Assigning to Facundo, he's actively working on decimal ATM. -- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 17:21 Message: Logged In: YES user_id=1200609 Originator: NO I see. Inheriting from Decimal and overloading __hash__ is a way to solve your problem, but it's IMHO a shallow bug and worth reporting. I just tried hash(D.as_tuple()) and it is blazing fast. I think that unless the official line is don't touch decimal.py until X, this change to hashing would be useful and (AFAICT) harmless enough to fit in e.g. 2.5.2. To avoid incompatibilities, __hash__ could check for Overflow and only use .as_tuple for values higher than the previous maximum (keeping, unfortunately, __hash__ slow for values below). Could the current status of Decimal be made a bit more clear? Are bug reports/patches welcome? Is bugging Facundo or RHettinger welcome? :) If getting __int__ a bit faster and able to convert sans huge strings is desired, I've updated that old function (see below) and AFAIK it could be used to replace Lib/decimal.py/Decimal.[__int__,__long__]. It gets about ten times faster on best cases and is about as slow on worst cases (could be much worse if long(rint_part + rdec_part)/exponent is a STUPID thing to do, but seems easy to avoid). As the original __int__ optimizes str(Decimal._int) and doesn't split/check for substrings, using the same path should speed this up more. I can run the tests and benchmark it (next month...) if there's interest. def dec2long(number): Convert decimal.Decimal to long (abridged, non-checking version) decimal_string = str(number) if e in decimal_string: radix, exponent = decimal_string.split(e) elif E in decimal_string: radix, exponent = decimal_string.split(E) else: radix, exponent = (decimal_string, 0) if exponent: exponent = int(exponent) if . in radix: rint, rdec = radix.split(.) radix_decimal_part_len = long(len(rdec)) if radix_decimal_part_len = exponent: radix_as_long = long(rint
[ python-Bugs-1772788 ] chr(128) in u'only ascii' - TypeError with misleading msg
Bugs item #1772788, was opened at 2007-08-13 01:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772788group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pekka Laukkanen (laukpe) Assigned to: Nobody/Anonymous (nobody) Summary: chr(128) in u'only ascii' - TypeError with misleading msg Initial Comment: A test using in format chr(x) in string raises a TypeError if x is in range 128-255 (i.e. non-ascii) and string is unicode. This happens even if the unicode string contains only ascii data as the example below demonstrates. Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type help, copyright, credits or license for more information. chr(127) in 'hello' False chr(128) in 'hello' False chr(127) in u'hi' False chr(128) in u'hi' Traceback (most recent call last): File stdin, line 1, in module TypeError: 'in string' requires string as left operand This can cause pretty nasty and hard-to-debug bugs in code using in string format if e.g. user provided data is converted to unicode internally. Most other string operations work nicely between normal and unicode strings and I'd say simply returning False in this situation would be ok too. Issuing a warning similarly as below might be a good idea also. chr(128) == u'' __main__:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal Finally, the error message is somewhat misleading since the left operand is definitely a string. type(chr(128)) type 'str' A real life example of code where this problem exist is telnetlib. I'll submit a separate bug about it as that problem can obviously be fixed in the library itself. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772788group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772794 ] Using telnetlib fails with unicode strings containing only a
Bugs item #1772794, was opened at 2007-08-13 02:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1772794group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pekka Laukkanen (laukpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using telnetlib fails with unicode strings containing only a
Initial Comment:
It is not possible to use unicode strings with telnetlib even if these strings
used only ascii characters. Example below demonstrates this.
Type help, copyright, credits or license for more information.
import telnetlib
telnetlib.Telnet().write(u'hi')
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.5/telnetlib.py, line 289, in write
if IAC in buffer:
TypeError: 'in string' requires string as left operand
This problem is caused by bug #1772788 chr(128) in u'only ascii' - TypeError
with misleading msg. The relevant code is following and IAC is chr(255).
def write(self, buffer):
if IAC in buffer:
buffer = buffer.replace(IAC, IAC+IAC)
self.msg(send %r, buffer)
self.sock.sendall(buffer)
There are many pretty obvious ways to have a workaround for the issue. I
suggest something like follows assuming that accepting unicode data is ok in
general. If unicode is not ok then pass can be replaced with something like
raise TypeError('Unicode data no accepted') to at least have a better error
message.
def write(self, buffer):
try:
buffer = buffer.replace(IAC, IAC+IAC)
except UnicodeError:
pass
self.msg(send %r, buffer)
self.sock.sendall(buffer)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1772794group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772794 ] Telnetlib dosn't accept unicode containing only ascii
Bugs item #1772794, was opened at 2007-08-13 02:17
Message generated for change (Settings changed) made by laukpe
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1772794group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pekka Laukkanen (laukpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Telnetlib dosn't accept unicode containing only ascii
Initial Comment:
It is not possible to use unicode strings with telnetlib even if these strings
used only ascii characters. Example below demonstrates this.
Type help, copyright, credits or license for more information.
import telnetlib
telnetlib.Telnet().write(u'hi')
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.5/telnetlib.py, line 289, in write
if IAC in buffer:
TypeError: 'in string' requires string as left operand
This problem is caused by bug #1772788 chr(128) in u'only ascii' - TypeError
with misleading msg. The relevant code is following and IAC is chr(255).
def write(self, buffer):
if IAC in buffer:
buffer = buffer.replace(IAC, IAC+IAC)
self.msg(send %r, buffer)
self.sock.sendall(buffer)
There are many pretty obvious ways to have a workaround for the issue. I
suggest something like follows assuming that accepting unicode data is ok in
general. If unicode is not ok then pass can be replaced with something like
raise TypeError('Unicode data no accepted') to at least have a better error
message.
def write(self, buffer):
try:
buffer = buffer.replace(IAC, IAC+IAC)
except UnicodeError:
pass
self.msg(send %r, buffer)
self.sock.sendall(buffer)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1772794group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1728488 ] -q (quiet) option for python interpreter
Feature Requests item #1728488, was opened at 2007-05-30 20:44 Message generated for change (Comment added) made by wojdyr You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=355470aid=1728488group_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: None Priority: 5 Private: No Submitted By: Marcin Wojdyr (wojdyr) Assigned to: Nobody/Anonymous (nobody) Summary: -q (quiet) option for python interpreter Initial Comment: I'd like to suggest the new option for python: -q Do not print the version and copyright messages. These messages are also suppressed in non-interactive mode. Why: I often use python as a calculator, for a couple-lines calculations, and would prefer to avoid having printed these three lines. There is a similar option in e.g. gdb. AFAICS the implementation would require small changes in Modules/main.c, Misc/python.man and probably in other docs. If it would be accepted, I can do it. Marcin -- Comment By: Marcin Wojdyr (wojdyr) Date: 2007-08-13 05:35 Message: Logged In: YES user_id=586843 Originator: YES - patch 1772833 -- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-03 04:06 Message: Logged In: YES user_id=942711 Originator: NO +1 for this option. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-08-02 06:26 Message: Logged In: YES user_id=80475 Originator: NO +1 I think this would be nice. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=355470aid=1728488group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721161 ] ERROR - Microsoft Visual C++ Runtime Library
Bugs item #1721161, was opened at 2007-05-18 08:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1721161group_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: 3rd Party Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: darioUniPD (dariounipd) Assigned to: Nobody/Anonymous (nobody) Summary: ERROR - Microsoft Visual C++ Runtime Library Initial Comment: While runnin a process in IDLE error (Python 2.5.1): == TitleOfMessageBox: Microsoft Visual C++ Runtime Library TheMessage: Runtime Error! Program: C:\[...]\python.exe The application has requested the Runtime to terminate it in an unusual way. Please content the application's support team for more information. == How to repair?! -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 07:09 Message: Logged In: YES user_id=849994 Originator: NO Closing as 3rd party. -- Comment By: Michael Toews (mwtoews) Date: 2007-08-10 21:38 Message: Logged In: YES user_id=1458205 Originator: NO According to http://matplotlib.sourceforge.net/backends.html this is a problem with the Tkinter GUI backend used through Pythonwin. -- Comment By: darioUniPD (dariounipd) Date: 2007-05-18 12:27 Message: Logged In: YES user_id=1796163 Originator: YES Sorry, I forget about it! I'm using PyLab (MatPlotLib) and ftplib mainly. Other packages I used are os and time, but I think that the problem is not here. Thanks! -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 09:39 Message: Logged In: YES user_id=849994 Originator: NO Please provide more information. What process did you try to run, and when did the error occur? It is very likely that the cause of this problem is a third-party extension module. Which modules do you load in your program? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1721161group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721161 ] ERROR - Microsoft Visual C++ Runtime Library
Bugs item #1721161, was opened at 2007-05-18 08:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1721161group_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: 3rd Party Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: darioUniPD (dariounipd) Assigned to: Nobody/Anonymous (nobody) Summary: ERROR - Microsoft Visual C++ Runtime Library Initial Comment: While runnin a process in IDLE error (Python 2.5.1): == TitleOfMessageBox: Microsoft Visual C++ Runtime Library TheMessage: Runtime Error! Program: C:\[...]\python.exe The application has requested the Runtime to terminate it in an unusual way. Please content the application's support team for more information. == How to repair?! -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 07:10 Message: Logged In: YES user_id=849994 Originator: NO Closing as 3rd party. -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-11 07:09 Message: Logged In: YES user_id=849994 Originator: NO Closing as 3rd party. -- Comment By: Michael Toews (mwtoews) Date: 2007-08-10 21:38 Message: Logged In: YES user_id=1458205 Originator: NO According to http://matplotlib.sourceforge.net/backends.html this is a problem with the Tkinter GUI backend used through Pythonwin. -- Comment By: darioUniPD (dariounipd) Date: 2007-05-18 12:27 Message: Logged In: YES user_id=1796163 Originator: YES Sorry, I forget about it! I'm using PyLab (MatPlotLib) and ftplib mainly. Other packages I used are os and time, but I think that the problem is not here. Thanks! -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 09:39 Message: Logged In: YES user_id=849994 Originator: NO Please provide more information. What process did you try to run, and when did the error occur? It is very likely that the cause of this problem is a third-party extension module. Which modules do you load in your program? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1721161group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772481 ] urllib2 hangs with some documents.
Bugs item #1772481, was opened at 2007-08-12 01:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772481group_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: Creature (acreature) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 hangs with some documents. Initial Comment: While working on a web spider I encountered the following page that causes the read() call of a urllib2 response to fail. It uses 100% of the CPU and does not seem to ever return. I have this behaviour on Python 2.4.4, but several people on 2.5.1 have tried the code below and reported the same behaviour. By the way, the page it uses is a porn site, but please don't get hung up on that fact. This is a data processing issue, not a subject matter issue. This test case is attached as a file, but is also available at http://pastebin.com/d6f98618f . Please note that the user-agent masquerading is present to rule out any issues with the server returning different data to different clients; commenting out the line so Python sends the standard headers still results in the issue occuring. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772481group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772489 ] dir() on traceback objects returns an empty list
Bugs item #1772489, was opened at 2007-08-11 19:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772489group_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: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: dir() on traceback objects returns an empty list Initial Comment: The current status of the py3k branch is that calling dir() on a traceback object does not produce the expected results: a 4-element list of the tb_* attributes. The attached patch restores this behaviour and adds a regression test to test_builtins. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-11 19:34 Message: Logged In: YES user_id=33168 Originator: NO I was the one that broke this when I removed __members__ and __methods__. I was hoping we could get rid of the getattr. See the XXX comment near the top of the file. If that can't be removed this patch should at least by applied. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1772489group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1771260 ] Errors in site.py not reported properly
Bugs item #1771260, was opened at 2007-08-09 15:37 Message generated for change (Comment added) made by rhamphoryncus You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1771260group_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: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: Errors in site.py not reported properly Initial Comment: (Ignore the p3yk dir name. This has been updated to the py3k branch.) [EMAIL PROTECTED]:~/src/python-p3yk/build$ make object : type: TypeError refcount: 4 address : 0x8239f0c lost sys.stderr make: *** [sharedmods] Error 1 The root cause is that (due to some local modifications) site.py failed to load and gave an error. This can be easily duplicated by opening up Lib/site.py:main and putting 1/0 on the first line. However, the ZeroDivisionError that should cause never gets printed. Python/pythonrun.c:initsite attempts to retrieve sys.stderr, which fails because site.py never got a chance to install it (!), then passes the NULL file object pointer to PyFile_WriteString, which turns that into a new exception (replacing the old one). initsite ignores the return value indicating the exception, instead clearing it, and the interpreter continues to load, no one the wiser. Several other exceptions may happen and get squashed, I'm not sure. Eventually, Python/sysmodule.c:sys_excepthook calls Python/pythonrun.c:PyErr_Display, which attempts to retrieve sys.stderr, and failing that calls _PyObject_Dump() on the exception (explaining the weird message). Oddly, there's a *second* if statement, which then prints the lost sys.stderr line. Possible remedies: 1. PyErr_Display's dump message is not very clear. 2. initsite should go directly to stderr if it can't retrieve sys.stderr. Alternatively, since site.py is now more important, it could be changed into a fatal error. Yet another option is to explicitly check for sys.stderr even on success and make that alone into a fatal error. 3. The error printing APIs could be modified to internalize the stderr retrieval. Upon failure they could print a brief stderr unavailable; original exception was ... message. -- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-08-10 12:19 Message: Logged In: YES user_id=12364 Originator: YES Following up on the possible remedies, I'm thinking PySys_WriteStderr could be extended to take file object as the first argument, and if null it writes to low-level stderr instead. That way the callers can add the message about lost sys.stderr themselves, rather than it being interspersed in their output. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1771260group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1771558 ] minor bug in turtle
Bugs item #1771558, was opened at 2007-08-10 11:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1771558group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeremy Sanders (jeremysanders) Assigned to: Nobody/Anonymous (nobody) Summary: minor bug in turtle Initial Comment: xpc17:~:$ python Python 2.5 (r25:51908, Apr 10 2007, 10:27:40) [GCC 4.1.2 20070403 (Red Hat 4.1.2-8)] on linux2 Type help, copyright, credits or license for more information. import turtle turtle.demo2() Traceback (most recent call last): File stdin, line 1, in module File /usr/lib64/python2.5/lib-tk/turtle.py, line 874, in demo2 sleep(2) NameError: global name 'sleep' is not defined Sleep needs to be imported from the time module before it is used. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1771558group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1771483 ] another 'nothing to repeat'
Bugs item #1771483, was opened at 2007-08-10 08:56
Message generated for change (Settings changed) made by viciousdog
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1771483group_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: Deleted
Resolution: None
Priority: 5
Private: No
Submitted By: viciousdog (viciousdog)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: another 'nothing to repeat'
Initial Comment:
Hi,
rxSlice = re.compile('\[([^:\]]*):([^:\[]?){1}(:[^:\[]+)?\]')
compiles, but
rxSlice = re.compile('\[([^:\]]*):([^:\[]*){1}(:[^:\[]+)?\]')
produces: error: nothing to repeat
(Python 2.5.1 in idle on Windows XPpro)
Perhaps that 'nothing to repeat' is intended for {x} (i wouldn't like that at
all), but then it must not differenciate between * and ?.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1771483group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1771483 ] another 'nothing to repeat'
Bugs item #1771483, was opened at 2007-08-10 08:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1771483group_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: viciousdog (viciousdog)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: another 'nothing to repeat'
Initial Comment:
Hi,
rxSlice = re.compile('\[([^:\]]*):([^:\[]?){1}(:[^:\[]+)?\]')
compiles, but
rxSlice = re.compile('\[([^:\]]*):([^:\[]*){1}(:[^:\[]+)?\]')
produces: error: nothing to repeat
(Python 2.5.1 in idle on Windows XPpro)
Perhaps that 'nothing to repeat' is intended for {x} (i wouldn't like that at
all), but then it must not differenciate between * and ?.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1771483group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1721161 ] ERROR - Microsoft Visual C++ Runtime Library
Bugs item #1721161, was opened at 2007-05-18 01:12 Message generated for change (Comment added) made by mwtoews You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1721161group_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: darioUniPD (dariounipd) Assigned to: Nobody/Anonymous (nobody) Summary: ERROR - Microsoft Visual C++ Runtime Library Initial Comment: While runnin a process in IDLE error (Python 2.5.1): == TitleOfMessageBox: Microsoft Visual C++ Runtime Library TheMessage: Runtime Error! Program: C:\[...]\python.exe The application has requested the Runtime to terminate it in an unusual way. Please content the application's support team for more information. == How to repair?! -- Comment By: Michael Toews (mwtoews) Date: 2007-08-10 14:38 Message: Logged In: YES user_id=1458205 Originator: NO According to http://matplotlib.sourceforge.net/backends.html this is a problem with the Tkinter GUI backend used through Pythonwin. -- Comment By: darioUniPD (dariounipd) Date: 2007-05-18 05:27 Message: Logged In: YES user_id=1796163 Originator: YES Sorry, I forget about it! I'm using PyLab (MatPlotLib) and ftplib mainly. Other packages I used are os and time, but I think that the problem is not here. Thanks! -- Comment By: Georg Brandl (gbrandl) Date: 2007-05-18 02:39 Message: Logged In: YES user_id=849994 Originator: NO Please provide more information. What process did you try to run, and when did the error occur? It is very likely that the cause of this problem is a third-party extension module. Which modules do you load in your program? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1721161group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633941 ] for line in sys.stdin: doesn't notice EOF the first time
Bugs item #1633941, was opened at 2007-01-12 02:34 Message generated for change (Comment added) made by marhar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1633941group_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: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: for line in sys.stdin: doesn't notice EOF the first time Initial Comment: [forwarded from http://bugs.debian.org/315888] for line in sys.stdin: doesn't notice EOF the first time when reading from tty. The test program: import sys for line in sys.stdin: print line, print eof A sample session: [EMAIL PROTECTED] python foo.py foo --- I pressed Enter and then Ctrl-D foo --- then this appeared, but not more eof --- this only came when I pressed Ctrl-D a second time [EMAIL PROTECTED] Seems to me that there is some buffering issue where Python needs to read end-of-file twice to notice it on all levels. Once should be enough. -- Comment By: Mark Harrison (marhar) Date: 2007-08-10 13:01 Message: Logged In: YES user_id=40482 Originator: NO I think this should be considered a bug. These two command lines (on unix) should behave the same: cat | ./foo.py ./foo.py But they do not. The first (using cat) behaves typically, needing only one control-D. The second needs the two control-D's as noted. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-04-25 11:04 Message: Logged In: YES user_id=984087 Originator: NO BTW, I opened bug 1643712 for doc change. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-24 09:20 Message: Logged In: YES user_id=984087 Originator: NO I tested two kinds of inputs with iter and noiter verisons. I posted noter code and OP's code is the iter version. 1) For input without newline at all (line1CTRL-DCTRL-DCTRL-D) behaves same with both versions. 2) The noiter version prints eof with line1\nCTRL-D while the iter version requires an additional CTRL-D. This is because iter version uses read ahead which is implemented using fread() . A simple C program using fread() behaves exactly same way. I tested on Linux but am sure windows behaviour (as posted by gagenellina) will have same reasons. Since the issue is with platform's stdio library, I don't think python should fix anything here. However, it may be worthwhile to mention something about this in documentation. I will open a bug for this purpose. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 09:45 Message: Logged In: YES user_id=984087 Originator: NO Ok. This may sound stupid but I couldn't find a way to attach a file to this bug report. So I am copying the code here: import sys line = sys.stdin.readline() while (line): print line, line = sys.stdin.readline() print eof * -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 09:37 Message: Logged In: YES user_id=984087 Originator: NO Sorry for my duplicate comment. It was a mistake. On closer examination, the OP's description does seem to indicate some issue. Please look at (attached) stdin_noiter.py which uses readline() directly and it does not have the problem described here. It properly detects EOF on first CTRL-D. This points to some problem with the iterator function fileobject.c:file_iternext(). I think that the first CTRL-D might be getting lost somewhere in the read ahead code (which only comes into picture with iterator). -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 08:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py testfile This command behaves as expected. Only when the input is from tty, the above described behaviour happens. That could be because of the terminal settings where characters may be buffered until a newline is entered. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 08:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py testfile This command behaves as expected. Only when the input is from tty, the above
[ python-Bugs-1770416 ] Decimal.__int__ overflows for large values
Bugs item #1770416, was opened at 2007-08-08 17:43 Message generated for change (Comment added) made by ajaksu2 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770416group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Nobody/Anonymous (nobody) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. from decimal import Decimal as D e = D(1e1234567890987654321) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer e = D(1e1234567890) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. -- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 05:09 Message: Logged In: YES user_id=1200609 Originator: NO Hi Jason, The OverflowError is related to index-sized ints as in ints that are valid indexes for sequences, try: e = 0 * 1234567890 So it seems that this error is avoiding the creation of a string of length 1234567890, which is a good thing (sorta) :) Once I tried to implement a dec2long function that was based on numbers instead of strings, see if it helps (it's VERY slow and naive, but IIRC it was a bit faster than the original version and correct): http://groups.google.com/group/comp.lang.python/msg/aba7264ab38eb25e Now, do you really need all that precision for such huge numbers? I know I didn't ;) Daniel -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770416group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770416 ] Decimal.__int__ overflows for large values
Bugs item #1770416, was opened at 2007-08-08 18:13 Message generated for change (Comment added) made by aryx You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770416group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Nobody/Anonymous (nobody) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. from decimal import Decimal as D e = D(1e1234567890987654321) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer e = D(1e1234567890) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. -- Comment By: Jason G (aryx) Date: 2007-08-09 12:39 Message: Logged In: YES user_id=1289703 Originator: YES Hey Daniel, The bigger issue for us is mostly the fact that Decimal.__hash__ us calling Decimal.__int__ and not because we want an integer/long version of a very large Decimal. We do not actually cast the decimal into an int/long explicitly. I wouldn't have any issues if Decimal.__int__ remained as it is, but I think it would be a good idea for Decimal.__hash__ to do something differently. Probably something that is fast and simple, such as hash( self.as_tuple() ), self being a Decimal of course. Our project is a CAS and we use Decimal for our real number class. I happened to run into this issue when I was implementing approximation of log(x) for extremely large/small values of x. I just started keyboard bashing numbers and behold, Decimal crashed on me :) -- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 05:39 Message: Logged In: YES user_id=1200609 Originator: NO Hi Jason, The OverflowError is related to index-sized ints as in ints that are valid indexes for sequences, try: e = 0 * 1234567890 So it seems that this error is avoiding the creation of a string of length 1234567890, which is a good thing (sorta) :) Once I tried to implement a dec2long function that was based on numbers instead of strings, see if it helps (it's VERY slow and naive, but IIRC it was a bit faster than the original version and correct): http://groups.google.com/group/comp.lang.python/msg/aba7264ab38eb25e Now, do you really need all that precision for such huge numbers? I know I didn't ;) Daniel -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770416group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770416 ] Decimal.__int__ overflows for large values
Bugs item #1770416, was opened at 2007-08-08 17:43 Message generated for change (Comment added) made by ajaksu2 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770416group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Nobody/Anonymous (nobody) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. from decimal import Decimal as D e = D(1e1234567890987654321) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer e = D(1e1234567890) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. -- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 14:21 Message: Logged In: YES user_id=1200609 Originator: NO I see. Inheriting from Decimal and overloading __hash__ is a way to solve your problem, but it's IMHO a shallow bug and worth reporting. I just tried hash(D.as_tuple()) and it is blazing fast. I think that unless the official line is don't touch decimal.py until X, this change to hashing would be useful and (AFAICT) harmless enough to fit in e.g. 2.5.2. To avoid incompatibilities, __hash__ could check for Overflow and only use .as_tuple for values higher than the previous maximum (keeping, unfortunately, __hash__ slow for values below). Could the current status of Decimal be made a bit more clear? Are bug reports/patches welcome? Is bugging Facundo or RHettinger welcome? :) If getting __int__ a bit faster and able to convert sans huge strings is desired, I've updated that old function (see below) and AFAIK it could be used to replace Lib/decimal.py/Decimal.[__int__,__long__]. It gets about ten times faster on best cases and is about as slow on worst cases (could be much worse if long(rint_part + rdec_part)/exponent is a STUPID thing to do, but seems easy to avoid). As the original __int__ optimizes str(Decimal._int) and doesn't split/check for substrings, using the same path should speed this up more. I can run the tests and benchmark it (next month...) if there's interest. def dec2long(number): Convert decimal.Decimal to long (abridged, non-checking version) decimal_string = str(number) if e in decimal_string: radix, exponent = decimal_string.split(e) elif E in decimal_string: radix, exponent = decimal_string.split(E) else: radix, exponent = (decimal_string, 0) if exponent: exponent = int(exponent) if . in radix: rint, rdec = radix.split(.) radix_decimal_part_len = long(len(rdec)) if radix_decimal_part_len = exponent: radix_as_long = long(rint + rdec) corrected_exponent = exponent - radix_decimal_part_len result = radix_as_long * 10L** corrected_exponent else: result = long(rint + rdec) / exponent else: radix_as_long = long(radix) result = radix_as_long * 10L**exponent else: if . in radix: radix_integer_part = long(radix.split(.)[0]) else: radix_integer_part = long(radix) result = radix_integer_part return result As a comparison, here's __int__ (abridged) from decimal.py: def __int__(number): Converts self to an int, truncating if necessary. if number._exp = 0: s = ''.join(map(str, number._int)) + '0'*number._exp else: s = ''.join(map(str, number._int))[:number._exp] if s == '': s = '0' sign = '-'*self._sign return int(sign + s) -- Comment By: Jason G (aryx) Date: 2007-08-09 12:09 Message: Logged In: YES user_id=1289703 Originator: YES Hey Daniel, The bigger issue for us is mostly the fact that Decimal.__hash__ us calling Decimal.__int__ and not because we want an integer/long version of a very large Decimal. We do not actually cast the decimal into an int/long explicitly. I wouldn't have any issues if Decimal.__int__ remained as it is, but I think it would be a good idea for Decimal.__hash__ to do something differently. Probably something that is fast and simple, such as hash( self.as_tuple() ), self
[ python-Bugs-1770416 ] Decimal.__int__ overflows for large values
Bugs item #1770416, was opened at 2007-08-08 20:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770416group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Facundo Batista (facundobatista) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. from decimal import Decimal as D e = D(1e1234567890987654321) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer e = D(1e1234567890) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-09 17:37 Message: Logged In: YES user_id=849994 Originator: NO Assigning to Facundo, he's actively working on decimal ATM. -- Comment By: ajaksu (ajaksu2) Date: 2007-08-09 17:21 Message: Logged In: YES user_id=1200609 Originator: NO I see. Inheriting from Decimal and overloading __hash__ is a way to solve your problem, but it's IMHO a shallow bug and worth reporting. I just tried hash(D.as_tuple()) and it is blazing fast. I think that unless the official line is don't touch decimal.py until X, this change to hashing would be useful and (AFAICT) harmless enough to fit in e.g. 2.5.2. To avoid incompatibilities, __hash__ could check for Overflow and only use .as_tuple for values higher than the previous maximum (keeping, unfortunately, __hash__ slow for values below). Could the current status of Decimal be made a bit more clear? Are bug reports/patches welcome? Is bugging Facundo or RHettinger welcome? :) If getting __int__ a bit faster and able to convert sans huge strings is desired, I've updated that old function (see below) and AFAIK it could be used to replace Lib/decimal.py/Decimal.[__int__,__long__]. It gets about ten times faster on best cases and is about as slow on worst cases (could be much worse if long(rint_part + rdec_part)/exponent is a STUPID thing to do, but seems easy to avoid). As the original __int__ optimizes str(Decimal._int) and doesn't split/check for substrings, using the same path should speed this up more. I can run the tests and benchmark it (next month...) if there's interest. def dec2long(number): Convert decimal.Decimal to long (abridged, non-checking version) decimal_string = str(number) if e in decimal_string: radix, exponent = decimal_string.split(e) elif E in decimal_string: radix, exponent = decimal_string.split(E) else: radix, exponent = (decimal_string, 0) if exponent: exponent = int(exponent) if . in radix: rint, rdec = radix.split(.) radix_decimal_part_len = long(len(rdec)) if radix_decimal_part_len = exponent: radix_as_long = long(rint + rdec) corrected_exponent = exponent - radix_decimal_part_len result = radix_as_long * 10L** corrected_exponent else: result = long(rint + rdec) / exponent else: radix_as_long = long(radix) result = radix_as_long * 10L**exponent else: if . in radix: radix_integer_part = long(radix.split(.)[0]) else: radix_integer_part = long(radix) result = radix_integer_part return result As a comparison, here's __int__ (abridged) from decimal.py: def __int__(number): Converts self to an int, truncating if necessary. if number._exp = 0: s = ''.join(map(str, number._int)) + '0'*number._exp else: s = ''.join(map(str, number._int))[:number._exp] if s == '': s = '0' sign = '-'*self._sign return int(sign + s) -- Comment By: Jason G (aryx) Date: 2007-08-09 15:09 Message: Logged In: YES user_id=1289703 Originator: YES Hey Daniel, The bigger issue for us is mostly the fact that Decimal.__hash__ us calling Decimal.__int__ and not because we want an integer/long version of a very large Decimal. We do not actually cast the decimal
[ python-Bugs-1771260 ] Errors in site.py not reported properly
Bugs item #1771260, was opened at 2007-08-09 15:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1771260group_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: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: Errors in site.py not reported properly Initial Comment: (Ignore the p3yk dir name. This has been updated to the py3k branch.) [EMAIL PROTECTED]:~/src/python-p3yk/build$ make object : type: TypeError refcount: 4 address : 0x8239f0c lost sys.stderr make: *** [sharedmods] Error 1 The root cause is that (due to some local modifications) site.py failed to load and gave an error. This can be easily duplicated by opening up Lib/site.py:main and putting 1/0 on the first line. However, the ZeroDivisionError that should cause never gets printed. Python/pythonrun.c:initsite attempts to retrieve sys.stderr, which fails because site.py never got a chance to install it (!), then passes the NULL file object pointer to PyFile_WriteString, which turns that into a new exception (replacing the old one). initsite ignores the return value indicating the exception, instead clearing it, and the interpreter continues to load, no one the wiser. Several other exceptions may happen and get squashed, I'm not sure. Eventually, Python/sysmodule.c:sys_excepthook calls Python/pythonrun.c:PyErr_Display, which attempts to retrieve sys.stderr, and failing that calls _PyObject_Dump() on the exception (explaining the weird message). Oddly, there's a *second* if statement, which then prints the lost sys.stderr line. Possible remedies: 1. PyErr_Display's dump message is not very clear. 2. initsite should go directly to stderr if it can't retrieve sys.stderr. Alternatively, since site.py is now more important, it could be changed into a fatal error. Yet another option is to explicitly check for sys.stderr even on success and make that alone into a fatal error. 3. The error printing APIs could be modified to internalize the stderr retrieval. Upon failure they could print a brief stderr unavailable; original exception was ... message. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1771260group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1771381 ] bsddb can't use unicode keys
Bugs item #1771381, was opened at 2007-08-10 04:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1771381group_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: Unicode Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Erol Aktay (moghe) Assigned to: M.-A. Lemburg (lemburg) Summary: bsddb can't use unicode keys Initial Comment: bsddb throws a TypeError when I try to use an unicode string as key name; i.e. bsddb.btopen(foobar, c)[u'foo'] = bar fails I discovered it while experimenting with the shelve module. You may find more information in the attached file. Python version: 2.5.1 OS: Windows XP SP2 (5.1.2600) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1771381group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770551 ] words able to decode but unable to encode in GB18030
Bugs item #1770551, was opened at 2007-08-08 18:34
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1770551group_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: Unicode
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Z-flagship (zaex)
Assigned to: Hye-Shik Chang (perky)
Summary: words able to decode but unable to encode in GB18030
Initial Comment:
Here is a list of chinese characters that can be read from a file [in GB18030
encoding], but unable to encode to GB18030 encoding
detailed:
used codecs.open(r'file name', encoding='GB18030') to read the characters from
a file, and try to encode them word by word into GB18030 with
word.encode('GB18030'). The action caused an exception with 'illegal multibyte
sequence'
the attachment is also the list.
list:
䎬䎱䅟䌷䦟䦷䲠㧏㭎㘚㘎㱮䴔䴖䴗䦆㧟䙡䙌䴕䁖䎬䴙䥽䝼䞍䓖䲡䥇䦂䦅䴓㩳㧐㳠䲢䴘㖞䜣䥺䶮䜩䥺䲟䲣䦛䦶㑳㑇㥮㤘䏝䦃
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-08-09 20:35
Message:
Logged In: YES
user_id=33168
Originator: NO
This seems like a cjk problem. Hye-Shik, could you take a look?
--
Comment By: Z-flagship (zaex)
Date: 2007-08-08 18:37
Message:
Logged In: YES
user_id=1863611
Originator: YES
The Python is Python2.5 , my OS is windows XP professional sp2 version
2002
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1770551group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770009 ] decimal.Decimal(trash) produces informationless exception
Bugs item #1770009, was opened at 2007-08-08 05:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770009group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Machin (sjmachin) Assigned to: Facundo Batista (facundobatista) Summary: decimal.Decimal(trash) produces informationless exception Initial Comment: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import decimal decimal.Decimal(-$123,456.78) Traceback (most recent call last): File stdin, line 1, in module File C:\python25\lib\decimal.py, line 614, in __new__ self._sign, self._int, self._exp = context._raise_error(ConversionSyntax) File C:\python25\lib\decimal.py, line 2325, in _raise_error raise error, explanation decimal.InvalidOperation It should do something like float does ... better message, and show the offending arg: float(-$123,456.78) Traceback (most recent call last): File stdin, line 1, in module ValueError: invalid literal for float(): -$123,456.78 -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-08-09 20:36 Message: Logged In: YES user_id=33168 Originator: NO Facundo, could you take a look? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770009group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770009 ] decimal.Decimal(trash) produces informationless exception
Bugs item #1770009, was opened at 2007-08-08 22:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770009group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Machin (sjmachin) Assigned to: Nobody/Anonymous (nobody) Summary: decimal.Decimal(trash) produces informationless exception Initial Comment: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import decimal decimal.Decimal(-$123,456.78) Traceback (most recent call last): File stdin, line 1, in module File C:\python25\lib\decimal.py, line 614, in __new__ self._sign, self._int, self._exp = context._raise_error(ConversionSyntax) File C:\python25\lib\decimal.py, line 2325, in _raise_error raise error, explanation decimal.InvalidOperation It should do something like float does ... better message, and show the offending arg: float(-$123,456.78) Traceback (most recent call last): File stdin, line 1, in module ValueError: invalid literal for float(): -$123,456.78 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770009group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770190 ] platform.mac_ver() returning incorrect patch version
Bugs item #1770190, was opened at 2007-08-08 13:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1770190group_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: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gus Tabares (gtabares)
Assigned to: Jack Jansen (jackjansen)
Summary: platform.mac_ver() returning incorrect patch version
Initial Comment:
Running on an Intel Mac OSX 10.4.10 machine:
platform.mac_ver()
('10.4.9', ('', '', ''), 'i386')
I have reproduced this on 4 other (Intel Mac) machines. I don't have access to
a 10.4.10 PPC machine.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1770190group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770416 ] Decimal.__int__ overflows for large values
Bugs item #1770416, was opened at 2007-08-08 18:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770416group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (aryx) Assigned to: Nobody/Anonymous (nobody) Summary: Decimal.__int__ overflows for large values Initial Comment: This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__. from decimal import Decimal as D e = D(1e1234567890987654321) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp OverflowError: cannot fit 'long' into an index-sized integer e = D(1e1234567890) int(e) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.5/decimal.py, line 1501, in __int__ s = ''.join(map(str, self._int)) + '0'*self._exp MemoryError Also, for values that do work this is incredibly slow if they are still fairly large. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1770416group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770190 ] platform.mac_ver() returning incorrect patch version
Bugs item #1770190, was opened at 2007-08-08 20:08
Message generated for change (Comment added) made by jackjansen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1770190group_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: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gustavo Tabares (gtabares)
Assigned to: Jack Jansen (jackjansen)
Summary: platform.mac_ver() returning incorrect patch version
Initial Comment:
Running on an Intel Mac OSX 10.4.10 machine:
platform.mac_ver()
('10.4.9', ('', '', ''), 'i386')
I have reproduced this on 4 other (Intel Mac) machines. I don't have access to
a 10.4.10 PPC machine.
--
Comment By: Jack Jansen (jackjansen)
Date: 2007-08-09 00:05
Message:
Logged In: YES
user_id=45365
Originator: NO
Interesting problem! Mac_ver() basically uses gestalt() with a selector of
'sysv' and this will return '9' for the micro-version if it is 9 or
greater.
It could be fixed, according to
http://www.adobeforums.com/cgi-bin/webx?14@@.3bc49a09/0 by using three
calls to gestalt() with selectors 'sys1', 'sys2' and 'sys3', which will
return the three numbers correctly.
I'm not sure whether these selectors are always available, will
investigate.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1770190group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770551 ] words able to decode but unable to encode in GB18030
Bugs item #1770551, was opened at 2007-08-09 01:34
Message generated for change (Comment added) made by zaex
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1770551group_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: Unicode
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Z-flagship (zaex)
Assigned to: M.-A. Lemburg (lemburg)
Summary: words able to decode but unable to encode in GB18030
Initial Comment:
Here is a list of chinese characters that can be read from a file [in GB18030
encoding], but unable to encode to GB18030 encoding
detailed:
used codecs.open(r'file name', encoding='GB18030') to read the characters from
a file, and try to encode them word by word into GB18030 with
word.encode('GB18030'). The action caused an exception with 'illegal multibyte
sequence'
the attachment is also the list.
list:
䎬䎱䅟䌷䦟䦷䲠㧏㭎㘚㘎㱮䴔䴖䴗䦆㧟䙡䙌䴕䁖䎬䴙䥽䝼䞍䓖䲡䥇䦂䦅䴓㩳㧐㳠䲢䴘㖞䜣䥺䶮䜩䥺䲟䲣䦛䦶㑳㑇㥮㤘䏝䦃
--
Comment By: Z-flagship (zaex)
Date: 2007-08-09 01:37
Message:
Logged In: YES
user_id=1863611
Originator: YES
The Python is Python2.5 , my OS is windows XP professional sp2 version
2002
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1770551group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1767933 ] Badly formed XML using etree and utf-16
Bugs item #1767933, was opened at 2007-08-05 17:01
Message generated for change (Comment added) made by effbot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1767933group_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: XML
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: BugoK (bugok)
Assigned to: Fredrik Lundh (effbot)
Summary: Badly formed XML using etree and utf-16
Initial Comment:
Hello,
The bug occurs when writing an XML file using the UTF-16 encoding.
The problem is that the etree encodes every string to utf-16 by itself -
meaning, inserting the 0xfffe BOM before every string (tag, text, attribute
name, etc.), causing a badly formed utf=16 strings.
A possible solution, which was offered by a co-worker of mine, was to use a
utf-16 writer (from codecs.getwriter('utf-16') to write the file.
Best,
BugoK.
--
Comment By: Fredrik Lundh (effbot)
Date: 2007-08-07 08:20
Message:
Logged In: YES
user_id=38376
Originator: NO
ET's standard serializer currently only supports ASCII-compatible
encodings. See e.g.
http://effbot.python-hosting.com/ticket/47
The best workaround for ET 1.2 (Python 2.5) is probably to serialize as
utf-8 and transcode:
out = unicode(ET.tostring(elem), utf-8).encode(...)
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-08-07 07:54
Message:
Logged In: YES
user_id=33168
Originator: NO
Fredrik, could you take a look at this?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1767933group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1769002 ] A paragraph about packages should be updated.
Bugs item #1769002, was opened at 2007-08-07 06:44 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1769002group_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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: A paragraph about packages should be updated. Initial Comment: The page about packages says: When packages are structured into subpackages (as with the Sound package in the example), there's no shortcut to refer to submodules of sibling packages - the full name of the subpackage must be used ... This isn't true, a thing which becomes apparant once you read the next paragraph, about relative imports in Python 2.5. Thanks, Noam -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-07 07:13 Message: Logged In: YES user_id=849994 Originator: NO Thanks, fixed in rev. 56797, 56798 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1769002group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1645148 ] MIME renderer: wrong header line break with long subject?
Bugs item #1645148, was opened at 2007-01-26 11:04
Message generated for change (Comment added) made by kxroberto
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1645148group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: kxroberto (kxroberto)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: MIME renderer: wrong header line break with long subject?
Initial Comment:
from email.MIMEText import MIMEText
o=MIMEText('hello')
o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4
5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 '
o.as_string()
'Content-Type: text/plain; charset=us-ascii\nMIME-Version: 1.0\nContent-Transf
er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8
9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\
nhello'
The '6 7 8\n\t9 1 2 3' clashes together to 6 7 89 1 2 3
without space between 89 in usual mail readers.
Is this an error and should be :
'6 7 8 \n\t9 1 2 3'
?
as there is also the space preserved in
'6 7 8 9 \n\nhello'
--
Comment By: kxroberto (kxroberto)
Date: 2007-08-06 19:18
Message:
Logged In: YES
user_id=972995
Originator: YES
the bug appears to be quite frequent now (once one knows it :-) ).
Possibly for the same reason one sees this kind of subject alteration by
one space often on the usenet.
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-06-09 07:19
Message:
Logged In: YES
user_id=479790
Originator: NO
Quoting RFC2822 section 2.2.3
ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt:
The general rule is that wherever this standard allows for folding
white space (not simply WSP characters), a CRLF may be inserted before any
WSP. For example, the header field:
Subject: This is a test
can be represented as:
Subject: This
is a test
[...]Unfolding is accomplished by simply removing any CRLF that is
immediately followed by WSP.
That is, folding is done by inserting ONLY the sequence CRLF before any
folding whitespace. When the header is interpreted, the whitespace is NOT
removed, only the CRLF. The posted Subject header should become Subject: 1
2 3...7 8\n\r 9 1 2...'
I think this is a bug in the email.header.Header class; its __init__ says,
about the continuation_ws argument: [it] must be RFC 2822 compliant
folding whitespace (usually either a space or a hard tab) which will be
prepended to continuation lines.. Folding does not involve *prepending*
any whitespace, just inserting CRLF right before *existing* whitespace.
Note that this is wrong even for the old RFC 822 (with slightly different
rules for line folding.)
--
Comment By: kxroberto (kxroberto)
Date: 2007-06-08 14:11
Message:
Logged In: YES
user_id=972995
Originator: YES
What would be the RFC definition for a correct auto-line break in a
(subject) mail header line?
Wouldn't it be more simple to not do any auto-line break for the subject?
or is there a requirement for the line break in the RFC. Don't think any
reader program would fail because of 79 char subject header lines.
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-11 22:17
Message:
Logged In: YES
user_id=12800
Originator: NO
Whoops, this wasn't supposed to be a response to Tokio, but instead the
OP.
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2007-03-11 22:16
Message:
Logged In: YES
user_id=12800
Originator: NO
Tokio, I'm not so sure about adding that extra space. I tested all the
mail readers at my disposal on Linux and OSX. I don't have any Windows
machines available so I couldn't test Outlook or OE. (If you have them,
please indicate what they do in a comment here!) Here's what I found:
OSX:
Mail.app 2.1.1 -- the extra space produces an extra space between the 8
and 9 both in the message summary and in the Subject header in the preview
pane. The no extra space message looks fine.
Thunderbird 1.5.0.10 -- The extra space message produces an extra space
in the message summary, while the no extra space message looks fine here.
But the weird thing is that in both the extra space and non-extra space
cases, the Subject header in the preview pane both have extra spaces. It
looks to me like the leading tab is being inserted into the Subject header
view.
Entourage 11.3.3 -- The extra space shows up in both the summary and
preview panes but only in the message
[ python-Bugs-1768767 ] tutorial
Bugs item #1768767, was opened at 2007-08-06 12:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1768767group_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: Michael R Bax (mrbax) Assigned to: Nobody/Anonymous (nobody) Summary: tutorial Initial Comment: tutorial -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1768767group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1768767 ] tutorial
Bugs item #1768767, was opened at 2007-08-06 12:08 Message generated for change (Settings changed) made by mrbax You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1768767group_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: Deleted Resolution: None Priority: 5 Private: No Submitted By: Michael R Bax (mrbax) Assigned to: Nobody/Anonymous (nobody) Summary: tutorial Initial Comment: tutorial -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1768767group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1731717 ] race condition in subprocess module
Bugs item #1731717, was opened at 2007-06-06 08:19 Message generated for change (Comment added) made by abo You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1731717group_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: dsagal (dsagal) Assigned to: Peter Åstrand (astrand) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global _cleanup() function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object foo in one thread, and then a.wait(), and meanwhile I create another Popen object bar in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen((/bin/ls, -a, /tmp), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: Traceback (most recent call last): File /usr/lib/python2.4/threading.py, line 442, in __bootstrap self.run() File /usr/lib/python2.4/threading.py, line 422, in run self.__target(*self.__args, **self.__kwargs) File z.py, line 21, in tt s.communicate()[0] File /usr/lib/python2.4/subprocess.py, line 1083, in communicate self.wait() File /usr/lib/python2.4/subprocess.py, line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. -- Comment By: Donovan Baarda (abo) Date: 2007-08-07 05:45 Message: Logged In: YES user_id=10273 Originator: NO I can create a patch to make current head a bit cleaner, if anyone is interested... -- Comment By: Donovan Baarda (abo) Date: 2007-08-04 07:29 Message: Logged In: YES user_id=10273 Originator: NO I just looked at subprocess in svs trunk and it looks like it might already be fixed in both subprocess.py and popen2.py. The part where __del__() adds abandoned Popen instances to _active and _cleanup() removes them is already there. _cleanup() has been made more thread resistant by catching and ignoring exceptions that arise when two _cleanups() try to remove the same instances. Popen.poll() has been made more robust by having it set self.returncode to an optional _deadstate argument value when poll gets an os.error from os.pidwait() on a child that gets cleaned up by another thread. I think there are still a few minor race conditions around Popen.poll(), but it will only affect what non-zero returncode you get... it's not so much thread safe as thread robust. I think the _deadstate argument approach to try and make Popen.poll() thread-robust is a bit hacky. I would rather see _cleanup() be properly threadsafe by having it remove the inst from _active before processing it and re-adding it back if it is still not finished. However, as it is now it looks like it is fixed... -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-04 06:11 Message: Logged In: YES user_id=6380 Originator: NO If you want this fixed in 2.5.x, a new release is just around the corner, and time is very tight. Otherwise, 2.6a1 is half a year off. -- Comment By: Donovan Baarda (abo) Date: 2007-08-04 05:26 Message: Logged In: YES user_id=10273 Originator: NO Actually, after thinking about it, there may be a way to make _cleanup() threadsafe without using explicit locks by leveraging off the GIL. If _active.pop() and _active.append() are atomic because of the GIL, then _cleanup() can be made
[ python-Bugs-1731717 ] race condition in subprocess module
Bugs item #1731717, was opened at 2007-06-06 00:19 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1731717group_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: dsagal (dsagal) Assigned to: Peter Åstrand (astrand) Summary: race condition in subprocess module Initial Comment: Python's subprocess module has a race condition: Popen() constructor has a call to global _cleanup() function on whenever a Popen object gets created, and that call causes a check for all pending Popen objects whether their subprocess has exited - i.e. the poll() method is called for every active Popen object. Now, if I create Popen object foo in one thread, and then a.wait(), and meanwhile I create another Popen object bar in another thread, then a.poll() might get called by _clean() right at the time when my first thread is running a.wait(). But those are not synchronized - each calls os.waitpid() if returncode is None, but the section which checks returncode and calls os.waitpid() is not protected as a critical section should be. The following code illustrates the problem, and is known to break reasonably consistenly with Python2.4. Changes to subprocess in Python2.5 seems to address a somewhat related problem, but not this one. import sys, os, threading, subprocess, time class X(threading.Thread): def __init__(self, *args, **kwargs): super(X, self).__init__(*args, **kwargs) self.start() def tt(): s = subprocess.Popen((/bin/ls, -a, /tmp), stdout=subprocess.PIPE, universal_newlines=True) # time.sleep(1) s.communicate()[0] for i in xrange(1000): X(target = tt) This typically gives a few dozen errors like these: Exception in thread Thread-795: Traceback (most recent call last): File /usr/lib/python2.4/threading.py, line 442, in __bootstrap self.run() File /usr/lib/python2.4/threading.py, line 422, in run self.__target(*self.__args, **self.__kwargs) File z.py, line 21, in tt s.communicate()[0] File /usr/lib/python2.4/subprocess.py, line 1083, in communicate self.wait() File /usr/lib/python2.4/subprocess.py, line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes Note that uncommenting time.sleep(1) fixes the problem. So does wrapping subprocess.poll() and wait() with a lock. So does removing the call to global _cleanup() in Popen constructor. -- Comment By: Peter Åstrand (astrand) Date: 2007-08-06 22:02 Message: Logged In: YES user_id=344921 Originator: NO I can create a patch to make current head a bit cleaner, if anyone is interested... Sure, this would be great. I would also love a test case that reproduces this problem. -- Comment By: Donovan Baarda (abo) Date: 2007-08-06 21:45 Message: Logged In: YES user_id=10273 Originator: NO I can create a patch to make current head a bit cleaner, if anyone is interested... -- Comment By: Donovan Baarda (abo) Date: 2007-08-03 23:29 Message: Logged In: YES user_id=10273 Originator: NO I just looked at subprocess in svs trunk and it looks like it might already be fixed in both subprocess.py and popen2.py. The part where __del__() adds abandoned Popen instances to _active and _cleanup() removes them is already there. _cleanup() has been made more thread resistant by catching and ignoring exceptions that arise when two _cleanups() try to remove the same instances. Popen.poll() has been made more robust by having it set self.returncode to an optional _deadstate argument value when poll gets an os.error from os.pidwait() on a child that gets cleaned up by another thread. I think there are still a few minor race conditions around Popen.poll(), but it will only affect what non-zero returncode you get... it's not so much thread safe as thread robust. I think the _deadstate argument approach to try and make Popen.poll() thread-robust is a bit hacky. I would rather see _cleanup() be properly threadsafe by having it remove the inst from _active before processing it and re-adding it back if it is still not finished. However, as it is now it looks like it is fixed... -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-08-03 22:11 Message: Logged In: YES user_id=6380 Originator: NO If you want this fixed in 2.5.x, a new release is just around the corner, and time is very tight. Otherwise, 2.6a1 is half a year off
[ python-Bugs-1768858 ] Python - Operation time out problem
Bugs item #1768858, was opened at 2007-08-06 17:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1768858group_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: MASK (mohammedsk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python - Operation time out problem
Initial Comment:
I have a program that reads from a file some search terms. The script uses
Medline record parser pub med dictionary.
Since I search so many terms, the script times out. Here is the error:
Traceback (most recent call last):
File (stdin), line1, in module
File search_all.py,line71, in module
Cur_record = medline_dict [id]
File C:\Python25\Lib\site-packages\PubMed.py, line 103,
in_getitem_raise Key Error,x
Key Error: IOError('socket error',error(10060,'Operation timed out'))
I looked online for solutions and one solution was to add the following to the
script:
import socket
socket.setdefaulttimeout(value)
But this code did not do anything, the script continues on timing out.
A complete Python script is attached.
Any help is appreciated.
Thanks,
Mohammed
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1768858group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
