[ python-Bugs-1705362 ] cannot change cursor color in IDLE
Bugs item #1705362, was opened at 2007-04-22 19:14 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=1705362&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: zorkin (zorkin) Assigned to: Nobody/Anonymous (nobody) Summary: cannot change cursor color in IDLE Initial Comment: Python 2.5.1 for windows When I change the cursor color to another color, it still stays black, so I can't really make black background. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705362&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1705365 ] 'nonlocal x' at top level crashes interpreter
Bugs item #1705365, was opened at 2007-04-22 12: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=1705365&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Reese (johnreese)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'nonlocal x' at top level crashes interpreter
Initial Comment:
A nonlocal declaration at the interpreter top level causes a bus error. This
happens in the p3yk branch at head (r54922). Reporter is using MacOS 10.4.9 on
Intel. Reporter is perfectly aware that nonlocal doesn't do anything useful at
the top level, but feels it should not crash the interpreter.
% gdb python3.0
GNU gdb 6.3.50-20050815 (Apple version gdb-563) (Wed Jul 19 05:10:58 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for shared
libraries .. done
(gdb) run
Starting program: /Users/jtr/bin/python3.0
Reading symbols for shared libraries . done
Python 3.0x (p3yk:54922, Apr 22 2007, 12:15:19)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> nonlocal x
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0004
PySet_Contains (anyset=0x0, key=0x532640) at Objects/setobject.c:2129
2129if (!PyAnySet_Check(anyset)) {
(gdb) The program is running. Exit anyway? (y or n) y
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705365&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1705393 ] Select() failure (race condition)
Bugs item #1705393, was opened at 2007-04-22 13:38
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=1705393&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ron Garret (rongarret)
Assigned to: Nobody/Anonymous (nobody)
Summary: Select() failure (race condition)
Initial Comment:
select.select fails on file-like objects created by socket.makefile when data
exists in the file buffer but not in the underlying socket.
Here is code to reproduce the bug. Run it, then point a web browser at port
8080 and observer that select times out indicating that no input is available
even though input is still in fact available.
===
from SocketServer import *
from socket import *
from select import select
class myHandler(StreamRequestHandler):
def handle(self):
while 1:
sl = select([self.rfile],[],[],1)[0]
print sl
l = self.rfile.readline()
if len(l)<3: break
print l,
pass
print>>self.wfile, 'HTTP/1.0 200 OK'
print>>self.wfile, 'Content-type: text/plain'
print>>self.wfile
print>>self.wfile, 'foo'
server = TCPServer(('',8080), myHandler)
server.serve_forever()
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705393&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1703110 ] Incorrect example for add_password()
Bugs item #1703110, was opened at 2007-04-18 12:56
Message generated for change (Comment added) made by bkline
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703110&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bob Kline (bkline)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect example for add_password()
Initial Comment:
In the documentation for urllib2, the example [1] for using basic HTTP
authentication has the following code for the call to add_password():
auth_handler.add_password('realm', 'host', 'username', 'password')
This actually worked in earlier (pre-2.4.3) versions of urllib2, but even in
those older versions, the documentation for HTTPPasswordMgr.add_password()
makes it clear that a URI must be passed as the second argument to the method,
not a host name.
Even though the behavior in the library method has changed (passing a full URI
versions of Python earlier than 2.4.3 didn't work, at least when a non-standard
port was specified), the documentation has not changed (the add_password()
documentation specifies a URI, even in the pre-2.4.3 versions of Python) and
the examples in the documentation for urllib2 still say 'host'.
[1] http://docs.python.org/lib/urllib2-examples.html
--
>Comment By: Bob Kline (bkline)
Date: 2007-04-22 17:00
Message:
Logged In: YES
user_id=291529
Originator: YES
If I'm not right in assuming that the documentation is generated directly
from urllib2.py let me know and I'll try to find the right separate file in
svn.
File Added: urllib2.py.patch
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-21 19:49
Message:
Logged In: YES
user_id=33168
Originator: NO
Bob, can you submit a patch to correct these problems? Note: we no
longer support the 2.4 series.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703110&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-813986 ] robotparser interactively prompts for username and password
Bugs item #813986, was opened at 2003-09-28 13:06 Message generated for change (Comment added) made by nagle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813986&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: 6 Private: No Submitted By: Erik Demaine (edemaine) Assigned to: Martin v. Löwis (loewis) Summary: robotparser interactively prompts for username and password Initial Comment: This is a rare occurrence, but if a /robots.txt file is password-protected on an http server, robotparser interactively prompts (via raw_input) for a username and password, because that is urllib's default behavior. One example of such a URL, at least at the time of this writing, is http://www.cosc.canterbury.ac.nz/robots.txt Given that robotparser and robots.txt is all about *robots* (not interactive users), I don't think this interactive behavior is terribly appropriate. Attached is a simple patch to robotparser.py to fix this behavior, forcing urllib to return the 401 error that it ought to. Another issue is whether a 401 (Authorization Required) URL means that everything should be allowed or everything should be disallowed. I'm not sure what's "right". Reading the spec, it says 'This file must be accessible via HTTP on the local URL "/robots.txt"' which I would read to mean it should be accessible without username/password. On the other hand, the current robotparser.py code says "if self.errcode == 401 or self.errcode == 403: self.disallow_all = 1" which has the opposite effect. I'll leave deciding which is most appropriate to the powers that be. -- Comment By: John Nagle (nagle) Date: 2007-04-22 21:12 Message: Logged In: YES user_id=5571 Originator: NO I tried the patch by doing this: import robotparser def prompt_user_passwd(self, host, realm): return None, None robotparser.URLopener.prompt_user_passwd = prompt_user_passwd# temp patch This dealt with the problem effectively; robots.txt files are being processed normally, and if reading one causes an authentication request, it's handled as if no password was input, without any interaction. So this could probably go in. -- Comment By: John Nagle (nagle) Date: 2007-04-21 16:53 Message: Logged In: YES user_id=5571 Originator: NO The attached patch was never integrated into the distribution. This is still broken in Python 2.4 (Win32), Python 2.5 (Win32), and Python 2.5 (Linux). This stalled an overnight batch job for us. Very annoying. Reproduce with: import robotparser url = 'http://mueblesmoraleda.com' # whole site is password-protected. parser = robotparser.RobotFileParser() parser.set_url(url) parser.read() # Prompts for password -- Comment By: Wummel (calvin) Date: 2003-09-29 13:24 Message: Logged In: YES user_id=9205 http://www.robotstxt.org/wc/norobots-rfc.html specifies the 401 and 403 return code consequences as restricting the whole site (ie disallow_all = 1). For the password input, the patch looks good to me. On the long term, robotparser.py should switch to urllib2.py anyway, and it should handle Transfer-Encoding: gzip. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813986&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1705365 ] 'nonlocal x' at top level crashes interpreter
Bugs item #1705365, was opened at 2007-04-22 19:20
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705365&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 3000
Status: Open
Resolution: None
>Priority: 6
Private: No
Submitted By: John Reese (johnreese)
>Assigned to: Nick Coghlan (ncoghlan)
Summary: 'nonlocal x' at top level crashes interpreter
Initial Comment:
A nonlocal declaration at the interpreter top level causes a bus error. This
happens in the p3yk branch at head (r54922). Reporter is using MacOS 10.4.9 on
Intel. Reporter is perfectly aware that nonlocal doesn't do anything useful at
the top level, but feels it should not crash the interpreter.
% gdb python3.0
GNU gdb 6.3.50-20050815 (Apple version gdb-563) (Wed Jul 19 05:10:58 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for shared
libraries .. done
(gdb) run
Starting program: /Users/jtr/bin/python3.0
Reading symbols for shared libraries . done
Python 3.0x (p3yk:54922, Apr 22 2007, 12:15:19)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> nonlocal x
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0004
PySet_Contains (anyset=0x0, key=0x532640) at Objects/setobject.c:2129
2129if (!PyAnySet_Check(anyset)) {
(gdb) The program is running. Exit anyway? (y or n) y
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-04-22 22:23
Message:
Logged In: YES
user_id=849994
Originator: NO
Nick, that crash is in the symtable code you refactored with the setcomp
patch.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705365&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1703110 ] Incorrect example for add_password()
Bugs item #1703110, was opened at 2007-04-18 16:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703110&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bob Kline (bkline)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect example for add_password()
Initial Comment:
In the documentation for urllib2, the example [1] for using basic HTTP
authentication has the following code for the call to add_password():
auth_handler.add_password('realm', 'host', 'username', 'password')
This actually worked in earlier (pre-2.4.3) versions of urllib2, but even in
those older versions, the documentation for HTTPPasswordMgr.add_password()
makes it clear that a URI must be passed as the second argument to the method,
not a host name.
Even though the behavior in the library method has changed (passing a full URI
versions of Python earlier than 2.4.3 didn't work, at least when a non-standard
port was specified), the documentation has not changed (the add_password()
documentation specifies a URI, even in the pre-2.4.3 versions of Python) and
the examples in the documentation for urllib2 still say 'host'.
[1] http://docs.python.org/lib/urllib2-examples.html
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-04-22 22:25
Message:
Logged In: YES
user_id=849994
Originator: NO
The docs are maintained separately, you'll have to look at
Doc/lib/liburllib2.tex.
--
Comment By: Bob Kline (bkline)
Date: 2007-04-22 21:00
Message:
Logged In: YES
user_id=291529
Originator: YES
If I'm not right in assuming that the documentation is generated directly
from urllib2.py let me know and I'll try to find the right separate file in
svn.
File Added: urllib2.py.patch
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-21 23:49
Message:
Logged In: YES
user_id=33168
Originator: NO
Bob, can you submit a patch to correct these problems? Note: we no
longer support the 2.4 series.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703110&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1693753 ] Portability issue: os.rename behaves differently on win32
Bugs item #1693753, was opened at 2007-04-03 12:17 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693753&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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: cs_ (cs_) Assigned to: Nobody/Anonymous (nobody) Summary: Portability issue: os.rename behaves differently on win32 Initial Comment: os.rename(src, dst) fails on Windows if dst already exist and regular file. On Unixes, it does not fail, and silently overwrites dst. It's better to use MoveFileEx(src, dst, MOVEFILE_REPLACE_EXISTING) when moving regular files under Win32 to make it behave consistent way. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-04-22 18:48 Message: Logged In: YES user_id=984087 Originator: NO I submitted a patch for this (1704547) -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-04-12 12:35 Message: Logged In: YES user_id=984087 Originator: NO >From MSDN document and googling, it does look like MOVEFILE_REPLACE_EXISTING guarantees atomicity for rename operation. I will see if I can come up with a patch (I will first need to learn building python on windows). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693753&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1703110 ] Incorrect example for add_password()
Bugs item #1703110, was opened at 2007-04-18 12:56
Message generated for change (Comment added) made by bkline
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703110&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bob Kline (bkline)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect example for add_password()
Initial Comment:
In the documentation for urllib2, the example [1] for using basic HTTP
authentication has the following code for the call to add_password():
auth_handler.add_password('realm', 'host', 'username', 'password')
This actually worked in earlier (pre-2.4.3) versions of urllib2, but even in
those older versions, the documentation for HTTPPasswordMgr.add_password()
makes it clear that a URI must be passed as the second argument to the method,
not a host name.
Even though the behavior in the library method has changed (passing a full URI
versions of Python earlier than 2.4.3 didn't work, at least when a non-standard
port was specified), the documentation has not changed (the add_password()
documentation specifies a URI, even in the pre-2.4.3 versions of Python) and
the examples in the documentation for urllib2 still say 'host'.
[1] http://docs.python.org/lib/urllib2-examples.html
--
>Comment By: Bob Kline (bkline)
Date: 2007-04-22 21:38
Message:
Logged In: YES
user_id=291529
Originator: YES
File Added: bug1703110.patch
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-04-22 18:25
Message:
Logged In: YES
user_id=849994
Originator: NO
The docs are maintained separately, you'll have to look at
Doc/lib/liburllib2.tex.
--
Comment By: Bob Kline (bkline)
Date: 2007-04-22 17:00
Message:
Logged In: YES
user_id=291529
Originator: YES
If I'm not right in assuming that the documentation is generated directly
from urllib2.py let me know and I'll try to find the right separate file in
svn.
File Added: urllib2.py.patch
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-21 19:49
Message:
Logged In: YES
user_id=33168
Originator: NO
Bob, can you submit a patch to correct these problems? Note: we no
longer support the 2.4 series.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703110&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-1705520 ] pyunit should allow __unittest in locals to trim stackframes
Feature Requests item #1705520, was opened at 2007-04-23 13:56
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=1705520&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.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Collins (rbcollins)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyunit should allow __unittest in locals to trim stackframes
Initial Comment:
pyunit looks for __unittest = 1 in the globals of functions in an assertion
stacktrace. This is used to trim the trace so that unittest implementation
methods do not show up.
It would be great if it looked in the locals of the frame as well, as this
would allow subclasses of TestCase that add new assertFOO methods to have them
filtered in the same manner.
e.g. (bad example :))
def assertComplexState(self, inputs):
__unittest = 1
self.assertEqual('42', inputs[0], 'the input %s is not the right answer' %
inputs)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1705520&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1705393 ] Select() failure (race condition)
Bugs item #1705393, was opened at 2007-04-22 17:38
Message generated for change (Comment added) made by gagenellina
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705393&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ron Garret (rongarret)
Assigned to: Nobody/Anonymous (nobody)
Summary: Select() failure (race condition)
Initial Comment:
select.select fails on file-like objects created by socket.makefile when data
exists in the file buffer but not in the underlying socket.
Here is code to reproduce the bug. Run it, then point a web browser at port
8080 and observer that select times out indicating that no input is available
even though input is still in fact available.
===
from SocketServer import *
from socket import *
from select import select
class myHandler(StreamRequestHandler):
def handle(self):
while 1:
sl = select([self.rfile],[],[],1)[0]
print sl
l = self.rfile.readline()
if len(l)<3: break
print l,
pass
print>>self.wfile, 'HTTP/1.0 200 OK'
print>>self.wfile, 'Content-type: text/plain'
print>>self.wfile
print>>self.wfile, 'foo'
server = TCPServer(('',8080), myHandler)
server.serve_forever()
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-04-23 01:53
Message:
Logged In: YES
user_id=479790
Originator: NO
The handler should not do its own select() call. (And even then, select
should use the underlying socket, not the wrapping pseudo-file object).
Just removing the select() call works fine.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705393&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1703448 ] "t.join(); assert t not in threading.enumerate()" fails
Bugs item #1703448, was opened at 2007-04-19 05:22 Message generated for change (Comment added) made by gagenellina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrew Bennetts (spiv) Assigned to: Raymond Hettinger (rhettinger) Summary: "t.join(); assert t not in threading.enumerate()" fails Initial Comment: This script always fails for me, usually on the very first iteration: import threading while True: print '.', t = threading.Thread(target=lambda: None) t.start() t.join() alive_threads = threading.enumerate() assert len(alive_threads) == 1, alive_threads The docs clearly say this is expected to work: Thread.join is described as "Wait until the thread terminates" and threading.enumerate's description says it will "Return a list of all currently active Thread objects ... It excludes terminated threads". So by the time t.join() returns, the thread should not be reported by threading.enumerate anymore. The bug appears to be that while the thread is shutting down, join() may exit too early: it waits for the __stopped flag to be set, but the thread hasn't necessarily been removed from the _active dict by that time, so enumerate will report a "stopped" thread. (Or if you like the bug is that __stopped is can be set while the thread is still in the _active dict.) A workaround is to filter the results of threading.enumerate() through [t for t in threading.enumerate() if t.isAlive()]. -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-04-23 02:21 Message: Logged In: YES user_id=479790 Originator: NO The analysis appears to be correct, but I can't reproduce the bug with 2.5 on Windows XP SP2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703448&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1705362 ] cannot change cursor color in IDLE
Bugs item #1705362, was opened at 2007-04-22 16:14 Message generated for change (Comment added) made by gagenellina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705362&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: zorkin (zorkin) Assigned to: Nobody/Anonymous (nobody) Summary: cannot change cursor color in IDLE Initial Comment: Python 2.5.1 for windows When I change the cursor color to another color, it still stays black, so I can't really make black background. -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-04-23 02:48 Message: Logged In: YES user_id=479790 Originator: NO IDLE on Windows appears to be using an always-black caret (cursor) - not the standard caret behavior, which does its "blinking" by inverting the background color. So something might be improved here, but I doubt you can reliably set the caret color on Windows; see http://support.microsoft.com/kb/84054/en-us -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705362&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1703448 ] "t.join(); assert t not in threading.enumerate()" fails
Bugs item #1703448, was opened at 2007-04-19 05:22 Message generated for change (Comment added) made by gagenellina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrew Bennetts (spiv) Assigned to: Raymond Hettinger (rhettinger) Summary: "t.join(); assert t not in threading.enumerate()" fails Initial Comment: This script always fails for me, usually on the very first iteration: import threading while True: print '.', t = threading.Thread(target=lambda: None) t.start() t.join() alive_threads = threading.enumerate() assert len(alive_threads) == 1, alive_threads The docs clearly say this is expected to work: Thread.join is described as "Wait until the thread terminates" and threading.enumerate's description says it will "Return a list of all currently active Thread objects ... It excludes terminated threads". So by the time t.join() returns, the thread should not be reported by threading.enumerate anymore. The bug appears to be that while the thread is shutting down, join() may exit too early: it waits for the __stopped flag to be set, but the thread hasn't necessarily been removed from the _active dict by that time, so enumerate will report a "stopped" thread. (Or if you like the bug is that __stopped is can be set while the thread is still in the _active dict.) A workaround is to filter the results of threading.enumerate() through [t for t in threading.enumerate() if t.isAlive()]. -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-04-23 02:51 Message: Logged In: YES user_id=479790 Originator: NO The analysis appears to be correct, but I can't reproduce the bug with 2.5 on Windows XP SP2. -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-04-23 02:21 Message: Logged In: YES user_id=479790 Originator: NO The analysis appears to be correct, but I can't reproduce the bug with 2.5 on Windows XP SP2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703448&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1705393 ] Select() failure (race condition)
Bugs item #1705393, was opened at 2007-04-22 13:38
Message generated for change (Comment added) made by rongarret
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705393&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ron Garret (rongarret)
Assigned to: Nobody/Anonymous (nobody)
Summary: Select() failure (race condition)
Initial Comment:
select.select fails on file-like objects created by socket.makefile when data
exists in the file buffer but not in the underlying socket.
Here is code to reproduce the bug. Run it, then point a web browser at port
8080 and observer that select times out indicating that no input is available
even though input is still in fact available.
===
from SocketServer import *
from socket import *
from select import select
class myHandler(StreamRequestHandler):
def handle(self):
while 1:
sl = select([self.rfile],[],[],1)[0]
print sl
l = self.rfile.readline()
if len(l)<3: break
print l,
pass
print>>self.wfile, 'HTTP/1.0 200 OK'
print>>self.wfile, 'Content-type: text/plain'
print>>self.wfile
print>>self.wfile, 'foo'
server = TCPServer(('',8080), myHandler)
server.serve_forever()
--
>Comment By: Ron Garret (rongarret)
Date: 2007-04-22 23:00
Message:
Logged In: YES
user_id=1775883
Originator: YES
>Just removing the select() call works fine.
For this simple example yes, not for more complicated cases. My
particular application is a transparent HTTP proxy which needs to be able
to serve multiple connections at once and handle keep-alive connections.
(The proxy connects to local server processes through unix sockets, which
is why I can't use a regular HTTP proxy. Send me email if you want more
details about why I'm doing this.) Without writing a full-blown HTTP-aware
proxy, select (or something like it) is necessary.
Upon further study, though, I have come to the conclusion that this is not
actually a bug (since select is doing what it is advertised to do), just
very counter-intituitive behavior. If select is going to accept file
objects as arguments it ought to do the Right Thing with them IMO.
--
Comment By: Gabriel Genellina (gagenellina)
Date: 2007-04-22 21:53
Message:
Logged In: YES
user_id=479790
Originator: NO
The handler should not do its own select() call. (And even then, select
should use the underlying socket, not the wrapping pseudo-file object).
Just removing the select() call works fine.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705393&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
