[ python-Bugs-1460514 ] ctypes extension does not compile on Mac OS 10.3.9
Bugs item #1460514, was opened at 2006-03-29 01:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: ctypes extension does not compile on Mac OS 10.3.9 Initial Comment: I compiled Python from CVS this morning. It silently failed to compile ctypes. Here is the text surrounding the failure gcc [deleted] -c /Users/dalke/cvses/python-svn/Modules/_ctypes/ libffi/src/powerpc/darwin_closure.S -o build/temp.darwin-7.9.0- Power_Macintosh-2.5/darwin_closure.o darwin_closure.S:249:unknown section attribute: live_support darwin_closure.S:249:Rest of line ignored. 1st junk character valued 69 (E). building 'itertools' extension ... Python installed but when I tried to import ctypes I got File "/usr/local/lib/python2.5/ctypes/__init__.py", line 8, in from _ctypes import Union, Structure, Array ImportError: No module named _ctypes I tracked it down to the '+live_support' attribute from the darwin_closure.S. My compiler does not understand that. Thomas Heller (in private email) pointed out the text from the ctypes README On OS X, the segment attribute live_support must be defined. If your compiler doesn't know about it, upgrade or set the environment variable CCASFLAGS="-Dno_live_support". Upgrading is out of the option. I set the environment variable but that did not fix things when I tried to recompile Python. However, editing the file to remove the "+live_support" works. All the self-tests passed, and my experimentation this afternoon was successful. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460340 ] random.sample can raise KeyError
Bugs item #1460340, was opened at 2006-03-29 00:05
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.sample can raise KeyError
Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.
If you initialize a dictionary as follows:
a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))
then
random.sample(a,3)
raises KeyError most times that you call it.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 09:11
Message:
Logged In: YES
user_id=849994
random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.
I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460340 ] random.sample can raise KeyError
Bugs item #1460340, was opened at 2006-03-28 19:05
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.sample can raise KeyError
Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.
If you initialize a dictionary as follows:
a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))
then
random.sample(a,3)
raises KeyError most times that you call it.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-29 04:17
Message:
Logged In: YES
user_id=80475
Checked-in a fix.
See revision 43420 and 43421.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 04:11
Message:
Logged In: YES
user_id=849994
random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.
I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460514 ] ctypes extension does not compile on Mac OS 10.3.9
Bugs item #1460514, was opened at 2006-03-29 08:28 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Andrew Dalke (dalke) >Assigned to: Thomas Heller (theller) Summary: ctypes extension does not compile on Mac OS 10.3.9 Initial Comment: I compiled Python from CVS this morning. It silently failed to compile ctypes. Here is the text surrounding the failure gcc [deleted] -c /Users/dalke/cvses/python-svn/Modules/_ctypes/ libffi/src/powerpc/darwin_closure.S -o build/temp.darwin-7.9.0- Power_Macintosh-2.5/darwin_closure.o darwin_closure.S:249:unknown section attribute: live_support darwin_closure.S:249:Rest of line ignored. 1st junk character valued 69 (E). building 'itertools' extension ... Python installed but when I tried to import ctypes I got File "/usr/local/lib/python2.5/ctypes/__init__.py", line 8, in from _ctypes import Union, Structure, Array ImportError: No module named _ctypes I tracked it down to the '+live_support' attribute from the darwin_closure.S. My compiler does not understand that. Thomas Heller (in private email) pointed out the text from the ctypes README On OS X, the segment attribute live_support must be defined. If your compiler doesn't know about it, upgrade or set the environment variable CCASFLAGS="-Dno_live_support". Upgrading is out of the option. I set the environment variable but that did not fix things when I tried to recompile Python. However, editing the file to remove the "+live_support" works. All the self-tests passed, and my experimentation this afternoon was successful. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460564 ] Misleading documentation for socket.fromfd()
Bugs item #1460564, was opened at 2006-03-29 11:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460564&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Smith (mlrsmith) Assigned to: Nobody/Anonymous (nobody) Summary: Misleading documentation for socket.fromfd() Initial Comment: The socket.fromfd() method does not correctly document what it does, in a way that is likely to cause users to leak file descriptors. Proposed fix: --- Modules/socketmodule.c 2005-09-14 20:15:03.0 +0200 +++ /home/msmith/src/Python-2.4.2/Modules/socketmodule.c 2006-03-29 11:28:35.0 +0200 @@ -3077,7 +3077,8 @@ PyDoc_STRVAR(fromfd_doc, "fromfd(fd, family, type[, proto]) -> socket object\n\ \n\ -Create a socket object from the given file descriptor.\n\ +Duplicate the given file descriptor, and create a socket\n\ +object from the duplicate.\r\ The remaining arguments are the same as for socket()."); #endif /* NO_DUP */ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460564&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460340 ] random.sample can raise KeyError
Bugs item #1460340, was opened at 2006-03-29 00:05
Message generated for change (Comment added) made by phr
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.sample can raise KeyError
Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.
If you initialize a dictionary as follows:
a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))
then
random.sample(a,3)
raises KeyError most times that you call it.
--
>Comment By: paul rubin (phr)
Date: 2006-03-29 09:46
Message:
Logged In: YES
user_id=72053
I don't think the fix at 43421 is quite right, but I can't
easily test it in my current setup. Suppose
a = dict.fromkeys(range(99) + ['x'])
b = random.sample(a,1)
99% of the time, there's no KeyError and b gets set to [j]
where j is some random integer.
1% of the time, there's a KeyError, random.sample is called
recursively, and the recursive call returns [some integer j]
99% of the time, and returns ['x'] 1% of the time.
So in total, ['x'] gets returned .01% of the time instead of
1% of the time.
I think it's better to not set result[i]=population[j]
inside the loop. Instead, just build up the selected set
until it has enough indices; then try to make a result list
using those indices, and if there's a KeyError, convert the
population to a list and use the same selection set to make
the results.
gbrandl also correctly points out that a dict is not a
sequence type, so maybe it's ok to just punt on dicts. But
it's obvious from the code comments that somebody once
wanted dicts to work, and it's reasonable for people to want
sets to work.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-29 09:17
Message:
Logged In: YES
user_id=80475
Checked-in a fix.
See revision 43420 and 43421.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 09:11
Message:
Logged In: YES
user_id=849994
random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.
I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460340 ] random.sample can raise KeyError
Bugs item #1460340, was opened at 2006-03-29 00:05
Message generated for change (Comment added) made by phr
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.sample can raise KeyError
Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.
If you initialize a dictionary as follows:
a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))
then
random.sample(a,3)
raises KeyError most times that you call it.
--
>Comment By: paul rubin (phr)
Date: 2006-03-29 10:07
Message:
Logged In: YES
user_id=72053
Actually the previous comment is wrong too; 99% of the time,
sample(a,1) will return None since that's the value
connected to every key in the dictionary, i.e. it's
population[j] for every j. The other 1% of the time, the
dict gets converted to a list, and the sample returns a key
from the dict rather than a value, which is certainly wrong.
And you can see how the probabilities are still messed up
if the values in the dict are distinct.
I think it's ok to give up on dicts, but some warning should
about it be added to the manual unless dict-like things
somehow get detected in the code. It would be best to test
for the object really being a sequence, but I don't know if
such a test exists. Maybe one should be added.
I'll leave it to you guys to reopen this bug if appropriate.
--
Comment By: paul rubin (phr)
Date: 2006-03-29 09:46
Message:
Logged In: YES
user_id=72053
I don't think the fix at 43421 is quite right, but I can't
easily test it in my current setup. Suppose
a = dict.fromkeys(range(99) + ['x'])
b = random.sample(a,1)
99% of the time, there's no KeyError and b gets set to [j]
where j is some random integer.
1% of the time, there's a KeyError, random.sample is called
recursively, and the recursive call returns [some integer j]
99% of the time, and returns ['x'] 1% of the time.
So in total, ['x'] gets returned .01% of the time instead of
1% of the time.
I think it's better to not set result[i]=population[j]
inside the loop. Instead, just build up the selected set
until it has enough indices; then try to make a result list
using those indices, and if there's a KeyError, convert the
population to a list and use the same selection set to make
the results.
gbrandl also correctly points out that a dict is not a
sequence type, so maybe it's ok to just punt on dicts. But
it's obvious from the code comments that somebody once
wanted dicts to work, and it's reasonable for people to want
sets to work.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-29 09:17
Message:
Logged In: YES
user_id=80475
Checked-in a fix.
See revision 43420 and 43421.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 09:11
Message:
Logged In: YES
user_id=849994
random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.
I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460605 ] Python 2.4.2 does not compile on SunOS 5.10 using gcc
Bugs item #1460605, was opened at 2006-03-29 13:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460605&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jakob Schiøtz (schiotz) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2 does not compile on SunOS 5.10 using gcc Initial Comment: Core Python does not compile on my university's Sun server. $ ./configure --prefix=$HOME $ gmake [ lots of output deleted ] gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/cobject.o Objects/cobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:476: error: invalid operands to binary == Objects/complexobject.c:476: error: wrong type argument to unary minus Objects/complexobject.c:476: error: invalid operands to binary == Objects/complexobject.c:476: error: wrong type argument to unary minus gmake: *** [Objects/complexobject.o] Error 1 $ uname -a SunOS hald 5.10 Generic_118822-18 sun4u sparc SUNW,Sun-Fire-15000 ~/src/Python-2.4.2 $ gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460605&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460340 ] random.sample can raise KeyError
Bugs item #1460340, was opened at 2006-03-28 19:05
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
>Status: Open
>Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: random.sample can raise KeyError
Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.
If you initialize a dictionary as follows:
a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))
then
random.sample(a,3)
raises KeyError most times that you call it.
--
>Comment By: Tim Peters (tim_one)
Date: 2006-03-29 08:02
Message:
Logged In: YES
user_id=31435
Ya, this is flaky for dicts; re-opening. For example,
>>> d = dict((i, complex(i, i)) for i in xrange(30))
>>> random.sample(d, 5) # ask for 5 and it samples values
[(25+25j), (4+4j), (16+16j), (13+13j), (17+17j)]
>>> random.sample(d, 6) # ask for 6 and it samples keys
[20, 11, 9, 4, 14, 1]
That one doesn't have to do with internal exceptions, it has
only to do with which of sample()'s internal algorithms gets
used.
Paul's point about potential bias is also a worry. Here's a
full example:
"""
from random import sample
d = dict.fromkeys(range(24))
d['x'] = 'y'
count = hits = 0
while 1:
count += 1
hits += sample(d, 1) == ['x']
if count % 1 == 0:
print count, "%.2f%%" % (100.0 * hits / count)
"""
Since len(d) == 25, I'd hope to see 'x' selected 1/25 = 4%
of the time. Instead it gets selected 0.16% of the time
(1/25**2 -- and Paul's analysis of why is on target).
--
Comment By: paul rubin (phr)
Date: 2006-03-29 05:07
Message:
Logged In: YES
user_id=72053
Actually the previous comment is wrong too; 99% of the time,
sample(a,1) will return None since that's the value
connected to every key in the dictionary, i.e. it's
population[j] for every j. The other 1% of the time, the
dict gets converted to a list, and the sample returns a key
from the dict rather than a value, which is certainly wrong.
And you can see how the probabilities are still messed up
if the values in the dict are distinct.
I think it's ok to give up on dicts, but some warning should
about it be added to the manual unless dict-like things
somehow get detected in the code. It would be best to test
for the object really being a sequence, but I don't know if
such a test exists. Maybe one should be added.
I'll leave it to you guys to reopen this bug if appropriate.
--
Comment By: paul rubin (phr)
Date: 2006-03-29 04:46
Message:
Logged In: YES
user_id=72053
I don't think the fix at 43421 is quite right, but I can't
easily test it in my current setup. Suppose
a = dict.fromkeys(range(99) + ['x'])
b = random.sample(a,1)
99% of the time, there's no KeyError and b gets set to [j]
where j is some random integer.
1% of the time, there's a KeyError, random.sample is called
recursively, and the recursive call returns [some integer j]
99% of the time, and returns ['x'] 1% of the time.
So in total, ['x'] gets returned .01% of the time instead of
1% of the time.
I think it's better to not set result[i]=population[j]
inside the loop. Instead, just build up the selected set
until it has enough indices; then try to make a result list
using those indices, and if there's a KeyError, convert the
population to a list and use the same selection set to make
the results.
gbrandl also correctly points out that a dict is not a
sequence type, so maybe it's ok to just punt on dicts. But
it's obvious from the code comments that somebody once
wanted dicts to work, and it's reasonable for people to want
sets to work.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-03-29 04:17
Message:
Logged In: YES
user_id=80475
Checked-in a fix.
See revision 43420 and 43421.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-29 04:11
Message:
Logged In: YES
user_id=849994
random.sample is documented to take a sequence as its first
argument. A dict is not a sequence type.
I think you want
random.sample(a.keys(), 3)
or, for large dicts,
random.sample(a.iterkeys(), 3)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&gro
[ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active
Bugs item #1199282, was opened at 2005-05-10 20:24
Message generated for change (Comment added) made by tfaujour
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Peter Ã
strand (astrand)
Summary: subprocess _active.remove(self) self not in list _active
Initial Comment:
I start a subprocess in a seperate thread (25 concurrent
threads)
in some of the threads the following error occurs
Exception in thread Thread-4:
Traceback (most recent call last):
File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
self.run()
File "upgrade.py", line 45, in run
returncode = p.wait()
File "C:\Python24\lib\subprocess.py", line 765, in wait
_active.remove(self)
ValueError: list.remove(x): x not in list
this is the code that starts the subprocess and where I
wait for the result
p = subprocess.Popen('command', \
stdin=None,
stdout=subprocess.PIPE, \
stderr=subprocess.STDOUT,
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()
--
Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 15:50
Message:
Logged In: YES
user_id=1488657
> Simply list operations such as remove() and append() are
> thread safe,
OK, my apologies... I did not know.
I did some more tests. On Linux, I found lots of:
File "./subprocess.py", line 428, in call
return Popen(*args, **kwargs).wait()
File "./subprocess.py", line 1023, in wait
pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes
The try...except solution does not handle this (since we are
in the "posix" section).
In my opinion, the call to _cleanup() in Popen.__init__() is
useless (it just checks if older processes have stopped when
a new one is started. I cannot see why it could be
mandatory) and it is the root of this bug.
I commented it out (line 506) and retried my tests on Linux
& Windows plateforms: I had no exception at all.
--
Comment By: Peter Ã
strand (astrand)
Date: 2006-03-29 07:11
Message:
Logged In: YES
user_id=344921
>I think accesses to _active should be serialized in a
>thread-safe way. _active could be a Queue (from the Queue
>module) for example
Simply list operations such as remove() and append() are
thread safe, so there should be no need for a Queue. Also, a
Queue cannot be used since the subprocess module needs to be
compatible with Python 2.2.
--
Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 01:17
Message:
Logged In: YES
user_id=1488657
I am running into the same problem on a Windows 2k/XP
plateform with a multi-threaded application. It occurs randomly.
It has never appened (yet) on a Linux plateform.
I think accesses to _active should be serialized in a
thread-safe way. _active could be a Queue (from the Queue
module) for example.
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-25 09:10
Message:
Logged In: YES
user_id=1434251
Wouldn't it be best to completely remove any references
to "_active" and "_cleanup"?
--
Comment By: cheops (atila-cheops)
Date: 2006-01-25 08:08
Message:
Logged In: YES
user_id=1276121
As suggested by astrand
adding a try ... except clause in the file subprocess.py did
the job
I had to add that try ... except clause in 2 places
if you look in the file there are 2 instances were
list.remove(x) occurs unprotected.
try:
list.remove(x)
except:
pass
I have worked with 2.4.0, 2.4.1 and 2.4.2 and all three
needed the patch.
Hope this helps.
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 17:34
Message:
Logged In: YES
user_id=1434251
BTW: In my case, I call python.exe from a Windows service.
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 17:30
Message:
Logged In: YES
user_id=1434251
I have a similar problem.
Python 2.4.1 under MS Windows 2003,
Multi-Threaded application (about concurrent 10 threads).
In my case the same error occurs during _cleanup called
from __init__ :
File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t
hreadutil.py", line 582, in callSubProcess
creationflags = creationflags
File "C:\Python24\lib\subprocess.py", line 506, in
__init__
_cleanup()
File "C:\Pytho
[ python-Bugs-1081824 ] Rewrite of docs for compiler.visitor
Bugs item #1081824, was opened at 2004-12-09 02:06 Message generated for change (Comment added) made by kjohnson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081824&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Jeremy Hylton (jhylton) Summary: Rewrite of docs for compiler.visitor Initial Comment: I was recently prompted to look at the docs for compiler.visitor (Lib Ref 19.4 Using Visitors to Walk ASTs). With all due respect it is not up to the standards of most of the docs. I have attempted a rewrite which is in the attachment. I suggest also that the entry for walk() on the main compiler doc page (19.1) should be updated to refer to 19.4 for details. HTH Kent -- >Comment By: Kent Johnson (kjohnson) Date: 2006-03-29 13:53 Message: Logged In: YES user_id=49695 Hmmph. A year later I see I didn't actually attach my suggested rewrite. Trying again. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081824&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460493 ] Why not drop the _active list?
Bugs item #1460493, was opened at 2006-03-29 09:16 Message generated for change (Comment added) made by tfaujour You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: HVB bei TUP (hvb_tup) Assigned to: Nobody/Anonymous (nobody) Summary: Why not drop the _active list? Initial Comment: I am using a modified version of subprocess.py, where I have removed the _active list and all references to it. I have tested it (under Windows 2000) and there were no errors. So what is the reason for managing the _active list at all? Why not drop it? -- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-29 15:59 Message: Logged In: YES user_id=1488657 I agree. The use of _active makes subprocess.py thread-UNsafe. See also: Bug #1199282 In order to have a thread-safe subprocess.py, I commented out the call to _cleanup() in Popen.__init__(). As a side effect, _active becomes useless. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1457783 ] Malloc error on MacOSX/imaplib
Bugs item #1457783, was opened at 2006-03-24 10:10 Message generated for change (Settings changed) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1457783&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: Malloc error on MacOSX/imaplib Initial Comment: I am using Python 2.4.2 on MacOSX (10.4.5). Fetching mails with larger attachments (2MB or so) using IMAP (with getmail) fails: python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) malloc: *** vm_allocate(size=262144) failed (error code=3) python2.4(5615) malloc: *** error: can't allocate region python2.4(5615) malloc: *** set a breakpoint in szone_error to debug python2.4(5615) mallo
[ python-Bugs-1460886 ] Broken __hash__ for Unicode objects
Bugs item #1460886, was opened at 2006-03-29 19:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Broken __hash__ for Unicode objects
Initial Comment:
http://docs.python.org/ref/customization.html says
equal objects should hash to the same value. But this
is not the case when the default Unicode encoding has
been changed (by e.g. importing PyGTK).
Using Python 2.4.2:
>>> import sys
>>> reload(sys)
>>> sys.setdefaultencoding('utf-8')
>>> hash(u"\u1234"), hash(str(u"\u1234"))
(-518661067, -1855038154)
>>> u"\u1234" == str(u"\u1234")
True
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460886 ] Broken __hash__ for Unicode objects
Bugs item #1460886, was opened at 2006-03-29 21:16
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: None
Status: Open
>Resolution: Invalid
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Broken __hash__ for Unicode objects
Initial Comment:
http://docs.python.org/ref/customization.html says
equal objects should hash to the same value. But this
is not the case when the default Unicode encoding has
been changed (by e.g. importing PyGTK).
Using Python 2.4.2:
>>> import sys
>>> reload(sys)
>>> sys.setdefaultencoding('utf-8')
>>> hash(u"\u1234"), hash(str(u"\u1234"))
(-518661067, -1855038154)
>>> u"\u1234" == str(u"\u1234")
True
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-29 21:54
Message:
Logged In: YES
user_id=38388
This is a known fact.
When changing the default encoding, you are basically on
your own, so there's nothing much we can about it.
BTW, the above hack that you're using to get at the
sys.setdefaultencoding() API already indicates that you're
leaving the path of standard Python.
We deliberatly remove that API from the sys module in
site.py to make changing the default encoding an explicit task.
If importing PyGTK has the side-effect of applying such a
hack, then PyGTK is seriously broken and you should report
this to their developers.
Closing as "Invalid".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460886 ] Broken __hash__ for Unicode objects
Bugs item #1460886, was opened at 2006-03-29 21:16
Message generated for change (Settings changed) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: None
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Broken __hash__ for Unicode objects
Initial Comment:
http://docs.python.org/ref/customization.html says
equal objects should hash to the same value. But this
is not the case when the default Unicode encoding has
been changed (by e.g. importing PyGTK).
Using Python 2.4.2:
>>> import sys
>>> reload(sys)
>>> sys.setdefaultencoding('utf-8')
>>> hash(u"\u1234"), hash(str(u"\u1234"))
(-518661067, -1855038154)
>>> u"\u1234" == str(u"\u1234")
True
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-29 21:54
Message:
Logged In: YES
user_id=38388
This is a known fact.
When changing the default encoding, you are basically on
your own, so there's nothing much we can about it.
BTW, the above hack that you're using to get at the
sys.setdefaultencoding() API already indicates that you're
leaving the path of standard Python.
We deliberatly remove that API from the sys module in
site.py to make changing the default encoding an explicit task.
If importing PyGTK has the side-effect of applying such a
hack, then PyGTK is seriously broken and you should report
this to their developers.
Closing as "Invalid".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1442493 ] IDLE shell window gets very slow when displaying long lines
Bugs item #1442493, was opened at 2006-03-03 14:45 Message generated for change (Comment added) made by drhok You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Heiko Selber (drhok) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE shell window gets very slow when displaying long lines Initial Comment: I wrote a little python script that prints a large dictionary to stdout (simply using 'print mydictionary'). In fact, the type is irrelevant, what matters is that the resulting output had approx. 200,000 characters. The shell prints the dictionary into a single line, which causes the window to be almost non-responding, e.g. when I try to scroll the window. Even on a high-end PC it takes a minute or even longer to react to anything. I use Python 2.4.2 on Windows XP SP2. I am aware that it is not exactly wise to print such large objects, but I usually print return values to stdout when I debug a script, and I do not always expect an object to be that large. The average text editor handles such long lines much better. A quick workaround might be to break very long lines automagically (perhaps at around column 1000). PS: I already observed the bug some years ago. I think I even submitted it to python or idlefork a long time ago but I was unable to find it in the buglist. -- >Comment By: Heiko Selber (drhok) Date: 2006-03-29 20:19 Message: Logged In: YES user_id=865975 Hi kbk, well, my use case is debugging. I write a script and run it with IDLE. It doesn't behave as expected, so I insert a print statement. Next time I run it, IDLE hangs. Oops, it was a long array; it should have been an int. Line too long. Duh. OK, I wait through it, correct the bug, run it again. What happens? IDLE hangs again, trying to scroll a long line (of the previous run). Never mind, I can always kill the process... Dammit, I can't! It eats 100% CPU; task manager doesn't respond. IMHO his takes away one of python's strengths, which is making quick hacks really quick. Would you suggest redirecting this issue to tkinter? You don't seem to consider this an issue at all. I will give squeezer a try. Or maybe PyDev? -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-03-28 23:08 Message: Logged In: YES user_id=149084 This is a known problem with Tk/Tcl/tkinter - large output scrolls slowly. It's not something that can be fixed in IDLE. I tried it on Arch Linux - IDLE 2.5a0 - Tk 8.4. 250,000 character output not too bad , 25 sec, but 10,000 lines of 25 char takes over twice that long, so breaking the lines doesn't help. I don't see any response problem once the output completes. The situation is exponentially worse at 500,000 char. What is your use case? IDLE is designed to be an IDE. Why output such massive data? You may be interested in Squeezer, a Noam Raphael extension to IDLEfork. http://sourceforge.net/tracker/index.php? func=detail&aid=704316&group_id=9579&atid=309579 I haven't tried it myself, but it might be what you're looking for. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-03-10 20:18 Message: Logged In: YES user_id=341410 Generally speaking, most wrapping text controls have issues with wrapping long lines. It would seem reasonable to get the width of the text control in characters, and manually wrap all incoming lines regardless. If the existance or not of real line endings are important, one could mark which lines are manually wrapped and remove the line endings on copy (edit->copy, ctrl+c, etc.). -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-09 23:45 Message: Logged In: YES user_id=593130 I verified this with print 10*'a', also XP (home) sp2. The sluggishness continued after getting the prompt back and trying to do something simple, like 2+2, taking maybe 1/2 minute to print 4 and then the >>> prompt again. The sluggishness *also* continued after restarting the shell (^F6). This indicates that the problem is with the window, not with IDLE. Hope someone can try same on *nix system to see if general with TKinter or specific to Win systems. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options
[ python-Feature Requests-1453973 ] addheaders for urlopen / open / xxxx_open
Feature Requests item #1453973, was opened at 2006-03-19 10:55
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453973&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: addheaders for urlopen / open / _open
Initial Comment:
Adding a header also for each open call is a frequent
need for me (much more than e.g. proxies per call in
urllib1/urlopen).
For example:
urlopen(url,data,addheaders=[('Referer':lasturl)])
So far one is forced to set the _complete_ re-rendered
bunch of opener.addheaders each time (and to maintain a
separate opener for each thread )
open/OpenerDirector.open maybe should distribute
*args,**kwargs
---
Note on disciplined use of protocol modules in urllib2
( see also #1046077 ):
urllib2 still draws in all kind of (future?) protocol
modules all in advance => slows down app startup / cgi
script's ...; ugly non-pythonic/non-modular; unused
prots cannot be excluded for cx_Freeze,setup ...
Now the fat cookielib was also added in that manner.
Thus, when you use urllib2 for "ftp://xy";, you load
also all kind of fun (down to things like
_MozillaCookieJar) into Python.
The need for those imports is very local (search e.g.
"ftplib."). ==> local import in those few places.
I saw, this jam style already encouraged more
undisciplined dependencies like :
"origin_req_host = cookielib.request_host(self)"
(~urllib2-py2.4/line 191) in the general Request.__init__
Robert
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-29 12:27
Message:
Logged In: YES
user_id=341410
Whether or not urllib2 imports generally unneeded modules is
a different matter than whether inserting headers should be
easier. In the future, please separate feature requests
from random chatter about a module.
I'm personally for making it easier to include alternate
headers, though am ambiguous as to your suggested change.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1453973&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1442493 ] IDLE shell window gets very slow when displaying long lines
Bugs item #1442493, was opened at 2006-03-03 06:45 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Heiko Selber (drhok) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE shell window gets very slow when displaying long lines Initial Comment: I wrote a little python script that prints a large dictionary to stdout (simply using 'print mydictionary'). In fact, the type is irrelevant, what matters is that the resulting output had approx. 200,000 characters. The shell prints the dictionary into a single line, which causes the window to be almost non-responding, e.g. when I try to scroll the window. Even on a high-end PC it takes a minute or even longer to react to anything. I use Python 2.4.2 on Windows XP SP2. I am aware that it is not exactly wise to print such large objects, but I usually print return values to stdout when I debug a script, and I do not always expect an object to be that large. The average text editor handles such long lines much better. A quick workaround might be to break very long lines automagically (perhaps at around column 1000). PS: I already observed the bug some years ago. I think I even submitted it to python or idlefork a long time ago but I was unable to find it in the buglist. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-03-29 12:35 Message: Logged In: YES user_id=341410 You can close the window which includes the Shell that has the huge output, or even reduce the priority of your Idle shell (you can make it automatic by mucking about with the shortcut; see the 'start' command). -- Comment By: Heiko Selber (drhok) Date: 2006-03-29 12:19 Message: Logged In: YES user_id=865975 Hi kbk, well, my use case is debugging. I write a script and run it with IDLE. It doesn't behave as expected, so I insert a print statement. Next time I run it, IDLE hangs. Oops, it was a long array; it should have been an int. Line too long. Duh. OK, I wait through it, correct the bug, run it again. What happens? IDLE hangs again, trying to scroll a long line (of the previous run). Never mind, I can always kill the process... Dammit, I can't! It eats 100% CPU; task manager doesn't respond. IMHO his takes away one of python's strengths, which is making quick hacks really quick. Would you suggest redirecting this issue to tkinter? You don't seem to consider this an issue at all. I will give squeezer a try. Or maybe PyDev? -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-03-28 15:08 Message: Logged In: YES user_id=149084 This is a known problem with Tk/Tcl/tkinter - large output scrolls slowly. It's not something that can be fixed in IDLE. I tried it on Arch Linux - IDLE 2.5a0 - Tk 8.4. 250,000 character output not too bad , 25 sec, but 10,000 lines of 25 char takes over twice that long, so breaking the lines doesn't help. I don't see any response problem once the output completes. The situation is exponentially worse at 500,000 char. What is your use case? IDLE is designed to be an IDE. Why output such massive data? You may be interested in Squeezer, a Noam Raphael extension to IDLEfork. http://sourceforge.net/tracker/index.php? func=detail&aid=704316&group_id=9579&atid=309579 I haven't tried it myself, but it might be what you're looking for. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-03-10 12:18 Message: Logged In: YES user_id=341410 Generally speaking, most wrapping text controls have issues with wrapping long lines. It would seem reasonable to get the width of the text control in characters, and manually wrap all incoming lines regardless. If the existance or not of real line endings are important, one could mark which lines are manually wrapped and remove the line endings on copy (edit->copy, ctrl+c, etc.). -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-09 15:45 Message: Logged In: YES user_id=593130 I verified this with print 10*'a', also XP (home) sp2. The sluggishness continued after getting the prompt back and trying to do something simple, like 2+2, taking maybe 1/2 minute to print 4 and then the >>> prompt again. The sluggishness *also* continued after restarting the shell (^F6). This indicates that the problem is with the window, not with IDLE. Hope someone can tr
[ python-Bugs-1460605 ] Python 2.4.2 does not compile on SunOS 5.10 using gcc
Bugs item #1460605, was opened at 2006-03-29 13:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460605&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jakob Schiøtz (schiotz) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2 does not compile on SunOS 5.10 using gcc Initial Comment: Core Python does not compile on my university's Sun server. $ ./configure --prefix=$HOME $ gmake [ lots of output deleted ] gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/cobject.o Objects/cobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:476: error: invalid operands to binary == Objects/complexobject.c:476: error: wrong type argument to unary minus Objects/complexobject.c:476: error: invalid operands to binary == Objects/complexobject.c:476: error: wrong type argument to unary minus gmake: *** [Objects/complexobject.o] Error 1 $ uname -a SunOS hald 5.10 Generic_118822-18 sun4u sparc SUNW,Sun-Fire-15000 ~/src/Python-2.4.2 $ gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-03-29 22:40 Message: Logged In: YES user_id=21627 Can you please try 2.4.3 instead? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460605&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460493 ] Why not drop the _active list?
Bugs item #1460493, was opened at 2006-03-29 09:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: HVB bei TUP (hvb_tup) Assigned to: Nobody/Anonymous (nobody) Summary: Why not drop the _active list? Initial Comment: I am using a modified version of subprocess.py, where I have removed the _active list and all references to it. I have tested it (under Windows 2000) and there were no errors. So what is the reason for managing the _active list at all? Why not drop it? -- >Comment By: Martin v. Löwis (loewis) Date: 2006-03-29 22:41 Message: Logged In: YES user_id=21627 The purpose of the _active list is to wait(2) for open processes. It needs to stay. -- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-29 15:59 Message: Logged In: YES user_id=1488657 I agree. The use of _active makes subprocess.py thread-UNsafe. See also: Bug #1199282 In order to have a thread-safe subprocess.py, I commented out the call to _cleanup() in Popen.__init__(). As a side effect, _active becomes useless. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1442493 ] IDLE shell window gets very slow when displaying long lines
Bugs item #1442493, was opened at 2006-03-03 09:45 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Heiko Selber (drhok) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE shell window gets very slow when displaying long lines Initial Comment: I wrote a little python script that prints a large dictionary to stdout (simply using 'print mydictionary'). In fact, the type is irrelevant, what matters is that the resulting output had approx. 200,000 characters. The shell prints the dictionary into a single line, which causes the window to be almost non-responding, e.g. when I try to scroll the window. Even on a high-end PC it takes a minute or even longer to react to anything. I use Python 2.4.2 on Windows XP SP2. I am aware that it is not exactly wise to print such large objects, but I usually print return values to stdout when I debug a script, and I do not always expect an object to be that large. The average text editor handles such long lines much better. A quick workaround might be to break very long lines automagically (perhaps at around column 1000). PS: I already observed the bug some years ago. I think I even submitted it to python or idlefork a long time ago but I was unable to find it in the buglist. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-03-29 15:52 Message: Logged In: YES user_id=149084 It's not that I don't consider it an issue, but I can't do anything to improve the performance of the Tk text widget. IDLE is pure Python. One thing that comes to mind is to set a maximum line length. If the line exceeds that, print line(:(MAX -100) + '...' + line(:-100) instead of printing the whole thing which no one wants to look at anyway. Another thing I've wanted to do is provide the ability to clear the shell window when it gets too full, w/o restarting IDLE. Yes, you might ask the tkinter guys on their mail list, I'd be interested in hearing their reply. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-03-29 15:35 Message: Logged In: YES user_id=341410 You can close the window which includes the Shell that has the huge output, or even reduce the priority of your Idle shell (you can make it automatic by mucking about with the shortcut; see the 'start' command). -- Comment By: Heiko Selber (drhok) Date: 2006-03-29 15:19 Message: Logged In: YES user_id=865975 Hi kbk, well, my use case is debugging. I write a script and run it with IDLE. It doesn't behave as expected, so I insert a print statement. Next time I run it, IDLE hangs. Oops, it was a long array; it should have been an int. Line too long. Duh. OK, I wait through it, correct the bug, run it again. What happens? IDLE hangs again, trying to scroll a long line (of the previous run). Never mind, I can always kill the process... Dammit, I can't! It eats 100% CPU; task manager doesn't respond. IMHO his takes away one of python's strengths, which is making quick hacks really quick. Would you suggest redirecting this issue to tkinter? You don't seem to consider this an issue at all. I will give squeezer a try. Or maybe PyDev? -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-03-28 18:08 Message: Logged In: YES user_id=149084 This is a known problem with Tk/Tcl/tkinter - large output scrolls slowly. It's not something that can be fixed in IDLE. I tried it on Arch Linux - IDLE 2.5a0 - Tk 8.4. 250,000 character output not too bad , 25 sec, but 10,000 lines of 25 char takes over twice that long, so breaking the lines doesn't help. I don't see any response problem once the output completes. The situation is exponentially worse at 500,000 char. What is your use case? IDLE is designed to be an IDE. Why output such massive data? You may be interested in Squeezer, a Noam Raphael extension to IDLEfork. http://sourceforge.net/tracker/index.php? func=detail&aid=704316&group_id=9579&atid=309579 I haven't tried it myself, but it might be what you're looking for. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-03-10 15:18 Message: Logged In: YES user_id=341410 Generally speaking, most wrapping text controls have issues with wrapping long lines. It would seem reasonable to get the width of the text control in characters, and manually wrap all incoming lines regardles
[ python-Bugs-1460886 ] Broken __hash__ for Unicode objects
Bugs item #1460886, was opened at 2006-03-29 19:16
Message generated for change (Comment added) made by piman
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Broken __hash__ for Unicode objects
Initial Comment:
http://docs.python.org/ref/customization.html says
equal objects should hash to the same value. But this
is not the case when the default Unicode encoding has
been changed (by e.g. importing PyGTK).
Using Python 2.4.2:
>>> import sys
>>> reload(sys)
>>> sys.setdefaultencoding('utf-8')
>>> hash(u"\u1234"), hash(str(u"\u1234"))
(-518661067, -1855038154)
>>> u"\u1234" == str(u"\u1234")
True
--
>Comment By: Joe Wreschnig (piman)
Date: 2006-03-29 22:03
Message:
Logged In: YES
user_id=796
What's the point of having a default encoding if it breaks a
fundamental part of the language on anything but the default
value?
I mean, I can tweak site.py to set it to utf-8; does this
become a valid bug then? site.py even contains a check to
set the encoding to an alternate value if I want.
This may be a "known fact". Every reported bug is a known
fact. That doesn't mean it's not a bug.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-29 19:54
Message:
Logged In: YES
user_id=38388
This is a known fact.
When changing the default encoding, you are basically on
your own, so there's nothing much we can about it.
BTW, the above hack that you're using to get at the
sys.setdefaultencoding() API already indicates that you're
leaving the path of standard Python.
We deliberatly remove that API from the sys module in
site.py to make changing the default encoding an explicit task.
If importing PyGTK has the side-effect of applying such a
hack, then PyGTK is seriously broken and you should report
this to their developers.
Closing as "Invalid".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460886 ] Broken __hash__ for Unicode objects
Bugs item #1460886, was opened at 2006-03-29 21:16
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Broken __hash__ for Unicode objects
Initial Comment:
http://docs.python.org/ref/customization.html says
equal objects should hash to the same value. But this
is not the case when the default Unicode encoding has
been changed (by e.g. importing PyGTK).
Using Python 2.4.2:
>>> import sys
>>> reload(sys)
>>> sys.setdefaultencoding('utf-8')
>>> hash(u"\u1234"), hash(str(u"\u1234"))
(-518661067, -1855038154)
>>> u"\u1234" == str(u"\u1234")
True
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-30 00:36
Message:
Logged In: YES
user_id=38388
You can tweak the default encoding setting in site.py, but
again, you're on your own when doing so.
I also wonder why you would expect str(u"\u1234") (==
'\xe1\x88\xb4' with your setting) to have the same hash
value as a single Unicode code point.
Note that hash values are cached inside the Unicode object.
If we were to let the hash value depend on the current
setting of the default encoding, it would be possible to
have two equal Unicode objects with two different hash values.
It's one of the few places that actually does hard code the
ASCII default encoding. Most others will work with other
encodings as well, but again: no guarantees. Note that
because of this, you don't get a differen hash value for
ASCII Unicode code points and ASCII-compatible default
encodings.
In future versions, the default encoding will go away, so
please don't start relying on it.
--
Comment By: Joe Wreschnig (piman)
Date: 2006-03-30 00:03
Message:
Logged In: YES
user_id=796
What's the point of having a default encoding if it breaks a
fundamental part of the language on anything but the default
value?
I mean, I can tweak site.py to set it to utf-8; does this
become a valid bug then? site.py even contains a check to
set the encoding to an alternate value if I want.
This may be a "known fact". Every reported bug is a known
fact. That doesn't mean it's not a bug.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-03-29 21:54
Message:
Logged In: YES
user_id=38388
This is a known fact.
When changing the default encoding, you are basically on
your own, so there's nothing much we can about it.
BTW, the above hack that you're using to get at the
sys.setdefaultencoding() API already indicates that you're
leaving the path of standard Python.
We deliberatly remove that API from the sys module in
site.py to make changing the default encoding an explicit task.
If importing PyGTK has the side-effect of applying such a
hack, then PyGTK is seriously broken and you should report
this to their developers.
Closing as "Invalid".
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460886&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1461115 ] test_winsound fails in 2.4.3
Bugs item #1461115, was opened at 2006-03-30 00:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461115&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Martin v. Löwis (loewis) Summary: test_winsound fails in 2.4.3 Initial Comment: The released 2.4.3 Windows installer doesn't include source file Lib/test/check_soundcard.vbs, which causes test_winsound to report 7 bogus failures when run on a box with a sound card. I expect the 2.5 installer also needs to be fiddled to include this file. I confirmed that the problem went away after copying check_soundcard.vbs from a 2.4 branch checkout into the 2.4.3 installation tree. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1461115&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460493 ] Why not drop the _active list?
Bugs item #1460493, was opened at 2006-03-28 23:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: HVB bei TUP (hvb_tup) Assigned to: Nobody/Anonymous (nobody) Summary: Why not drop the _active list? Initial Comment: I am using a modified version of subprocess.py, where I have removed the _active list and all references to it. I have tested it (under Windows 2000) and there were no errors. So what is the reason for managing the _active list at all? Why not drop it? -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-29 23:43 Message: Logged In: YES user_id=33168 If you always called wait() the _active list isn't beneficial to you. However, many people do not call wait and the _active list provides a mechanism to cleanup zombied children. This is important for many users. If you need thread safely, you can handle the locking yourself before calling poll()/wait(). -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-29 12:41 Message: Logged In: YES user_id=21627 The purpose of the _active list is to wait(2) for open processes. It needs to stay. -- Comment By: Tristan Faujour (tfaujour) Date: 2006-03-29 05:59 Message: Logged In: YES user_id=1488657 I agree. The use of _active makes subprocess.py thread-UNsafe. See also: Bug #1199282 In order to have a thread-safe subprocess.py, I commented out the call to _cleanup() in Popen.__init__(). As a side effect, _active becomes useless. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-826756 ] email/Generator.py: Incorrect header output
Bugs item #826756, was opened at 2003-10-20 20:23 Message generated for change (Comment added) made by bbaetz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=826756&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Matthias Pronk (mjepronk) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email/Generator.py: Incorrect header output Initial Comment: I've found a small bug when using the email/Parser.py classes. When there is a long "Subject" header, it will be wrapped to multiple lines, which are preceded by a tab. This is undesired behaviour, because e-mail clients show this tab in the subject. Especially, Mozilla for Windows shows a strange square symbol. The following code in email/Generator.py (line 180) resolves the problem: else: # Header's got lots of smarts, so use it. if h.lower() == 'subject': cont_ws = ' ' else: cont_ws = '\t' print >> self._fp, Header( v, maxlinelen=self.__maxheaderlen, header_name=h, continuation_ws=cont_ws).encode() For more information you can e-mail me: matthias -at- rubberbiscuit.nl -- Comment By: Bradley Baetz (bbaetz) Date: 2006-03-30 18:52 Message: Logged In: YES user_id=495627 I disagree that this follows RFC2822. The RFC says: The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation. This means that if python takes a header: Subject: This is a long string and wraps it to: Subject: This is a\r\n\tlong string then when the MUA "simply remov[es] any CRLF" the whitespace, and we end up with: Subject: This is a\tlong string with a tab rather than a space, which doesn't look too good. Some MUAs condense any following WSP into a single space, but thats technically breaking the RFC. (This affects mailman - http://mail.python.org/pipermail/mailman-developers/2005-December/018410.html) -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-22 05:38 Message: Logged In: YES user_id=12800 RFC 2822 specifies when and how long headers are supposed to be wrapped, and the default Generator behavior is to be compliant with this standard. I consider it a bug in your mail reader that such long headers are displayed incorrectly (other mail readers display long wrapped headers correctly). Having said this, you have options. You can disable wrapping altogether by passing maxheaderlen=0 to the Generator constructor, or you can create a Generator subclass which overrides the _write_headers() method and passes a different value for continuation_ws. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=826756&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
