[ python-Bugs-1431253 ] Logging hangs thread after detaching a StreamHandler's termi
Bugs item #1431253, was opened at 2006-02-13 22:07
Message generated for change (Comment added) made by yangzhang
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431253&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: Pending
Resolution: Works For Me
Priority: 5
Submitted By: Yang Zhang (yangzhang)
Assigned to: Vinay Sajip (vsajip)
Summary: Logging hangs thread after detaching a StreamHandler's termi
Initial Comment:
Hi all,
After many hours, I think I've found a bug in the
logging module!
If you add a (stdout) StreamHandler to a logger, then
detach the terminal for that stdout, subsequent calls
to log() will hang the calling thread.
To reproduce this, write the following scripts (this
was a small test case I came up with - maybe there's
something simpler):
$ cat tryhup.bash
#!/usr/bin/env bash
scp hup.* localhost:
ssh localhost './hup.bash ; while true ; do sleep 1 ;
done'
$ cat hup.bash
#!/usr/bin/env bash
./hup.py &
$ cat hup.py
#!/usr/bin/env python
import time
import logging
f = file( '/tmp/hup.out', 'w' )
try:
logging.basicConfig( filename = '/tmp/lup.out',
filemode = 'w' )
# XXX PROBLEM LINE BELOW
logging.getLogger('').addHandler( logging.
StreamHandler() )
while True:
f.write( '---\n' )
f.flush()
logging.critical( '==' )
time.sleep(1)
finally:
f.close()
Run ./tryhup.bash. It will sit in an idle spin. Monitor
the files /tmp/hup.out and /tmp/lup.out. Hit Ctrl-C on
tryhup to kill it. The python process is still running,
but is stalled (the .out files are no longer changing).
If you remove the above labeled line, however, this
doesn't happen.
Can anybody please acknowledge this bug? Any temporary
workarounds to this problem? Thanks in advance for
looking into this and for hearing me in!
--
>Comment By: Yang Zhang (yangzhang)
Date: 2006-02-16 23:17
Message:
Logged In: YES
user_id=1207658
Hi, yes, after I submitted this bug I actually looked into
logging.StreamHandler, and found that its code was not too
complicated (as with everything Python :).
I tried some more experiments, and found that the problem is
in stderr, which throws an exception. The problem was that I
couldn't see the exception (and didn't suspect that's what
was happening), so the fact that the next line never came
out led me to believe that the thread froze.
Is stderr supposed to raise an exception like this? Is this
a bug?
Unfortunately, it's hard for me to tell what's going on
(what the exception is that's being thrown). How do I tell
what it's raising? (stderr is no longer avail. after all) I
don't know how to catch an exception of any type and (say)
print its str or repr value to a file so that I can tell
what's going on.
--
Comment By: Yang Zhang (yangzhang)
Date: 2006-02-16 23:16
Message:
Logged In: YES
user_id=1207658
Hi, yes, after I submitted this bug I actually looked into
logging.StreamHandler, and found that its code was not too
complicated (as with everything Python :).
I tried some more experiments, and found that the problem is
in stderr, which throws an exception. The problem was that I
couldn't see the exception (and didn't suspect that's what
was happening), so the fact that the next line never came
out led me to believe that the thread froze.
Is stderr supposed to raise an exception like this? Is this
a bug?
Unfortunately, it's hard for me to tell what's going on
(what the exception is that's being thrown). How do I tell
what it's raising? (stderr is no longer avail. after all) I
don't know how to catch an exception of any type and (say)
print its str or repr value to a file so that I can tell
what's going on.
--
Comment By: Vinay Sajip (vsajip)
Date: 2006-02-16 17:04
Message:
Logged In: YES
user_id=308438
Please provide more information about your OS - I ran these
scripts on Ubuntu 5.10 and did not see the problems you
mention. The script continues to run (printing dashes to the
console), and hup.out/lup.out are also updated continuously.
Also, note that the logging module merely opens the stream
passed to the StreamHander for output, so check if in
your configuration you get a hang just doing a write to
sys.stderr.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431253&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailm
[ python-Feature Requests-1433435 ] Use new expat version 2.0
Feature Requests item #1433435, was opened at 2006-02-17 10:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1433435&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: XML Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wolfgang Langner (tds33) Assigned to: Nobody/Anonymous (nobody) Summary: Use new expat version 2.0 Initial Comment: New expat version 2.0 is released. This one schould be used in the next python release (2.5). I checked the repository and feature request and there is no note about usage of new expat versions. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1433435&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1432260 ] pydoc still doesn't handle lambda well
Bugs item #1432260, was opened at 2006-02-15 17:03 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432260&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: Closed >Resolution: Fixed Priority: 5 Submitted By: William McVey (wamcvey) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc still doesn't handle lambda well Initial Comment: This is a duplicate of Bug ID 672578, but I could find no way for a 'normal user' to reopen a closed bug ticket. Pydoc doesn't currently handle functions and methods defined with lambda very well. Not only are names associated with a lambda defined function/method not indicated in the generated module and class definitions, but docstrings attached to the object generated by lambda are not integrated into the output. I've attached a sample program that illustrates the discrepency of handling methods defined with 'def' versus those that are handled with 'lambda'. -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-02-17 10:48 Message: Logged In: YES user_id=1188172 Thanks, I fixed this to look as in the HTML doc. Revisions 42439, 42440. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432260&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1431253 ] Logging hangs thread after detaching a StreamHandler's termi
Bugs item #1431253, was opened at 2006-02-14 06:07
Message generated for change (Settings changed) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431253&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: Pending
>Resolution: Works For Me
Priority: 5
Submitted By: Yang Zhang (yangzhang)
Assigned to: Vinay Sajip (vsajip)
Summary: Logging hangs thread after detaching a StreamHandler's termi
Initial Comment:
Hi all,
After many hours, I think I've found a bug in the
logging module!
If you add a (stdout) StreamHandler to a logger, then
detach the terminal for that stdout, subsequent calls
to log() will hang the calling thread.
To reproduce this, write the following scripts (this
was a small test case I came up with - maybe there's
something simpler):
$ cat tryhup.bash
#!/usr/bin/env bash
scp hup.* localhost:
ssh localhost './hup.bash ; while true ; do sleep 1 ;
done'
$ cat hup.bash
#!/usr/bin/env bash
./hup.py &
$ cat hup.py
#!/usr/bin/env python
import time
import logging
f = file( '/tmp/hup.out', 'w' )
try:
logging.basicConfig( filename = '/tmp/lup.out',
filemode = 'w' )
# XXX PROBLEM LINE BELOW
logging.getLogger('').addHandler( logging.
StreamHandler() )
while True:
f.write( '---\n' )
f.flush()
logging.critical( '==' )
time.sleep(1)
finally:
f.close()
Run ./tryhup.bash. It will sit in an idle spin. Monitor
the files /tmp/hup.out and /tmp/lup.out. Hit Ctrl-C on
tryhup to kill it. The python process is still running,
but is stalled (the .out files are no longer changing).
If you remove the above labeled line, however, this
doesn't happen.
Can anybody please acknowledge this bug? Any temporary
workarounds to this problem? Thanks in advance for
looking into this and for hearing me in!
--
>Comment By: Vinay Sajip (vsajip)
Date: 2006-02-17 01:04
Message:
Logged In: YES
user_id=308438
Please provide more information about your OS - I ran these
scripts on Ubuntu 5.10 and did not see the problems you
mention. The script continues to run (printing dashes to the
console), and hup.out/lup.out are also updated continuously.
Also, note that the logging module merely opens the stream
passed to the StreamHander for output, so check if in
your configuration you get a hang just doing a write to
sys.stderr.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431253&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1432694 ] Implement preemptive threads in Python
Feature Requests item #1432694, was opened at 2006-02-16 10:11
Message generated for change (Comment added) made by darkprokoba
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&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: Threads
Group: None
>Status: Pending
Resolution: Invalid
Priority: 5
Submitted By: Andrey Petrov (darkprokoba)
Assigned to: Michael Hudson (mwh)
Summary: Implement preemptive threads in Python
Initial Comment:
Cooperative threads have their uses but I find the lack
of real native pre-emptive threads a major issue in a
21-st century language.
We should consider the inertia of programmers from
C++/Java/.NET background. They are used to and
experienced in solving certain kind of problems with
pre-emptive threads, and it's just too plain
inconvenient to step back and try to cope with
cooperative threads.
The idea behind Python is that programming should not
be a pain, right?
This applies especially to GUI programs, where threads
are used to perform time-consuming work in order to
avoid the GUI from freezing (was I surprised the first
time I tried this in Python!)
Just look at some of the modern Python GUI
applications, found in some recent Linux distributions.
99% of Fedora's configuration tools suffer extreme
usability issues caused by their single-threadedness. I
hate using yumex because the GUI is basically frozen
for the half minute it takes to reload all repos I have
configured on my machine!!! I know there might be a way
to alleviate this particual class of problems by more
careful cooperative thread programing... but I believe
we need a more straightforward solution (i.e.
preemptive threads) and not workarounds.
I apologize if this issue has already been raised before.
Cheers,
darkprokoba
--
>Comment By: Andrey Petrov (darkprokoba)
Date: 2006-02-17 11:52
Message:
Logged In: YES
user_id=950037
OK, let me try again :-)
The problem is in the global interpreter lock:
http://docs.python.org/api/threads.html
this basically says that you can have as many native threads
as you like but only one of them could have the global
interpreter lock and could therefore be executing python
code at a time. The only use of python's multiple threads
then is so they could release the global lock and block on
i/o operations while one lucky thread has the lock and
executes python code and accesses python objects happily.
So we have multiple native threads (e.g. pthreads) but they
pass arround the global lock in a cooperative manner. This
is not preemptive threading imho.
It's a severely limited model and has the following
potential problem: a thread may enter a time-consuming i/o
operation but forget to release the global interpreter lock
- leading to a freeze in the entire interpreter (all threads
are waiting for the global lock, while the thread that has
it waits on the i/o operation)
Are there any plans for alleviating this problem? A thread
should not voluntarily release the lock so that the rest of
the threads get a chance to execute python code. It should
be possible to preempt any thread at any time without its
consent in order to have a true preemptive threading model.
Or please correct me If I'm wrong.
--
Comment By: Michael Hudson (mwh)
Date: 2006-02-16 16:14
Message:
Logged In: YES
user_id=6656
We _have_ preemptive threads in Python ("import threading"). Suggest you
report a real problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1430298 ] smtplib: empty mail addresses
Bugs item #1430298, was opened at 2006-02-12 22:36 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430298&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: Freek Dijkstra (macfreek) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib: empty mail addresses Initial Comment: It is not possible to send an email with smtplib with an empty return address. if you leave the sender mail address empty, smtplib will use "" as sender, instead of "<>", as it should do. Note that an empty return address is typically used for mail delivery warnings (it has a valid usage!) This bug is still in current SVN (I just checked http://svn.python.org/ projects/python/trunk/Lib/smtplib.py). Below is a fix for smtplib.py that came with Python 2.3 (since I still use that version). The bug is in the function "quoteaddr(addr):" *** orig/smtplib.py 2005-05-14 23:48:03.0 +0200 --- smtplib.py 2006-02-08 09:52:25.0 +0100 *** *** 176,181 --- 176,183 if m == (None, None): # Indicates parse failure or AttributeError #something weird here.. punt -ddm return "<%s>" % addr + elif m == None: + return "<>" else: return "<%s>" % m -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-02-17 10:53 Message: Logged In: YES user_id=1188172 Thanks for the report, I applied your patch in rev. 42442, 42443 (2.4). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430298&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1432694 ] Implement preemptive threads in Python
Feature Requests item #1432694, was opened at 2006-02-16 10:11
Message generated for change (Settings changed) made by darkprokoba
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&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: Threads
Group: None
>Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Andrey Petrov (darkprokoba)
Assigned to: Michael Hudson (mwh)
Summary: Implement preemptive threads in Python
Initial Comment:
Cooperative threads have their uses but I find the lack
of real native pre-emptive threads a major issue in a
21-st century language.
We should consider the inertia of programmers from
C++/Java/.NET background. They are used to and
experienced in solving certain kind of problems with
pre-emptive threads, and it's just too plain
inconvenient to step back and try to cope with
cooperative threads.
The idea behind Python is that programming should not
be a pain, right?
This applies especially to GUI programs, where threads
are used to perform time-consuming work in order to
avoid the GUI from freezing (was I surprised the first
time I tried this in Python!)
Just look at some of the modern Python GUI
applications, found in some recent Linux distributions.
99% of Fedora's configuration tools suffer extreme
usability issues caused by their single-threadedness. I
hate using yumex because the GUI is basically frozen
for the half minute it takes to reload all repos I have
configured on my machine!!! I know there might be a way
to alleviate this particual class of problems by more
careful cooperative thread programing... but I believe
we need a more straightforward solution (i.e.
preemptive threads) and not workarounds.
I apologize if this issue has already been raised before.
Cheers,
darkprokoba
--
Comment By: Andrey Petrov (darkprokoba)
Date: 2006-02-17 11:52
Message:
Logged In: YES
user_id=950037
OK, let me try again :-)
The problem is in the global interpreter lock:
http://docs.python.org/api/threads.html
this basically says that you can have as many native threads
as you like but only one of them could have the global
interpreter lock and could therefore be executing python
code at a time. The only use of python's multiple threads
then is so they could release the global lock and block on
i/o operations while one lucky thread has the lock and
executes python code and accesses python objects happily.
So we have multiple native threads (e.g. pthreads) but they
pass arround the global lock in a cooperative manner. This
is not preemptive threading imho.
It's a severely limited model and has the following
potential problem: a thread may enter a time-consuming i/o
operation but forget to release the global interpreter lock
- leading to a freeze in the entire interpreter (all threads
are waiting for the global lock, while the thread that has
it waits on the i/o operation)
Are there any plans for alleviating this problem? A thread
should not voluntarily release the lock so that the rest of
the threads get a chance to execute python code. It should
be possible to preempt any thread at any time without its
consent in order to have a true preemptive threading model.
Or please correct me If I'm wrong.
--
Comment By: Michael Hudson (mwh)
Date: 2006-02-16 16:14
Message:
Logged In: YES
user_id=6656
We _have_ preemptive threads in Python ("import threading"). Suggest you
report a real problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432694&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1431253 ] Logging hangs thread after detaching a StreamHandler's termi
Bugs item #1431253, was opened at 2006-02-13 22:07
Message generated for change (Comment added) made by yangzhang
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431253&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: Works For Me
Priority: 5
Submitted By: Yang Zhang (yangzhang)
Assigned to: Vinay Sajip (vsajip)
Summary: Logging hangs thread after detaching a StreamHandler's termi
Initial Comment:
Hi all,
After many hours, I think I've found a bug in the
logging module!
If you add a (stdout) StreamHandler to a logger, then
detach the terminal for that stdout, subsequent calls
to log() will hang the calling thread.
To reproduce this, write the following scripts (this
was a small test case I came up with - maybe there's
something simpler):
$ cat tryhup.bash
#!/usr/bin/env bash
scp hup.* localhost:
ssh localhost './hup.bash ; while true ; do sleep 1 ;
done'
$ cat hup.bash
#!/usr/bin/env bash
./hup.py &
$ cat hup.py
#!/usr/bin/env python
import time
import logging
f = file( '/tmp/hup.out', 'w' )
try:
logging.basicConfig( filename = '/tmp/lup.out',
filemode = 'w' )
# XXX PROBLEM LINE BELOW
logging.getLogger('').addHandler( logging.
StreamHandler() )
while True:
f.write( '---\n' )
f.flush()
logging.critical( '==' )
time.sleep(1)
finally:
f.close()
Run ./tryhup.bash. It will sit in an idle spin. Monitor
the files /tmp/hup.out and /tmp/lup.out. Hit Ctrl-C on
tryhup to kill it. The python process is still running,
but is stalled (the .out files are no longer changing).
If you remove the above labeled line, however, this
doesn't happen.
Can anybody please acknowledge this bug? Any temporary
workarounds to this problem? Thanks in advance for
looking into this and for hearing me in!
--
>Comment By: Yang Zhang (yangzhang)
Date: 2006-02-16 23:16
Message:
Logged In: YES
user_id=1207658
Hi, yes, after I submitted this bug I actually looked into
logging.StreamHandler, and found that its code was not too
complicated (as with everything Python :).
I tried some more experiments, and found that the problem is
in stderr, which throws an exception. The problem was that I
couldn't see the exception (and didn't suspect that's what
was happening), so the fact that the next line never came
out led me to believe that the thread froze.
Is stderr supposed to raise an exception like this? Is this
a bug?
Unfortunately, it's hard for me to tell what's going on
(what the exception is that's being thrown). How do I tell
what it's raising? (stderr is no longer avail. after all) I
don't know how to catch an exception of any type and (say)
print its str or repr value to a file so that I can tell
what's going on.
--
Comment By: Vinay Sajip (vsajip)
Date: 2006-02-16 17:04
Message:
Logged In: YES
user_id=308438
Please provide more information about your OS - I ran these
scripts on Ubuntu 5.10 and did not see the problems you
mention. The script continues to run (printing dashes to the
console), and hup.out/lup.out are also updated continuously.
Also, note that the logging module merely opens the stream
passed to the StreamHander for output, so check if in
your configuration you get a hang just doing a write to
sys.stderr.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431253&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1284928 ] logging module's setLoggerClass not really working
Bugs item #1284928, was opened at 2005-09-08 13:51 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Rotem Yaari (rotem_ya) Assigned to: Nobody/Anonymous (nobody) Summary: logging module's setLoggerClass not really working Initial Comment: The logging package should be modified in a way which would let users call the setLoggerClass API, and then consistently get loggers only from that class. In the logging package as it is today, the root logger will always be a logging.Logger instance, and not the new class specified in the call to setLoggerClass. These semantics are not clear. -- >Comment By: Vinay Sajip (vsajip) Date: 2006-02-17 01:06 Message: Logged In: YES user_id=308438 Recent checkins to CVS cater for adding user-defined attributes to a LogRecord, and the function name is also available in the LogRecord. -- Comment By: Rotem Yaari (rotem_ya) Date: 2005-09-19 13:15 Message: Logged In: YES user_id=1340892 That sounds fine. The only thing I think is important is that it'll be possible to add fields to the LogRecord in the period of time between its creation and its "emitting". That will let users add any behavior desired to the logging mechanism. In addition, since setLoggerClass is obviously not intended for users, it should be prefixed with an underscore or made "pseudo private"... its otherwise confusing. -- Comment By: Vinay Sajip (vsajip) Date: 2005-09-19 12:31 Message: Logged In: YES user_id=308438 OK - I'm part way through implementing a change whereby the function name is available through the base logging functionality - the findCaller() implementation in CVS currently gets the function name, but I have not yet implemented the part which puts it into the LogRecord. So this particular patch of yours will soon not be necessary. Also note that you can also redefine the record-making function - but I am currently thinking of how to make this part of the system better, as it is a little untidy at the moment. The objective is to make it easy to add whatever you want to the LogRecord __dict__ which can later be used in the formatted output. -- Comment By: Rotem Yaari (rotem_ya) Date: 2005-09-19 06:34 Message: Logged In: YES user_id=1340892 This is an example logger class I would like to use: class PatchedLogger(logging.Logger): def __init__(self, name, *patches): logging.Logger.__init__(self, name) self.patches = patches def handle(self, record): #copied from the actual Logger implementation if (not self.disabled) and self.filter(record): for patch in self.patches: patch(record) self.callHandlers(record) And an example "patch": def EnableTrace(record): """ adds the %(function)s for logging records """ function_name = _get_function_name(inspect.stack()[4]) record.function = function_name -- Comment By: Vinay Sajip (vsajip) Date: 2005-09-19 01:00 Message: Logged In: YES user_id=308438 Can you please explain your use case? Why does the package have to be modified in that way? Why do you need to be able to have the root logger be creatable from a custom class? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-882297 ] socket's makefile file object doesn't work with timeouts.
Bugs item #882297, was opened at 2004-01-22 19:36
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&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: Jeremy Fincher (jemfinch)
>Assigned to: Skip Montanaro (montanaro)
Summary: socket's makefile file object doesn't work with timeouts.
Initial Comment:
Ok, here's what I did:
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.bind(('', 9009))
>>> s.listen(5)
>>> s.accept()
Now, I opened a second Python interpreter in which I
typed this:
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.connect(('localhost', 9009))
In the first interpreter I did this:
>>> s.accept()
(,
('127.0.0.1', 33059))
>>> s1 = _[0]
>>> s1.settimeout(3)
>>> fd = s1.makefile()
Then I tested that the timeout worked correctly. Still
in the first interpreter:
>>> fd.readline()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()
Now, while that was blocking, I did this in the second
interpreter:
>>> s.send('foo')
3
Which caused this in the first interpreter (as
expected, since I didn't send a newline):
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()
While that was blocking, I did this in the second
interpreter:
>>> s.send('bar\n')
4
Finally sending a newline. But lo and behold! In the
first interpreter I got this:
>>> fd.readline()
'bar\n'
Alas, my 'foo' has been lost!
Anyway, the documentation does explicitly state that
the socket should be in blocking mode, *implying* that
it does no buffering, but it doesn't say anything about
timeouts. Ideally, the file object would buffer enough
data until the readline could return meaningfully, but
failing that, the documentation should probably be
updated to mention that timeouts shouldn't be used with
readline on the returned file object.
--
>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 13:10
Message:
Logged In: YES
user_id=1188172
If this is a bug, it hasn't been fixed. I reproduced it here.
Assigning to Skip since he worked on "makefile" as it seems.
--
Comment By: John J Lee (jjlee)
Date: 2006-02-01 20:38
Message:
Logged In: YES
user_id=261020
I believe this was fixed in socket.py in rev 32056, closing
bug 707074.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-882297 ] socket's makefile file object doesn't work with timeouts.
Bugs item #882297, was opened at 2004-01-22 19:36
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&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: Jeremy Fincher (jemfinch)
Assigned to: Skip Montanaro (montanaro)
Summary: socket's makefile file object doesn't work with timeouts.
Initial Comment:
Ok, here's what I did:
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.bind(('', 9009))
>>> s.listen(5)
>>> s.accept()
Now, I opened a second Python interpreter in which I
typed this:
>>> import socket
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.connect(('localhost', 9009))
In the first interpreter I did this:
>>> s.accept()
(,
('127.0.0.1', 33059))
>>> s1 = _[0]
>>> s1.settimeout(3)
>>> fd = s1.makefile()
Then I tested that the timeout worked correctly. Still
in the first interpreter:
>>> fd.readline()
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()
Now, while that was blocking, I did this in the second
interpreter:
>>> s.send('foo')
3
Which caused this in the first interpreter (as
expected, since I didn't send a newline):
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.3/socket.py", line 338,
in readline
data = self._sock.recv(self._rbufsize)
socket.timeout: timed out
>>> fd.readline()
While that was blocking, I did this in the second
interpreter:
>>> s.send('bar\n')
4
Finally sending a newline. But lo and behold! In the
first interpreter I got this:
>>> fd.readline()
'bar\n'
Alas, my 'foo' has been lost!
Anyway, the documentation does explicitly state that
the socket should be in blocking mode, *implying* that
it does no buffering, but it doesn't say anything about
timeouts. Ideally, the file object would buffer enough
data until the readline could return meaningfully, but
failing that, the documentation should probably be
updated to mention that timeouts shouldn't be used with
readline on the returned file object.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 13:10
Message:
Logged In: YES
user_id=1188172
If this is a bug, it hasn't been fixed. I reproduced it here.
Assigning to Skip since he worked on "makefile" as it seems.
--
Comment By: John J Lee (jjlee)
Date: 2006-02-01 20:38
Message:
Logged In: YES
user_id=261020
I believe this was fixed in socket.py in rev 32056, closing
bug 707074.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882297&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1421513 ] IMPORT PROBLEM: Local submodule shadows global module
Bugs item #1421513, was opened at 2006-02-01 15:48 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421513&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: None >Status: Closed >Resolution: Postponed Priority: 5 Submitted By: Jens Engel (jens_engel) Assigned to: Nobody/Anonymous (nobody) Summary: IMPORT PROBLEM: Local submodule shadows global module Initial Comment: PYTHON: 2.3, 2.4 PLATFORMS: Solaris, Linux, Cygwin, Win32 Local sister modules seem to hide global ones (of the standard Python library) when import occurs in a submodule. This statement even holds for indirect imports from the standard Python library. FILE STRUCTURE for EXAMPLES: - my/ +-- __init__.py +-- main.py +-- main2.py +-- symbol.py \-- types.py EXAMPLE 1: Local submodule shadows global one. # -- file:my.main.py # COMMAND-LINE: python my/main.py # MY INTENTION: Import standard module "types". import types #< FAILURE: Imports my.types if __name__ == "__main__": print types.StringTypes #< EXCEPTION: StringTypes are not known. # -- FILE-END EXAMPLE 2: Indirect import uses "my.symbol" instead. # -- file:my.main2.py # COMMAND-LINE: python my/main2.py # MY INTENTION: Import standard module "compiler". # NOTE: Module "compiler" imports module "symbol" import compiler #< FAILURE: Imports my.symbol instead if __name__ == "__main__": pass # -- FILE-END NOTE: Module import problems can be better checked with "python -v". I have not found a work-around that let me decide if I want to import the global module or the local one. The only solution seens to be to relocate the module where "__main__" is used to another place where no such import conflict occurs. If my analysis is correct, the "main" module provides another ROOT filesystem for Python libraries that is normally preferred over the PYTHONHOME filesystem. If this is true, module names at this level must be UNIQUE in a GLOBAL namespace (that is only partly under my control) which I consider BAD. NOTE: In C++ if have the "::" prefix to indicate that I want to use the global/default namespace (=module) and not a sub-namespace. I am not aware of such a idom in Python. -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-02-17 13:13 Message: Logged In: YES user_id=1188172 This is, unfortunately, correct behavior. Python 2.5 will hopefully fix this with new import semantics for relative imports. As a workaround, don't call your modules like global ones when you need those. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1419989 ] class dictionary shortcircuits __getattr__
Bugs item #1419989, was opened at 2006-01-31 08:08 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1419989&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: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Shaun Cutts (shauncutts) Assigned to: Nobody/Anonymous (nobody) Summary: class dictionary shortcircuits __getattr__ Initial Comment: page 3.3.2 of Language Reference states: "Note that at least for instance variables, you can fake total control by not inserting any values in the instance attribute dictionary (but instead inserting them in another object)." A counterexample (doctest style): - >>> class Foo: ... bar = None ... def __getattr__( self, attr ): ... return 'boo' ... >>> f = Foo() >>> print "bar: ",f.bar bar: None -- 'bar' in class dictionary (not just in instance dictionary) also causes __getattr__ not to be called. BTW.. above in the doc, it says that __getattr__ called only if "normal methods" can't find attribute. So this would seem a documentation bug. However, right now at least, I would prefer if the instance dictionary alone were decisive. -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-02-17 13:16 Message: Logged In: YES user_id=1188172 This is correct behavior as documented. The first sentence in the cited page is: """ [__getattr__ is] Called when an attribute lookup has not found the attribute in the usual places (i.e. it is not an instance attribute nor is it found in the class tree for self).""" """Note that **at least** for instance variables,""" explicitly tells you that you can't do anything about class variables. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1419989&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1417699 ] float/atof have become locale aware
Bugs item #1417699, was opened at 2006-01-29 02:04
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: Bernhard Herzog (bernhard)
>Assigned to: Martin v. Löwis (loewis)
Summary: float/atof have become locale aware
Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:
Python 2.4.2 (#1, Nov 29 2005, 16:07:55)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5
This doesn't match what's specified in pep 331:
- float() and str() stay locale-unaware.
It also doesn't match the documentation for atof:
Convert a string to a floating point number.
The string must have the standard syntax for a
floating point literal in Python, optionally
preceded by a sign ("+" or "-"). Note that this
behaves identical to the built-in function float()
when passed a string.
The documentation for float() doesn't state which
format is accepted by float(), though.
The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:
This function behaves like the standard strtod()
function does in the C locale.
--
>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 13:19
Message:
Logged In: YES
user_id=1188172
Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1417554 ] SimpleHTTPServer doesn't return last-modified headers
Bugs item #1417554, was opened at 2006-01-28 20:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417554&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Aaron Swartz (aaronsw) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer doesn't return last-modified headers Initial Comment: SimpleHTTPServer doesn't return any Last-Modified headers with its responses, which means browsers can't cache them, which means if you try and view pages with images and things it has to reload all of them every time. -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-02-17 14:36 Message: Logged In: YES user_id=1188172 Committed a patch in rev. 42450. -- Comment By: Aaron Swartz (aaronsw) Date: 2006-01-28 20:25 Message: Logged In: YES user_id=122141 Here's a patch: http://sourceforge.net/tracker/index.php? func=detail&aid=1417555&group_id=5470&atid=305470 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417554&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1433667 ] os.path.expandvars sometimes doesn't expand $HOSTNAME
Bugs item #1433667, was opened at 2006-02-17 11:03
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=1433667&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: Doug Fort (dougfort)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.expandvars sometimes doesn't expand $HOSTNAME
Initial Comment:
$ echo "$HOSTNAME"
c0a80165.tipt.aol.com
$ /usr/local/bin/python
Python 2.4.2 (#1, Dec 30 2005, 11:14:42)
[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/Users/dougfort'
>>> os.path.expandvars("$HOSTNAME")
'$HOSTNAME'
>>>
arthurformat-d09:arthur$ echo $HOSTNAME
arthurformat-d09.ats.aol.com
arthurformat-d09:arthur$ /cm/tools/bin/python
Python 2.3.4 (#1, Jul 28 2004, 14:55:53)
[GCC 3.3.1] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/opt/aol/production/arthur'
>>> os.path.expandvars("$HOSTNAME")
'arthurformat-d09.ats.aol.com'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433667&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1433694 ] normalize function in minidom unlinks empty child nodes
Bugs item #1433694, was opened at 2006-02-17 11:52 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=1433694&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: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: RomanKliotzkin (romankliotzkin) Assigned to: Nobody/Anonymous (nobody) Summary: normalize function in minidom unlinks empty child nodes Initial Comment: Hi, When calling the "normalize" method of DOM objects in the minidom library, the method will attempt to collate text nodes together. When it encounters an empty text node, it will do the following: (line 197 in minidom.py) else: # empty text node; discard child.unlink() unlink() sets all the members of the child node to None, BUT the parent node still has a link to the child node. Therefore, if one is later iterating through the parent node and calls removeChild on the unlinked node, a NotFoundErr exception will be thrown by the library. To trigger, use the test case script along with the test case XML document included in the zip file. testcase.py testcase.xml My suggestion is to call self.removeChild(child), then call child.unlink(). That way, there is no ambiguity about an unlinked child being referenced by the parent. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433694&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1433667 ] os.path.expandvars sometimes doesn't expand $HOSTNAME
Bugs item #1433667, was opened at 2006-02-17 17:03
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433667&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: Doug Fort (dougfort)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.expandvars sometimes doesn't expand $HOSTNAME
Initial Comment:
$ echo "$HOSTNAME"
c0a80165.tipt.aol.com
$ /usr/local/bin/python
Python 2.4.2 (#1, Dec 30 2005, 11:14:42)
[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/Users/dougfort'
>>> os.path.expandvars("$HOSTNAME")
'$HOSTNAME'
>>>
arthurformat-d09:arthur$ echo $HOSTNAME
arthurformat-d09.ats.aol.com
arthurformat-d09:arthur$ /cm/tools/bin/python
Python 2.3.4 (#1, Jul 28 2004, 14:55:53)
[GCC 3.3.1] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/opt/aol/production/arthur'
>>> os.path.expandvars("$HOSTNAME")
'arthurformat-d09.ats.aol.com'
--
>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 19:13
Message:
Logged In: YES
user_id=1188172
It might be good if you explain what the differences between
the two snippets are, environment-wise.
The first question that comes to mind is: is $HOSTNAME
exported in the first shell?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433667&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1419652 ] PyImport_AppendInittab stores pointer to parameter
Bugs item #1419652, was opened at 2006-01-31 04:19 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1419652&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: coder_5 (coder_5) >Assigned to: Martin v. Löwis (loewis) Summary: PyImport_AppendInittab stores pointer to parameter Initial Comment: signature is: int PyImport_AppendInittab(char *name, void (*initfunc)(void)) if the 'name' pointer is freed or overwritten directly after the call to PyImport_AppendInittab, this call returns true but fails making the module known, and the interpreter crashes on PyFinalize(); this suggests that PyImport_AppendInittab stores the name pointer and uses it later, after leaving this function. this is undocumented and leads to crashes if name is freed in the meantime. (a typical c problem) this function is important to boost::python library to extend python with c++. workaround for c/c++ users: -malloc a char* for the name, -copy the modulename to name -call PyImport_AppendInittab with this name -DONT free name. (leaving a memory-leak) btw, 'char *' should be 'const char*', but this applies to most other Python API functions. -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-02-17 19:47 Message: Logged In: YES user_id=1188172 Should AppendInittab() itself malloc a char buffer? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1419652&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1433667 ] os.path.expandvars sometimes doesn't expand $HOSTNAME
Bugs item #1433667, was opened at 2006-02-17 12:03
Message generated for change (Comment added) made by neurogeek
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433667&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: Doug Fort (dougfort)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.expandvars sometimes doesn't expand $HOSTNAME
Initial Comment:
$ echo "$HOSTNAME"
c0a80165.tipt.aol.com
$ /usr/local/bin/python
Python 2.4.2 (#1, Dec 30 2005, 11:14:42)
[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/Users/dougfort'
>>> os.path.expandvars("$HOSTNAME")
'$HOSTNAME'
>>>
arthurformat-d09:arthur$ echo $HOSTNAME
arthurformat-d09.ats.aol.com
arthurformat-d09:arthur$ /cm/tools/bin/python
Python 2.3.4 (#1, Jul 28 2004, 14:55:53)
[GCC 3.3.1] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/opt/aol/production/arthur'
>>> os.path.expandvars("$HOSTNAME")
'arthurformat-d09.ats.aol.com'
--
Comment By: neurogeek (neurogeek)
Date: 2006-02-17 15:20
Message:
Logged In: YES
user_id=1394223
No problem for me in a Gentoo box in python 2.3.4 nor python
2.4.2
Is the problem persistent? could you give some meore info on
this?
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 14:13
Message:
Logged In: YES
user_id=1188172
It might be good if you explain what the differences between
the two snippets are, environment-wise.
The first question that comes to mind is: is $HOSTNAME
exported in the first shell?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433667&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1421696 ] http response dictionary incomplete
Bugs item #1421696, was opened at 2006-02-01 18:56 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421696&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: http response dictionary incomplete Initial Comment: httplib and BaseHTTPServer each maintain their own copy of possible response codes. They don't agree. It looks like the one in httplib is a superset of the one in BaseHTTPServer.BaseHTTPRequestHandler.responses, and httplib is the logical place for it, but (1) They map in opposite directions. (2) The httplib version is just a bunch of names at the module toplevel, with no particular grouping that separates them from random classes, or makes them easy to import as a group. (3) The httplib names are explicitly not exported. -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-02-17 20:20 Message: Logged In: YES user_id=1188172 I moved the urllib2 one to httplib as it belongs there. The constants httplib are explicitly documented and must remain. The BaseHTTPServer mapping includes its own "unofficial" long error messages and therefore cannot be merged with the others. -- Comment By: Jim Jewett (jimjjewett) Date: 2006-02-06 23:39 Message: Logged In: YES user_id=764593 That may make the cleanup more urgent. The mapping in urllib2 is new with 2.5, so it should still be fine to remove it, or forward to httplib. The mapping in httplib is explicitly not exported, as there is an __all__ which excludes them, so it *should* be legitimate to remove them in a new release. BaseHTTPServer places the mapping as a class attribute on a public class. Therefore, either the final location has to include both the message and the long message (so that BaseHTTPServer can import it and delegate), or this has to be the final location, or we can't at best get down to two. -- Comment By: John J Lee (jjlee) Date: 2006-02-06 01:56 Message: Logged In: YES user_id=261020 There's also one in urllib2 :-( -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1421696&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1019808 ] wrong socket error returned
Bugs item #1019808, was opened at 2004-08-31 18:18
Message generated for change (Comment added) made by vercruesse
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Federico Schwindt (fgsch)
Assigned to: Neal Norwitz (nnorwitz)
Summary: wrong socket error returned
Initial Comment:
hi,
first, background:
OS: OpenBSD-current/i386
Python version: 2.3.4
example script:
import socket
socket.setdefaulttimeout(30)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', ))
where nothing is listening on (ECONNREFUSED
should be returned).
when ran it i get:
Traceback (most recent call last):
File "bug.py", line 8, in ?
s.connect(('127.0.0.1', ))
File "", line 1, in connect
socket.error: (22, 'Invalid argument')
this is a problem in the socketmodule.c, in the
internal_connect() function. getsockopt with SOCK_ERROR
should be used once EINPROGRESS is returned to get the
real error.
this code works on linux, but the connect semantic
is, imho, broken. you cannot reuse a socket once it
failed (a test afterwards shown that this is valid
under linux).
please contact me if you need further details,
although i find this very clear.
thanks,
f.-
--
Comment By: Frank Vercruesse (vercruesse)
Date: 2006-02-17 21:46
Message:
Logged In: YES
user_id=202246
I can confirm the bug running Python 2.4.2 on Mac OS X
10.4.5 (PPC). However, the patch doesn't seem to resolve the
issue. Now I get the following traceback when running the
posted script:
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1, in connect
socket.error: (36, 'Operation now in progress')
--
Comment By: Federico Schwindt (fgsch)
Date: 2005-10-03 21:44
Message:
Logged In: YES
user_id=50493
patch against 2.4.1 appended. not tested in anything but
openbsd. nevertheless, i think it should work in linux and
osx. not sure about others.
cheers.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 08:02
Message:
Logged In: YES
user_id=33168
Can you provide a patch that you believe corrects this problem?
--
Comment By: Federico Schwindt (fgsch)
Date: 2005-06-24 11:41
Message:
Logged In: YES
user_id=50493
just tried this with 2.4.1 running in OpenBSD 3.7/amd64 and
the problem is still there :-(
--
Comment By: Federico Schwindt (fgsch)
Date: 2004-09-23 05:58
Message:
Logged In: YES
user_id=50493
any news? this may be a problem in other *BSDs as well..
--
Comment By: Federico Schwindt (fgsch)
Date: 2004-08-31 18:22
Message:
Logged In: YES
user_id=50493
maybe i was not clear. the problem is only happening when
setdefaulttimeout is used. otherwise ECONNREFUSED is
correctly returned.
f.-
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1433667 ] os.path.expandvars sometimes doesn't expand $HOSTNAME
Bugs item #1433667, was opened at 2006-02-17 17:03
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433667&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: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Doug Fort (dougfort)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.expandvars sometimes doesn't expand $HOSTNAME
Initial Comment:
$ echo "$HOSTNAME"
c0a80165.tipt.aol.com
$ /usr/local/bin/python
Python 2.4.2 (#1, Dec 30 2005, 11:14:42)
[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/Users/dougfort'
>>> os.path.expandvars("$HOSTNAME")
'$HOSTNAME'
>>>
arthurformat-d09:arthur$ echo $HOSTNAME
arthurformat-d09.ats.aol.com
arthurformat-d09:arthur$ /cm/tools/bin/python
Python 2.3.4 (#1, Jul 28 2004, 14:55:53)
[GCC 3.3.1] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os.path
>>> os.path.expandvars("$HOME")
'/opt/aol/production/arthur'
>>> os.path.expandvars("$HOSTNAME")
'arthurformat-d09.ats.aol.com'
--
>Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 21:50
Message:
Logged In: YES
user_id=1188172
Closing as requested.
--
Comment By: Doug Fort (dougfort)
Date: 2006-02-17 21:11
Message:
Logged In: YES
user_id=6399
It looks like posixpath.py uses os.environ to resolve
environment variables. That makes sense. On my OS X 10.4
Python 2.4.2, HOSTNAME does not appear in os.environ. There
must be some shell gimmick to resolve it from the command line.
I originally experienced this error on RedHat Enterprise
Linux. I'm unable to reproduce it in the interpreteer. The
process experiencing the error is launched from our client's
version of init. I suspect it just isn't getting the
HOSTNAME environment variable passed to it.
So in short, os.expandvars works as designed. I apologize
for submitting the bug without checking more throughly.
--
Comment By: neurogeek (neurogeek)
Date: 2006-02-17 20:20
Message:
Logged In: YES
user_id=1394223
No problem for me in a Gentoo box in python 2.3.4 nor python
2.4.2
Is the problem persistent? could you give some meore info on
this?
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 19:13
Message:
Logged In: YES
user_id=1188172
It might be good if you explain what the differences between
the two snippets are, environment-wise.
The first question that comes to mind is: is $HOSTNAME
exported in the first shell?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433667&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1433877 ] string parameter to ioctl not null terminated, includes fix
Bugs item #1433877, was opened at 2006-02-17 16:29 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=1433877&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Quentin Barnes (qbarnes) Assigned to: Nobody/Anonymous (nobody) Summary: string parameter to ioctl not null terminated, includes fix Initial Comment: I ran across this problem in Python 2.3.3 and see it is still there in 2.4.2. When running the test_pty.py test case, I would get intermittant failures depending on how the test was invoked or the compiler flags used on Solaris. Trussing the interpreter while running the test revealed: ioctl(4, I_PUSH, "ptem\xff^T^F^H") Err#22 EINVAL There was garbage on the end of the string when it would fail. I tracked the problem back to fcntl_ioctl() in fcntlmodule.c. The string was not being NULL terminated, but relied on having zeroed gargage on the stack to work. I checked the source for 2.4.2 and noticed the same problem. Patch to fix the problem is attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1433886 ] pointer aliasing causes core dump, with workaround
Bugs item #1433886, was opened at 2006-02-17 16:56 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=1433886&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Quentin Barnes (qbarnes) Assigned to: Nobody/Anonymous (nobody) Summary: pointer aliasing causes core dump, with workaround Initial Comment: When building 2.3.3 on Solaris using Studio 11 and "-xalias_level=std" to enable ISO C99 pointer aliasing rules, the interpreter would core dump when running test_descr2.py. From examining the source, I believe this problem exists in 2.4.2 as well, but did not verify it. I was able to simplify the code to invoke the problem down to: class C1(object): def __new__(cls): return super(C1, cls).__new__(cls) a = C1() I tracked the problem to super_init() in Objects/typeobject.c. The local variable "obj" is of type "PyObject *" and "type" is of type "PyTypeObject *". In this function, both variables can be pointing to the same object in memory. Since the pointers are not of compatible types, the compiler ends up optimizing out a memory load between Py_INCREF(obj) and Py_INCREF(type) caching a previously read value. This causes the object reference counter to only be incremented once instead of twice. When the object is deallocated, the interpreter blows up. A workaround is to cast one of the pointers to the others type so that the compiler can see the pointer aliasing potential. This is what I did in the patch. What I suspect needs to be done as a more global fix is to discontinue use of the PyObject_VAR_HEAD macro hack. Casting between structures containing this macro creates ISO C99 pointer aliasing violations. The contents of the macro needs to be in its own structure which is referenced so a compliant compiler can know of possible aliasing. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1333982 ] Bugs of the new AST compiler
Bugs item #1333982, was opened at 2005-10-21 03:08
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
>Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: Bugs of the new AST compiler
Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.
--
Comment By: Armin Rigo (arigo)
Date: 2006-02-12 13:54
Message:
Logged In: YES
user_id=4771
Subscripting is generally a bit sloppy: e.g. the AST model has
no way to distinguish between a single value and a one-element
tuple value! See:
>>> d = {}
>>> d[1,] = 6
>>> d
{1: 6}# !
I suggest we fix the model to turn the 'subs' of the 'Subscript' node
from a list of nodes to a single, mandatory 'sub' node. If tupling is
necessary, it can be explicitly represented with a 'sub' containing a
'Tuple' node.
--
Comment By: Michael Hudson (mwh)
Date: 2006-02-09 07:02
Message:
Logged In: YES
user_id=6656
We found another one. Something is wrong in the compilation of augmented
assignment to subscriptions containing tuples; running this code:
class C:
def __setitem__(self, i, v):
print i, v
def __getitem__(self, i):
print i
return 0
c = C()
c[4,5] += 1
gives a spurious exception:
Traceback (most recent call last):
File "", line 1, in
TypeError: object does not support item assignment
By contrast, "c[(4,5)] += 1" works fine.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-17 23:10
Message:
Logged In: YES
user_id=33168
EXTENDED_ARG problem was fixed a while ago.
The assert/pass problem was fixed with: 41756.
That leaves the LOAD_CONST/POP_TOP optimization that was
lost and one compiler warning: marshal_write_mod() not being
used.
--
Comment By: Michael Hudson (mwh)
Date: 2005-12-10 16:41
Message:
Logged In: YES
user_id=6656
You have to include those lines in a source file. It still crashes for me.
--
Comment By: Brett Cannon (bcannon)
Date: 2005-12-10 15:44
Message:
Logged In: YES
user_id=357491
I just checked Armin's problem code on rev. 41638 and it
worked for me in the interpreter. You still having
problems, Armin?
--
Comment By: Armin Rigo (arigo)
Date: 2005-12-04 02:30
Message:
Logged In: YES
user_id=4771
At rev 41584, the following code snippet triggers an assert
if --with-pydebug is enabled:
Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed
---
assert 1, ([s for s in x] +
[s for s in x])
pass
---
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-23 12:14
Message:
Logged In: YES
user_id=33168
Checkpoint of outstanding issues. I think all the others
mentioned so far have been fixed:
* Raymond's warnings in compile.c (unused locals are fixed)
* EXTENDED_ARG problem
* LOAD_CONST/POP_TOP (note we can fix this in the optimizer
generally which would get rid of other useless code too)
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-22 21:53
Message:
Logged In: YES
user_id=80475
FWIW, here are the warnings issued by my compiler:
Python-ast.c
C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' :
unreferenced local variable
C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' :
unreferenced local variable
C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' :
unreferenced local variable
C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' :
unreferenced local variable
C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' :
unreferenced local variable
C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' :
unreferenced local variable
C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' :
unreferenced local variable
compile.c
C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation
from 'const int ' to 'char '
C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation
from 'const int ' to 'char '
C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation
from 'const int ' to 'char '
-
[ python-Bugs-1333982 ] Bugs of the new AST compiler
Bugs item #1333982, was opened at 2005-10-21 03:08
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: Bugs of the new AST compiler
Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-17 22:56
Message:
Logged In: YES
user_id=33168
Jeremy, there's no need to read anything before my last
comment at 2005-12-17 23:10. The last two by Armin,
Michael, then my last comment are the only important ones.
Everything that occurred before my 2005-12-17 comment was
taken care of AFAIK.
--
Comment By: Armin Rigo (arigo)
Date: 2006-02-12 13:54
Message:
Logged In: YES
user_id=4771
Subscripting is generally a bit sloppy: e.g. the AST model has
no way to distinguish between a single value and a one-element
tuple value! See:
>>> d = {}
>>> d[1,] = 6
>>> d
{1: 6}# !
I suggest we fix the model to turn the 'subs' of the 'Subscript' node
from a list of nodes to a single, mandatory 'sub' node. If tupling is
necessary, it can be explicitly represented with a 'sub' containing a
'Tuple' node.
--
Comment By: Michael Hudson (mwh)
Date: 2006-02-09 07:02
Message:
Logged In: YES
user_id=6656
We found another one. Something is wrong in the compilation of augmented
assignment to subscriptions containing tuples; running this code:
class C:
def __setitem__(self, i, v):
print i, v
def __getitem__(self, i):
print i
return 0
c = C()
c[4,5] += 1
gives a spurious exception:
Traceback (most recent call last):
File "", line 1, in
TypeError: object does not support item assignment
By contrast, "c[(4,5)] += 1" works fine.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-17 23:10
Message:
Logged In: YES
user_id=33168
EXTENDED_ARG problem was fixed a while ago.
The assert/pass problem was fixed with: 41756.
That leaves the LOAD_CONST/POP_TOP optimization that was
lost and one compiler warning: marshal_write_mod() not being
used.
--
Comment By: Michael Hudson (mwh)
Date: 2005-12-10 16:41
Message:
Logged In: YES
user_id=6656
You have to include those lines in a source file. It still crashes for me.
--
Comment By: Brett Cannon (bcannon)
Date: 2005-12-10 15:44
Message:
Logged In: YES
user_id=357491
I just checked Armin's problem code on rev. 41638 and it
worked for me in the interpreter. You still having
problems, Armin?
--
Comment By: Armin Rigo (arigo)
Date: 2005-12-04 02:30
Message:
Logged In: YES
user_id=4771
At rev 41584, the following code snippet triggers an assert
if --with-pydebug is enabled:
Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed
---
assert 1, ([s for s in x] +
[s for s in x])
pass
---
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-23 12:14
Message:
Logged In: YES
user_id=33168
Checkpoint of outstanding issues. I think all the others
mentioned so far have been fixed:
* Raymond's warnings in compile.c (unused locals are fixed)
* EXTENDED_ARG problem
* LOAD_CONST/POP_TOP (note we can fix this in the optimizer
generally which would get rid of other useless code too)
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-22 21:53
Message:
Logged In: YES
user_id=80475
FWIW, here are the warnings issued by my compiler:
Python-ast.c
C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' :
unreferenced local variable
C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' :
unreferenced local variable
C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' :
unreferenced local variable
C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' :
unreferenced local variable
C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' :
unreferenced local variable
C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' :
unrefere
[ python-Bugs-1433877 ] string parameter to ioctl not null terminated, includes fix
Bugs item #1433877, was opened at 2006-02-17 14:29 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None >Priority: 9 Submitted By: Quentin Barnes (qbarnes) >Assigned to: Thomas Wouters (twouters) Summary: string parameter to ioctl not null terminated, includes fix Initial Comment: I ran across this problem in Python 2.3.3 and see it is still there in 2.4.2. When running the test_pty.py test case, I would get intermittant failures depending on how the test was invoked or the compiler flags used on Solaris. Trussing the interpreter while running the test revealed: ioctl(4, I_PUSH, "ptem\xff^T^F^H") Err#22 EINVAL There was garbage on the end of the string when it would fail. I tracked the problem back to fcntl_ioctl() in fcntlmodule.c. The string was not being NULL terminated, but relied on having zeroed gargage on the stack to work. I checked the source for 2.4.2 and noticed the same problem. Patch to fix the problem is attached. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-17 23:14 Message: Logged In: YES user_id=33168 Thomas, could this have caused the flakiness that you just fixed with test_pty? This patch seems correct to me and I think it should be applied. (If you want I can do that, but I wanted you to see this first.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1432525 ] os.listdir doesn't release GIL
Bugs item #1432525, was opened at 2006-02-15 14:45 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Ellis (ellisj) Assigned to: Nobody/Anonymous (nobody) Summary: os.listdir doesn't release GIL Initial Comment: posix_listdir in posixmodule.c does not release the global interpreter lock, blocking all other threads for the duration of the call. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432525&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
