Re: [Python-Dev] Testing Socket Timeouts patch 1519025
Tony Nelson schrieb: Hmm, OK, darn, thanks. MSWindows does allow users to press Ctl-C to send a KeyboardInterrupt, so it's just too bad if I can't find a way to test it from a script. You can use GenerateConsoleCtrlEvent to send Ctrl-C to all processes that share the console of the calling process. BTW, I picked SIGALRM because I could do it all with one thread. Reading POSIX, ISTM that if I sent the signal from another thread, it would bounce off that thread to the main thread during the call to kill(), at which point I got the willies. OTOH, if kill() is more widely available than alarm(), I'll give it a try, but going by the docs, I'd say it isn't. Indeed, alarm should be available on any POSIX system. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] first draft of bug guidelines for www.python.org/dev/
On Thu, Jul 20, 2006 at 08:52:34PM -0700, Brett Cannon wrote: * Summary A one-line describing the problem so as to make it easy for developers to spot whether they have the expertise needed to work on the bug. Summary is also displayed as a title on index and search pages, so it is important to make the summary right - short and descriptive. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Which version of distutils to ship with Python 2.5?
Anthony Baxter schrieb: In any case, I bumped the version number to 2.5, according to the policy discussed in Could this not simply use the Python version number directly, instead? See the prior discussion at http://mail.python.org/pipermail/distutils-sig/2005-January/004366.html Some people still believe (at least, believed in January 2005), that distutils is developed independently of Python, and thus deserves its own version number. Of course, Andrew Kuchling officially declared in r1982 of pep 291 that there won't be any further stand-alone distutils releases, and therefore, backwards compatibility with 2.1 is not necessary anymore. So I changed distutils.__version__ again, to be derived from sys.version_info. I left the numerous comments still in distutils that compatibility with 2.1 is desired. We should remove these after 2.5 is released (or perhaps even before that). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
Jean-Paul Calderone [EMAIL PROTECTED] wrote: On Sat, 29 Jul 2006 14:38:38 -0700, Josiah Carlson [EMAIL PROTECTED] wrote: If someone is looking for a project for 2.6 that digs into all sorts of platform-specific nastiness, they could add actual signal sending to the signal module (at least for unix systems). Maybe I am missing something obvious, but what is necessary beyond os.kill()? I note that os.kill() does everything necessary for posix systems. I didn't notice that it took an argument for the kind of signal. A new project for someone: combine all of the methods available to Windows into a single function. What /would/ be useful is a complete sigaction wrapper, but that's a completely separate topic. Like atexit, only a stack per signal? - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
At 9:42 AM +0200 7/30/06, Martin v. Löwis wrote: Tony Nelson schrieb: Hmm, OK, darn, thanks. MSWindows does allow users to press Ctl-C to send a KeyboardInterrupt, so it's just too bad if I can't find a way to test it from a script. You can use GenerateConsoleCtrlEvent to send Ctrl-C to all processes that share the console of the calling process. That looks like it would work, but it seems prone to overkill. To avoid killing all the processes running from a console, the test would need to be run in a subprocess in a new process group. If the test simply sends the event to its own process, all the other processes in its process group would receive the event as well, and probably die. I would expect that all the processes sharing the console would die, but even if they didn't when I tried it, I couldn't be sure that it wouldn't happen elsewhere, say when run from a .bat file. Martin, your advice is usually spot-on, but I don't always understand it. Maybe using it here is just complicated. I expect that GenerateConsoleCtrlEvent() can be called through the ctypes module, though that would make backporting the test to 2.4 a bit more difficult. It looks like the subprocess module can be passed the needed creation flag to make a new process group. The subprocess can send the event to itself, and could return the test result in its result code, so that part isn't so bad. To avoid adding a new file to the distribution, test_socket.test_main() could be modified to look for a command line argument requesting the particular test action. BTW, I picked SIGALRM because I could do it all with one thread. Reading POSIX, ISTM that if I sent the signal from another thread, it would bounce off that thread to the main thread during the call to kill(), at which point I got the willies. OTOH, if kill() is more widely available than alarm(), I'll give it a try, but going by the docs, I'd say it isn't. Indeed, alarm should be available on any POSIX system. Well, if alarm() is available, then the test will work. If not, it will be silently skipped, as are some other tests already in test_socket.py. I can't offhand tell if MSWindows supports alarm(), but RiscOS and OS2 do not. TonyN.:' mailto:[EMAIL PROTECTED] ' http://www.georgeanelson.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
On Sun, 30 Jul 2006 09:50:36 -0700, Josiah Carlson [EMAIL PROTECTED] wrote: Jean-Paul Calderone [EMAIL PROTECTED] wrote: On Sat, 29 Jul 2006 14:38:38 -0700, Josiah Carlson [EMAIL PROTECTED] wrote: If someone is looking for a project for 2.6 that digs into all sorts of platform-specific nastiness, they could add actual signal sending to the signal module (at least for unix systems). Maybe I am missing something obvious, but what is necessary beyond os.kill()? I note that os.kill() does everything necessary for posix systems. I didn't notice that it took an argument for the kind of signal. A new project for someone: combine all of the methods available to Windows into a single function. What /would/ be useful is a complete sigaction wrapper, but that's a completely separate topic. Like atexit, only a stack per signal? I just mean a complete wrapping of sigaction(2). In particular, I need this functionality to properly install a SIGCHLD handler which does not interfer with various I/O functions by installing the handler with the SA_RESTART flag, which is not currently possible using the signal.signal function. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 release schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Re: Python 2.5 compatibility On Jul 28, 2006, at 8:57 AM, Barry Warsaw wrote: +1. It would give me more type to port and test a few of my applications to the new version. I'm still working on Mailman but the most painful thing so far has been the conversion of exceptions to new-style classes, and even that wasn't /too/ painful. I believe I've finished porting Mailman to Python 2.5. None of the issues were insurmountable, but here they are FTR: 1) Exceptions are new-style classes but Mailman was doing one specific test against the type of an object to see if it needed to be instantiated. This test was written as: if isinstance(obj, ClassType) which fails in Python 2.5. I actually rewrote it like so: if isinstance(obj, ClassType) or isinstance(obj, type(type)) in MM2.1 because it has to be backward compatible to Python 2.1. 2) There was one place where I was commonly raising a string and that generates deprecation warnings, so I changed that to a class. There are a few other legacy string exceptions defined in the code, but they are rarely used and should all get rewritten as well. 3) Cookie.py's repr changed so that trailing semicolons are no longer output on the end of text lines. I understand this change was made so that Python cookies were more RFC compliant, but it broke some homegrown cookie text splitting we were doing. I changed this code to split on lines first. All in all, not too bad although the Cookie.py change took a while to track down! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRM0MDnEjvBPtnXfVAQJ9ZAP/VdtM79SXgx7s/X0aEIu4HDZva7TkYyi6 dRzlgAtEV5BN1yYn+vzw8PBCtdy+9N3yYtv/zqdQP54mZDjsaGaNw6MiS0jsETRy 248hj3otL/00WTrKWh8/OvDlLW8KUNQI4MWBOMKJ/TqYW5Es4fJGEMtbO/xqGXXD /wgWmmLOOAE= =Mu8m -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 release schedule
On Sunday 30 July 2006 15:44, Barry Warsaw wrote: if isinstance(obj, ClassType) or isinstance(obj, type(type)) Looks like you've got a possible name clash in the second isinstance. ;-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 release schedule
Barry Warsaw wrote: if isinstance(obj, ClassType) which fails in Python 2.5. I actually rewrote it like so: if isinstance(obj, ClassType) or isinstance(obj, type(type)) The second type seems to be superfluous. ;) Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 release schedule
On Sunday 30 July 2006 16:17, Georg Brandl wrote: The second type seems to be superfluous. ;) I was thinking it suggested there was a local named type. But if not, yeah. I get the impression Barry's pretty new to this Python thing. Wonder what he's been up to. ;-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 release schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 30, 2006, at 4:27 PM, Fred L. Drake, Jr. wrote: On Sunday 30 July 2006 16:17, Georg Brandl wrote: The second type seems to be superfluous. ;) I was thinking it suggested there was a local named type. But if not, yeah. I get the impression Barry's pretty new to this Python thing. Wonder what he's been up to. ;-) As I mentioned, this has to be compatible with Python 2.1: Python 2.1.3+ (#1, Apr 25 2005, 22:52:02) [GCC 3.3.5-20050130 (Gentoo Linux 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie- on linux2 Type copyright, credits or license for more information. isinstance(Exception, type) Traceback (most recent call last): File stdin, line 1, in ? TypeError: isinstance() arg 2 must be a class or type isinstance(Exception, type(type)) 0 Python 2.5b2 (trunk:50835, Jul 25 2006, 23:27:51) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type help, copyright, credits or license for more information. isinstance(Exception, type) True isinstance(Exception, type(type)) True I thought that was rather clever actually. :) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRM0fj3EjvBPtnXfVAQI1AQP+ID6BSbJ/4TL7cizvMjrxHD6JVjFKBzD6 7FCwXpvELQt7vlDWGrXWi+Lai/93nGqD42VYRSgtHqFP2gMYKEkM+TaLl91YFuSh B6jO7l5wW7SGlyLQQiibmPBp8uGDG30F1ylM9e9y9c69Hy1LJEa1sG8/AS/FiA+n fpQ/WlTNRvA= =uGDZ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 release schedule
Fred L. Drake, Jr. schrieb: On Sunday 30 July 2006 15:44, Barry Warsaw wrote: if isinstance(obj, ClassType) or isinstance(obj, type(type)) Looks like you've got a possible name clash in the second isinstance. ;-) Nah, that's rather an entry to the obfuscated Python contest. The two occurrences of type really mean to refer to the same thing; this is the test whether obj _is a_ new-style class. Normally, you would write isinstance(obj, type), but that gives a TypeError in 2.1 (isinstance() arg 2 must be a class or type). In 2.1, type(type) is FunctionType, so the test should fail (in the context, as obj ought to be a string, an exception object, or an exception type). In 2.2 and later, we have type(type) is type 1 # sometimes True instead I think I would have rewritten as try: # Instantiate it if possible and necessary exc = exc() except AttributeError: # no __call__; it's already an object pass (assuming that the mailman exceptions don't have __call__) or as if not isinstance(exc, Exception): exc = exc() (assuming that string exceptions are gone, but the code below already assumes that exc should be an object that supports exc.reason_notice()) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
Tony Nelson schrieb: You can use GenerateConsoleCtrlEvent to send Ctrl-C to all processes that share the console of the calling process. [...] Martin, your advice is usually spot-on, but I don't always understand it. Maybe using it here is just complicated. This was really just in response to your remark that you couldn't find a way to send Ctrl-C programmatically. I researched (in the C library sources) how SIGINT was *generated* (through SetConsoleCtrlHandler), and that let me to a way to generate I didn't mean to suggest that you *should* use GenerateConsoleCtrlEvent, only that you could if you wanted to. I expect that GenerateConsoleCtrlEvent() can be called through the ctypes module, though that would make backporting the test to 2.4 a bit more difficult. Well, if there was general utility to that API, I would prefer exposing it in the nt module. It doesn't quite fit into kill(2), as it doesn't allow to specify a pid of the target process, so perhaps it doesn't have general utility. In any case, that would have to wait for 2.6. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
At 11:42 PM +0200 7/30/06, Martin v. Löwis wrote: Tony Nelson schrieb: You can use GenerateConsoleCtrlEvent to send Ctrl-C to all processes that share the console of the calling process. [...] Martin, your advice is usually spot-on, but I don't always understand it. Maybe using it here is just complicated. This was really just in response to your remark that you couldn't find a way to send Ctrl-C programmatically. I researched (in the C library sources) how SIGINT was *generated* (through SetConsoleCtrlHandler), and that let me to a way to generate [one.] Well, fine work there! I didn't mean to suggest that you *should* use GenerateConsoleCtrlEvent, only that you could if you wanted to. Hmm. Well, it would make the test possible on MSWindows as well as on OS's implementing alarm(2). If I figure out how to build Python on MSWindows, I might give it a try. I tried to get MSVC 7.1 via the .Net SDK, but it installed VS 8 instead, so I'm not quite sure how to proceed. I expect that GenerateConsoleCtrlEvent() can be called through the ctypes module, though that would make backporting the test to 2.4 a bit more difficult. Well, if there was general utility to that API, I would prefer exposing it in the nt module. It doesn't quite fit into kill(2), as it doesn't allow to specify a pid of the target process, so perhaps it doesn't have general utility. In any case, that would have to wait for 2.6. A Process Group ID is the PID of the first process put in it, so it's sort of a PID. It just means a collection of processes, probably more than one. It seems to be mostly applicable to MSWindows, and isn't a suitable way to implement a form of kill(2). I hope that the Socket Timeouts patch 1519025 can make it into 2.5, or 2.5.1, as it is a bug fix. As such, it would probably be better to punt the test on MSWindows than to do a tricky fancy test that might have its own issues. TonyN.:' mailto:[EMAIL PROTECTED] ' http://www.georgeanelson.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
At 7:23 PM -0400 7/30/06, Tony Nelson wrote: ... ...I tried to get MSVC 7.1 via the .Net SDK, but it installed VS 8 instead, so I'm not quite sure how to proceed. ... David Murmann suggested off-list that I'd probably installed the 2.0 .Net SDK, and that I should install the 1.1 .Net SDK, which is the correct one. Now I can try to build Python on MSWindows. TonyN.:' mailto:[EMAIL PROTECTED] ' http://www.georgeanelson.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
Tony Nelson schrieb: Hmm. Well, it would make the test possible on MSWindows as well as on OS's implementing alarm(2). If I figure out how to build Python on MSWindows, I might give it a try. I tried to get MSVC 7.1 via the .Net SDK, but it installed VS 8 instead, so I'm not quite sure how to proceed. The .NET SDK (any version) is not suitable to build Python. You really need VS 2003; if you don't have it anymore, you might be able to find a copy of the free version of the VC Toolkit 2003 (VCToolkitSetup.exe) somewhere. Of course, just for testing, you can also install VS Express 2005, and use the PCbuild8 projects directory; these changes should work the same under both versions. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
At 4:34 AM +0200 7/31/06, Martin v. Löwis wrote:
Tony Nelson schrieb:
Hmm. Well, it would make the test possible on MSWindows as well as on
OS's implementing alarm(2). If I figure out how to build Python on
MSWindows, I might give it a try. I tried to get MSVC 7.1 via the .Net
SDK, but it installed VS 8 instead, so I'm not quite sure how to proceed.
The .NET SDK (any version) is not suitable to build Python.
I do see the warning in the instructions about it not be an optimizing
compiler. I've managed to build python.exe and the rt.bat tests mostly
work -- 2 tests fail, test_popen, and test_cmd_line because of popen()
failing.
Hmm, actually, this might be a real problem with the MSWindows version of
posix_popen() in Modules/posixmodule.c. The path to my built python.exe is:
E:\Documents and Settings\Tony Nelson\My
Documents\Python\pydev\trunk\PCBuild\python.exe
(lots of spaces in it). It seems properly quoted in the test and when I do
it by hand, but in a call to popen() it doesn't work:
popen('E:\Documents and Settings\Tony Nelson\My
Documents\Python\pydev\trunk\PCBuild\python.exe -c import
sys;sys.version_info')
The returned file object repr resembles one that does work. If I just use
python.exe from within the PCBuild directory:
popen('python.exe -c import sys;sys.version_info')
I get the right version, and that's the only 2.5b2 python I've got, so the
built python must be working, but the path, even quoted, isn't accepted by
MSWindows XP SP2. Should I report a bug? It may well just be MSWindows
weirdness, and not something that posixmodule.c can do anything about.
OTOH, it does work from the command line. I'll bet I wouldn't have seen a
thing if I'd checked out to E:\pydev instead.
You really need VS 2003; if you don't have it anymore, you might be able
to find a copy of the free version of the VC Toolkit 2003
(VCToolkitSetup.exe) somewhere.
I really never had VS 2003. It doesn't appear to be on microsoft.com
anymore. I'm reluctant to try to steal a copy.
Of course, just for testing, you can also install VS Express 2005, and
use the PCbuild8 projects directory; these changes should work the
same under both versions.
I'll try that if I have any real trouble with the non-optimized python or
if you insist that it's necessary.
TonyN.:' mailto:[EMAIL PROTECTED]
' http://www.georgeanelson.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] httplib and bad response chunking
On Tue, Jul 25, 2006 at 10:32:13PM -0400, Greg Ward wrote: what I discovered in the wild the other day was a response like this: 0005\r\nabcd\n\r\n0004\r\nabc\n\r\n\r\n i.e. the chunk-size for the terminating empty chunk was missing. This cause httplib.py to blow up with ValueError because it tried to call int(line, 16) assuming that 'line' contained a hex number, when in fact it was the empty string. Oops. IMHO the minimal fix is to turn ValueError into HTTPException (or a subclass thereof); httplib should not raise ValueError just because some server sends a bad response. (The server in question was Apache 2.0.52 running PHP 4.3.9 sending a big hairy error page because the database was down.) IMNSHO httplib should be fixed and this shouldn't be an error at all as its in the wild and will only show up more and more in the future. Plus file a bug with the apache or php project as appropriate for having a non-RFC compliant response. This is part of the good old network programming addage of being lenient in what you accept. -g ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
At 12:39 AM -0400 7/31/06, Tony Nelson wrote:
popen('E:\Documents and Settings\Tony Nelson\My
Documents\Python\pydev\trunk\PCBuild\python.exe -c import
sys;sys.version_info')
Ehh, I must admit that I retyped that. Obviously what I typed would not
work, but what I used was:
python = '' + sys.executable + ''
popen(python + ' -c import sys;sys.version_info'
So there wasn't a problem with backslashes. I've also been using raw
strings. And, as I said, the file objects looked OK, with backslashes
where they should be. Sorry for the mistyping.
TonyN.:' mailto:[EMAIL PROTECTED]
' http://www.georgeanelson.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Testing Socket Timeouts patch 1519025
At 12:58 AM -0400 7/31/06, Tony Nelson wrote:
At 12:39 AM -0400 7/31/06, Tony Nelson wrote:
popen('E:\Documents and Settings\Tony Nelson\My
Documents\Python\pydev\trunk\PCBuild\python.exe -c import
sys;sys.version_info')
Ehh, I must admit that I retyped that. Obviously what I typed would not
work, but what I used was:
python = '' + sys.executable + ''
popen(python + ' -c import sys;sys.version_info'
So there wasn't a problem with backslashes. I've also been using raw
strings. And, as I said, the file objects looked OK, with backslashes
where they should be. Sorry for the mistyping.
OK, I recognize the bug now. It's that quote parsing bug in MSWindows
(which I can find again if you want) which can be worked around by using an
extra quote at the front (and maybe also the back):
popen('E:\Documents ...
Not really a bug in Python at all.
TonyN.:' mailto:[EMAIL PROTECTED]
' http://www.georgeanelson.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
