[Python-Dev] Bug in PyErr_WriteUnraisable ?
I'd hit an access violation inside PyErr_WriteUnraisable when a non-exception instance was raised. The call to PyExceptionClass_Name with a non-exception instance is yielding an invalid pointer. We are embedding Python 2.5 and a string instance is raised using PyThreadState_SetAsyncExc. I can fix that in my code, by raising an appropiate exception instance, but I think PyErr_WriteUnraisable lacks some checks. -- Gabriel Becedillas Developer CORE SECURITY TECHNOLOGIES ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Embedded Python:: C/Python: Is Py_Finalize() necessary between embedded function calls?
Hi, I am developing an application where I have Python embedded in C
functions using the C/Python API to execute commands. My question stems
from my need to preserve a PyObject to pass between these Python
embedded C functions. My question is: do I have to call Py_Finalize() at
the end of each Python embedded C function?
The abstract structure of my code looks like this:
PyObject *po;
main() {
po = py_function_1();
// some C code in the middle here...
po = py_function_2(po);
// some more C code here...
}
In my implementation of py_function_1 and py_function_2 do I have to
call Py_Initialize() and Py_Finalize at the beginning and end of each of
the two functions? Or can I just call Py_Initialize at the beginning of
py_function_1 and then call Py_Finalize() at the end of py_function_2?
Thank You.
SP
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Embedded Python:: C/Python: Is Py_Finalize() necessary between embedded function calls?
On Fri, Feb 23, 2007 at 04:24:19AM -0800, Sydney Pang wrote: > do I have to call Py_Finalize() at > the end of each Python embedded C function? As far I understand you only need to call Py_Initialize() and Py_Finalize() once per every embedded interpreter, not for an every function. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug in PyErr_WriteUnraisable ?
On 2/22/07, Gabriel Becedillas <[EMAIL PROTECTED]> wrote: > I'd hit an access violation inside PyErr_WriteUnraisable when a > non-exception instance was raised. The call to PyExceptionClass_Name > with a non-exception instance is yielding an invalid pointer. > We are embedding Python 2.5 and a string instance is raised using > PyThreadState_SetAsyncExc. I can fix that in my code, by raising an > appropiate exception instance, but I think PyErr_WriteUnraisable lacks > some checks. > Please use the the bug tracker at http://sourceforge.net/tracker/?group_id=5470&atid=105470 to report issues with Python. -Brett > -- > > > Gabriel Becedillas > Developer > CORE SECURITY TECHNOLOGIES > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] microthreading vs. async io
Hi Adam, On Thu, Feb 15, 2007 at 06:17:03AM -0700, Adam Olsen wrote: > > E.g. have a wait(events = [], timeout = -1) method would be sufficient > > for most cases, where an event would specify > > I agree with everything except this. A simple function call would > have O(n) cost, thus being unacceptable for servers with many open > connections. Instead you need it to maintain a set of events and let > you add or remove from that set as needed. I just realized that this is not really true in the present context. If the goal is to support programs that "look like" they are multi-threaded, i.e. don't use callbacks, as I think is Joachim's goal, then most of the time the wait() function would be only called with a *single* event, rarely two or three, never more. Indeed, in this model a large server is implemented with many microthreads: at least one per client. Each of them blocks in a separate call to wait(). In each such call, only the events revelant to that client are mentioned. In other words, the cost is O(n), but n is typically 1 or 2. It is not the total number of events that the whole application is currently waiting on. Indeed, the scheduler code doing the real OS call (e.g. to select()) can collect the events in internal dictionaries, or in Poll objects, or whatever, and update these dictionaries or Poll objects with the 1 or 2 new events that a call to wait() introduces. In this respect, the act of *calling* wait() already means "add these events to the set of all events that need waiting for", without the need for a separate API for doing that. [Actually, I think that the simplicity of the wait(events=[]) interface over any add/remove/callback APIs is an argument in favor of the "microthread-looking" approach in general, though I know that it's a very subjective topic.] [I have experimented myself with a greenlet-based system giving wrapper functions for os.read()/write() and socket.recv()/send(), and in this style of code we tend to simply spawn new greenlets all the time. Each one looks like an infinite loop doing a single simple job: read some data, process it, write the result somewhere else, start again. (The loops are not really infinite; e.g. if sockets are closed, an exception is generated, and it causes the greenlet to exit.) So far I've managed to always wait on a *single* event in each greenlet, but sometimes it was a bit contrieved and being able to wait on 2-3 events would be handy.] A bientot, Armin. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] NOARGS_NULL
K D schrieb: > I thought it would be nice to have the code marked somehow so that it > was obvious what the additional (and obviously unused) parameter was. > The two references (NULL and METH_NOARGS) are both in upper-case and as > C is a case-sensitive language I think it's probably usual to do > case-sensitive greps etc when trying to understand code. Therefore, I > thought NOARGS_NULL as a name had enough information in it for someone > to "find their way" when looking at the code and wondering what that > unused parameter was declared for. Kev, The style-guide in C is that macro names are spelled in all-caps, so if you see an all-caps identifier, you expect it to be a macro name. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] dinner at Standard in Dallas
I'm organizing a trip to Standard in downtown Dallas for dinner tonight (Sunday night). It's about a 10 minute cab ride to Standard. We can share cabs and get there without too much trouble. The restaurant is on the expensive side. I'm thinking we should leave from the hotal around 6:30pm. http://www.standarddallas.com/ http://restaurants.dallasobserver.com/search/restaurants.php?oid=27399 A large group of us went for dinner last year and had a great time. The food was excellent, short ribs and mashed potatoes with truffles stand out in my mind. They also serve a tangerita cocktail--margerita made with Tang--that was memorable. Let me know if you'd like to come and I'll make reservations and arrange for cabs. Jeremy [Apologies if you get two copies of this message. The first one looks like it got lost or stuck.] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python-3000 upgrade path
I'm sending this to python-dev instead of python-3000 for two reasons: It's not about features to be added to Python 3.0, and it's not really about 3.0at all -- it's about 2.6 and later. It's about how we get Python 2.x to 3.0, and howmuch of 3.0we put into 2.6 and later. So here at PyCon, Guido did his usual talk about Py3K and how it's going to look. He also covered the tool he's writing to do the necessary syntactic translations, and short bits about how to write code to accommodate the other changes. One thing Guido didn't cover -- because it isn't his area of expertise and (correctly) expects others to step up and do it -- is the upgrade path for third party Python applications and libraries. I happen to care a lot about that, and so do a few other core Python developers, and we *will* make it happen in the smoothest way possible. We could use some community guidance on this, though. Here's my current thinking on the subject (and I talked about this with a couple of different people at the conference and in email): 1) Anything we can backport from Python 3.0 to Python 2.6 without breaking existing code, will be backported. So far, this means all the new features. 2) A few of the things going away in 3.0 will be warned about in 2.6 by default: things that have had better alternative for ages and are generally bad: backticks and input() are the only ones that come to mind right now. 3) The rest of the things that will change or go away in 3.0 *and* have alternatives in 2.6 will be warned about optionally. Neal is rewriting the warnings module to C, which should speed up warning generation a lot, and if necessary we'll use a global 'warn-for-py3k' flag to reduce the overhead for these warnings to the absolute minimum. 4) The new features of 3.0 that we can't backport (things changing semantics, instead of being added or going away) will be made available in 2.6 (as much as possible), using future statements. Right now, I cannot think of a single thing that cannot be made available that way. They will be, in essence, backward-compatibility hacks, but they'll work and the performance impact will be minimal. Of course, 4 is somewhat of a sweeping statement, even with the parenthesised reservation, considering some of the 3.0 features haven't been implemented yet. I'm pretty confident we can do this without comprimising 3.0, though. If we cannot, we might need to add an extra 'migration feature' in Python 2.7, or 2.8 or even 2.9 (but as it is now, I'm not sure that's specifically necessary. We may still want to release Python 2.7 and later for other reasons, of course.) The end result will be that you can write your Python code so it works in 2.6-or-later and 3.0, or -- just like now -- in 2.x-or-later (where 'x' depends on the features you use) but not 3.0. If you write careful code, you may get away with writing 2.2-or-later code that can be run in 3.0 with a single translation run. It will be fairly unlikely you can write code for 2.5-or-earlier *and* 3.0 without using the translation step, unless you live in a world blissfully unaware of anything non-ASCII. In any case, while we aren't working to make that possible, we certainly won't go out of the way to prevent it (but there still won't be any compromises in the 3.0 language just for code compatibility.) As I said, I've talked with a few people about this, both python core developers and people who develop their own software. I would like to hear from people who have concrete doubts about this upgrade path. I don't mean doubts about Python 3.0 -- this mail isn't about 3.0 at all, and I can only suggest you try out the py3k branch when the dubious feature(s) are implemented. I also don't mean doubts about how we're going to keep the performance impact minimal or how we're going to handle dict views and what not. I mean doubts about this procedure of having transitional releases between 2.5 and 3.0, and the *community* impact of 2.6+ and 3.0 this way. One thing in particular I wonder about is the warning about mixing tabs and spaces. Should it be in category 2) (on by default) or 3) (still off by default, but part of -Wpy3k)? -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] status of switch to Roundup off of SF
When I gave the PSF members an update on the work to move the python-dev tracker over to Roundup Andrew Kuchling asked me to also send an email to python-dev since October/November. As of right now the biggest thing holding up the transition is documentation. A doc needs to get written explaining basic workflow of how issues should be handled. Also need to go through and remove SF references and make them more general (e.g., mention an "issue tracker" when possible). After that some redirects need to be tweaked. www.python.org/sf/ needs to redirect to the Roundup installation (which is keeping SF bug numbers). bugs.python.org will also be set to point to the Roundup server. After all of that we will find out from Anthony and Neal when a release is going to be so as to do the switch when it won't run into a release (before or after). The current test tracker is at http://psf.upfronthosting.co.za/roundup/tracker/ . The meta tracker for dealing with this stuff is at http://psf.upfronthosting.co.za/roundup/meta/ . Feel free to have a look, but please don't go overboard with the suggestions on changes. It is not difficult to change the tracker after it launches. The last thing any of us want to see is the tracker launch delayed because someone wants a feature that takes a while to implement. Unless there is a critical issue you find it would be appreciated if you file the suggestion and just let us push after the launch if it is deemed it will take too much time to implement. The mailing list where all discussions take place is http://mail.python.org/mailman/listinfo/tracker-discuss . Fairly low-traffic although all updates to the meta tracker get sent there. Obviously if you have questions feel free to ask. And if you want to help with getting the switch to happen just speak up. =) -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] dinner at Standard in Dallas
I'm organizing a trip to Standard in downtown Dallas for dinner tonight (Sunday night). It's about a 10 minute cab ride to Standard. We can share cabs and get there without too much trouble. The restaurant is on the expensive side. I'm thinking we should leave from the hotal around 6:30pm. http://www.standarddallas.com/ http://restaurants.dallasobserver.com/search/restaurants.php?oid=27399 A large group of us went for dinner last year and had a great time. The food was excellent, short ribs and mashed potatoes with truffles stand out in my mind. They also serve a tangerita cocktail--margerita made with Tang--that was memorable. Let me know if you'd like to come and I'll make reservations and arrange for cabs. Jeremy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3000 upgrade path
On 2/25/07, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > It's about how we get Python 2.x to 3.0, and howmuch of 3.0 we put into 2.6 > and later. I've also talked to a bunch of people at PyCon, including Thomas. There seems to be much concern (rightfully so!) about the upgrade path from 2.x to 3.x. I don't think it will be easy to navigate, but I have confidence we can do a great job. My goal is to rip out as much cruft from the code base for 3k to make it easier to maintain. In order for users to adopt 3k, it must provide real benefit. In addition, it as painless as possible for third party developers to support both 2.x and 3.x. All the developers I talked to expressed relief that we weren't forgetting about them. There's still unease and will be until we demonstrate what we plan to do. They were satisfied with our general approach. The time schedules in PEP 361 (2.6 release schedule) and what Guido has said for 3k (from what I remember) are roughly: April 2007 - 3.0 PEPs and features accepted/decided June 2007 - 3.0a1 - basic (most) features implemented Dec 2007 - 2.6a1 Apr 2008 - 2.6 final July 2008 - 3.0 final Even if we slip these schedules, as long as we keep them in relative order, we can keep 2.6 robust, while also offering many of the 3k features. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bool conversion wart?
Guido van Rossum wrote: > How would this change be helpful? I'm utterly mystified by these > suggestions that bool would be more useful if it didn't behave like an > int in arithmetic. I think there's a desire by some people to get rid of unnecessary conceptual baggage left over for historical reasons. Those people are mystified as to why anyone would *want* a boolean to behave like an int. Personally I'm +0 on this. I wouldn't object if it happened, but I'm not pushing for it. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3000 upgrade path
Neal Norwitz <[EMAIL PROTECTED]> wrote: > The time schedules in PEP 361 (2.6 release schedule) and what Guido > has said for 3k (from what I remember) are roughly: > > April 2007 - 3.0 PEPs and features accepted/decided > June 2007 - 3.0a1 - basic (most) features implemented Any talk at PyCon regarding the new IO system? That looks like the biggest piece of unfinished Py3k work. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3000 upgrade path
On 2/25/07, Neil Schemenauer <[EMAIL PROTECTED]> wrote: > Neal Norwitz <[EMAIL PROTECTED]> wrote: > > The time schedules in PEP 361 (2.6 release schedule) and what Guido > > has said for 3k (from what I remember) are roughly: > > > > April 2007 - 3.0 PEPs and features accepted/decided > > June 2007 - 3.0a1 - basic (most) features implemented > > Any talk at PyCon regarding the new IO system? That looks like the > biggest piece of unfinished Py3k work. AFAIK, there hasn't been any work on the new IO system or str/unicode unification. Guido asked for help on these, but I don't know if there were any takers. Sprints will be held over the next several days, so hopefully there will be some work in these areas. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3000 upgrade path
Just the "it's not there yet" part :) There's some prototype code and email conversations archived, but no recent work that I'm aware of. On 2/25/07, Neil Schemenauer <[EMAIL PROTECTED]> wrote: Neal Norwitz <[EMAIL PROTECTED]> wrote: > The time schedules in PEP 361 (2.6 release schedule) and what Guido > has said for 3k (from what I remember) are roughly: > > April 2007 - 3.0 PEPs and features accepted/decided > June 2007 - 3.0a1 - basic (most) features implemented Any talk at PyCon regarding the new IO system? That looks like the biggest piece of unfinished Py3k work. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/thomas%40python.org -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3000 upgrade path
On 2/25/07, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On 2/25/07, Neil Schemenauer <[EMAIL PROTECTED]> wrote: > > Any talk at PyCon regarding the new IO system? That looks like the > > biggest piece of unfinished Py3k work. > > AFAIK, there hasn't been any work on the new IO system or str/unicode > unification. Guido asked for help on these, but I don't know if there > were any takers. Sprints will be held over the next several days, so > hopefully there will be some work in these areas. Right. To be honest, I consider the str/unicode unification a much bigger project than the new I/O library. I plan to do the new I/O library first (mostly in Python) first, hopefully at the PyCon sprint, since it can be done with the bytes and unicode objects; the old I/O library will break once we do the unification so the I/O library must be replaced before the unification can be started. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3000 upgrade path
On Sun, Feb 25, 2007 at 05:37:08PM -0600, Guido van Rossum wrote: > Right. To be honest, I consider the str/unicode unification a much > bigger project than the new I/O library. I was more concerned about IO because it would seem to require your time for design work. The str/unicode work could be farmed out to a bunch of workers. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3000 upgrade path
On 2/25/07, Neil Schemenauer <[EMAIL PROTECTED]> wrote: > On Sun, Feb 25, 2007 at 05:37:08PM -0600, Guido van Rossum wrote: > > Right. To be honest, I consider the str/unicode unification a much > > bigger project than the new I/O library. > > I was more concerned about IO because it would seem to require your > time for design work. The str/unicode work could be farmed out to a > bunch of workers. I was more thinking of pulling a few all-nighters -- seriously, since it needs to be done as quickly as possible once it is started. The number of volunteers who want to do C code is also dwindling... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming Include/object.h
On 1/3/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > In #1626545, Anton Tropashko requests that object.h should be > renamed, because it causes conflicts with other software. > > I would like to comply with this requests for 2.6, assuming there > shouldn't be many problems with existing software as object.h > shouldn't be included directly, anyway. I like the idea of renaming the header files, but I expect there is a lot more opportunity for breaking code that you estimate. I did a search on google.com/codesearch and found seven external packages that include Python.h and object.h (before I gave up). I assume we expect people won't include it, because it is also included in object.h. But they do it. Is there documentation that says you shouldn't import it? Jeremy > What do you think? > > Regards, > Martin > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3000 upgrade path
Thomas Wouters wrote: > One thing in particular I wonder about > is the warning about mixing tabs and spaces. Should it be in category 2) > (on by default) or 3) (still off by default, but part of -Wpy3k)? For my part, it wouldn't bother me at all if you turn it on by default any time you want. I've been careful to avoid tab-space mixing ever since my earliest uses of Python. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3000 upgrade path
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 25, 2007, at 3:49 PM, Neal Norwitz wrote: > The time schedules in PEP 361 (2.6 release schedule) and what Guido > has said for 3k (from what I remember) are roughly: > > April 2007 - 3.0 PEPs and features accepted/decided > June 2007 - 3.0a1 - basic (most) features implemented > Dec 2007 - 2.6a1 > Apr 2008 - 2.6 final > July 2008 - 3.0 final > > Even if we slip these schedules, as long as we keep them in relative > order, we can keep 2.6 robust, while also offering many of the 3k > features. I said semi-jokingly that the first release of Py3k should be / literally/ called Python 3000. Then each successive stabilizing release should drop a zero -- e.g. Python 3000, then Python 300, then Python 30. By the time we get to Python 3 all we should basically have to do is change the defaults of whatever Python 2.x version is out to complete the transition. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBReJgp3EjvBPtnXfVAQIZQgP+K5iWRTYHYvqb3cAUFJw/yDDiz5JPG94x XdMEnCUXwJVyU30q3FGSNeaz3hwQq7xgJuH5DBRHnGkxp7H/K42ft/KXnJVGnkt4 Kai8e26+zBXmCSCTVdJyKhpAiiFAqKTw26+L+a1jyJdSbUnly3coBAvRaOS9oQn6 QcVfx5vCOsM= =o7Ux -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3000 upgrade path
Barry Warsaw writes: > I said semi-jokingly that the first release of Py3k should be / > literally/ called Python 3000. Then each successive stabilizing > release should drop a zero -- e.g. Python 3000, then Python 300, then > Python 30. RKN = reverse Knuth numbering? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
