Re: [Python-Dev] Python 2.4 extensions require VC 7.1?
Actually, I was looking at the 1989 standard which is what we are supposed to be using, right? But the exact wording in 99 is: If the request can be honored, the signal function returns the value of func for the most recent successful call to signal for the specified signal sig. Otherwise, a value of SIG_ERR is returned and a positive value is stored in errno.. Sorry for meitioning EINVAL, my mistake. Continuing the hairsplitting: Note that the standard doesn´t specify the valid signals, they are implementation defined as you say. and in that sense, any old integer cannot be considered a signal sig in the above quote. So stricly speaking (in my interpretation) there is nothing wrong in aborting for an integer that isn´t defined to be a signal by the implementation. However: Let´s just agree that signal() isn´t up to spec, and leave it out of the discussion. There are provisions all over the code for particular quirks of particular platforms. Everything else appears to be up to spec. However, the usual, natural, straight-forward way of processing the mode string (in a loop with a switch statement) can't possible cause crashes. Making assumptions about how someone implements the CRT is not good practice. Relying on the implementors to go above and beyond the spec to ensure stability or some common sense behaviour is inviting trouble. We should be wary, not just on microsoft platforms, on treading onto domain that isn't defined. Anything can happen. Literally. But if you expect that, then in that sense, the VC8 implementation is probably better than most. Because they have gone out of their way to try to identify all possible ways that you can violate the domain of those functions, and do something defined if you do. So the behavior of these functions is defined for much wider range of input than for most other implementations, in other words, they have gone above and beyond the spec. So we can redirect all signals handlers to Python code if the user wishes so. I wonder. Setting process wide handlers like that seems to be odd if you are embedding python to do scripting for you. The main app is usually the one that decides on signal handling for various things. Seems like a python.exe thing to me. But never mind. At the very least one should then only set those handlers that are valid for each implementation. I'd also like to draw your attention to lines 1162 and onwards in timemodule.c, lines 410 onwards. Here is an example of us forcing values into an acceptable range, although the standard says: If any of the specified values is outside the normal range, the characters stored are unspecified.. But on some platforms it would crash, not just store unspecified values. So we are already compensating for implementations that break the standard (I think we can agree that this is breakage). So, if I agree with you that signal() is broken (by default, but mended by our fix) is there any any other technical reason why VC8 should not be taken into the fold? After all, it has already pointed out to us that we are dangerously allowing user format strings to propagate. Cheers, Kristján ___ 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] Python 2.4 extensions require VC 7.1?
Kristján V. Jónsson wrote: However, the usual, natural, straight-forward way of processing the mode string (in a loop with a switch statement) can't possible cause crashes. Making assumptions about how someone implements the CRT is not good practice. I'm not arguing about that, and I think Python should be changed. Notice, however, that this would be a behavioural change: currently, Python passes through the mode argument for open(), exposing the platform-specific behaviour. If Python would reject mode arguments that are not supported in standard C, programs that currently work may break. I wonder. Setting process wide handlers like that seems to be odd if you are embedding python to do scripting for you. The main app is usually the one that decides on signal handling for various things. Seems like a python.exe thing to me. But never mind. At the very least one should then only set those handlers that are valid for each implementation. There is no portable way to find out what those are. So, if I agree with you that signal() is broken (by default, but mended by our fix) is there any any other technical reason why VC8 should not be taken into the fold? After all, it has already pointed out to us that we are dangerously allowing user format strings to propagate. I can't say for sure - there should be some testing first. One issue I can think of is the packaging: Microsoft wants us to install msvcr80.dll using their SxS technology, with manifests and everything. That needs to be considered in the build process, and dealt with in the MSI production. I have no experience with side-by-side installation of native assemblies yet, so I would have to learn this first, or wait for somebody to provide patches. This probably also impacts exe builders, which have to pick up the DLL from SxS. Another technical issue is the absence of support for msvcr80.dll in MinGW - one currently couldn't build Python extensions that link with the right CRT. Not purely technical, but somebody would also need to find out what the licensing conditions on msvcr80.dll are: what are the conditions for redistribution if I have a licensed copy of VS 2005? What if I have VS Express? What if I have neither, and just want to package it as a side effect of using, say, py2exe? 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] Python 2.4 extensions require VC 7.1?
This is, in fact, exactly what the python trunk does right now. This is done in exceptions.c Kristján -Original Message- From: Scott Dial [mailto:[EMAIL PROTECTED] Sent: 17. júní 2006 12:54 To: Python Dev Cc: Martin v. Löwis; Kristján V. Jónsson Subject: Re: [Python-Dev] Python 2.4 extensions require VC 7.1? I'm nobody but I don't find your argument compelling. I suggest you go read: http://msdn2.microsoft.com/en-us/library/ksazx244.aspx ___ 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] Python 2.4 extensions require VC 7.1?
The signal() doc is rather vague on the point, since it doesn´t define the availible set of signals. It doesn´t even say that a signal identifier is an integer. But it says that it should return EINVAL if it cannot satisfy the request. It doesn´t say if the request is invalid, but I don't want to go into hairsplitting here. So I could agree with you there. But I completely disagree when you insist that microsoft has broken the C library. What they have done is added parameter validation, and thus simply added code in the undefined domain. I would also like to point out that, again apart from signal(), you are relying on undefined behaviour of fopen and others. It may well cause a crash on one of your other platforms one day, you have no way of knowing. VS2005 just pointed that out to you. So, it is my suggestion that in stead of going all defensive, and shouting breakage, why not simply fix those very dubious CRT usage patterns? Think of it as lint. Also, consider this: in the case of file() and strftime() we are passing in dynamic strings. The strings are not within control of python. Normally these are static strings, within the control of the developer which has the function reference on hand, knows what he wants and so on. Yet, here we are passing in any old strings. There is a huge undefined domain there, and we should be very concerned about that. It is a wonder we haven´t seen these functions crash before. I would like to see the question about whether or not to use VS2005 be made purely on the merit of what is most practical (and useful) for people, rather than some emotional arguments about with loaded terms like breakage, and personal feelings towards Microsoft. (And by the way, why does pythoncore.dll mess with signal() anyway? shouldn´t that be python.exe? I don´t want a dll that I embed to mess with my signal handling) Cheers, Kristján -Original Message- From: Martin v. Löwis [mailto:[EMAIL PROTECTED] Sent: 17. júní 2006 13:28 To: Scott Dial Cc: Python Dev; Kristján V. Jónsson Subject: Re: [Python-Dev] Python 2.4 extensions require VC 7.1? Sure, I can *make* the library conform to C 99. I could also write my own C library entirely to achieve that effect. The fact remains that VS 2005 violates standard C where VS 2003 and earlier did not: A conforming program will abort, instead of completing successfully. ___ 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] Python 2.4 extensions require VC 7.1?
Kristján V. Jónsson wrote: The signal() doc is rather vague on the point, since it doesn´t define the availible set of signals. It doesn´t even say that a signal identifier is an integer. But it says that it should return EINVAL if it cannot satisfy the request. What signal() doc are you looking at? I'm looking at http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf section 7.14. This is ISO C99 (actually, technical corrigendum 2 of that), and it does not mention EINVAL. (BTW, signal does not *return* EINVAL, it returns SIG_ERR and sets errno). signal() isn't vague about the set of available signals. 7.14/3 lists some, then 7.14/4 says # The complete set of signals, their semantics, and their default # handling is implementation-defined; all signal numbers shall be # positive. It doesn´t say if the request is invalid Ah, so you are looking at the Microsoft documentation? As the implementation isn't compliant to standard C, I would not expect their documentation to faithfully reproduce standard C. but I don't want to go into hairsplitting here. It's an important point. If Python does not follow some relevant standard, and therefore breaks, it is Python that must be fixed. If it breaks on some system which in itself violates some standard, we have the choice of either working around or ignoring the system. But I completely disagree when you insist that microsoft has broken the C library. But they have. A program that is compliant to standard C used to work with earlier versions of the C library, and stops working with the current version. What they have done is added parameter validation, and thus simply added code in the undefined domain. Except that the set of supported signals is not undefined, it's implementation-defined. See 3.4.1 for a definition of implementation-defined behaviour, and 3.4.3 for a definition of undefined behaviour. I would also like to point out that, again apart from signal(), you are relying on undefined behaviour of fopen and others. That is true, so we should fix Python here. So, it is my suggestion that in stead of going all defensive, and shouting breakage, why not simply fix those very dubious CRT usage patterns? Think of it as lint. Again, for fopen: sure. For signal, this is not possible: We want to set *all* signal handlers on a system, but we have know way of determining at compile time what all signal handlers are. Standard C is deliberately designed to allow applications to do that, and with msvcr80.dll, we can't. Also, consider this: in the case of file() and strftime() we are passing in dynamic strings. The strings are not within control of python. Normally these are static strings, within the control of the developer which has the function reference on hand, knows what he wants and so on. Yet, here we are passing in any old strings. There is a huge undefined domain there, and we should be very concerned about that. It is a wonder we haven´t seen these functions crash before. No, that's not a wonder. It's actually unfortunate that standard C did not make it an error, but they likely didn't do it because of existing practice. However, the usual, natural, straight-forward way of processing the mode string (in a loop with a switch statement) can't possible cause crashes. (And by the way, why does pythoncore.dll mess with signal() anyway? So we can redirect all signals handlers to Python code if the user wishes so. 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] Python 2.4 extensions require VC 7.1?
Giovanni Bajo wrote: It was discussed before, and the agreement was to use VS 2003 for another cycle (i.e. 2.5). But the fact that VS 2003 is no longer available for download is an important fact, and we might want to rediscuss the issue. it's still available in the .net sdk packages (see comp.lang.python), and it's still available for MSDN subscribers. /F ___ 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] Python 2.4 extensions require VC 7.1?
Giovanni Bajo wrote: It was discussed before, and the agreement was to use VS 2003 for another cycle (i.e. 2.5). But the fact that VS 2003 is no longer available for download is an important fact, and we might want to rediscuss the issue. I don't recall the discussion vividly, but I think the reasoning was something like because it still works. Maybe I remember wrong, but this is not a compelling argument en lieu of it being hard to get a hold of the toolkit. If there is some kind of legwork involved with getting python moved to VS2005, then I'll volunteer.. Despite the possibility illegality of the posting of the toolkit, I suggest curious people to google for 'Index Of VCToolkitSetup.exe', if need be. -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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] Python 2.4 extensions require VC 7.1?
Fredrik Lundh wrote: It was discussed before, and the agreement was to use VS 2003 for another cycle (i.e. 2.5). But the fact that VS 2003 is no longer available for download is an important fact, and we might want to rediscuss the issue. it's still available in the .net sdk packages (see comp.lang.python), and it's still available for MSDN subscribers. It's also easy to get a used copy on ebay. 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] Python 2.4 extensions require VC 7.1?
Scott Dial wrote: I don't recall the discussion vividly, but I think the reasoning was something like because it still works. Maybe I remember wrong, but this is not a compelling argument en lieu of it being hard to get a hold of the toolkit. If there is some kind of legwork involved with getting python moved to VS2005, then I'll volunteer.. There were several reasons: it's the same compiler that was used to compile Python 2.4, so authors of Python extension modules typically already have a copy. Switching to VS 2005 would require people to get that first, and it would require people to have three releases of VC installed just to build modules for Python 2.3, 2.4, and 2.5. Another reason is that I consider VS 2005 buggy, I hope that some of the breakage that Microsoft has done to the C library is reverted in a future release. VS2005 managed to break compatibility with C89 and C99 in a way that made Python fail to start up, also, it was possible to have the CRT abort just by calling the builtin open with the wrong arguments. There is now a work-around for that breakage, but still, I don't trust that VS 2005 is a good product. I'm hoping that Python can skip VS 2005 entirely, and go straight to VS 2007 (or whatever it will be called) 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] Python 2.4 extensions require VC 7.1?
I remember you voicing this point at the Texas sprint. I can't say I agree. The behaviour of certain function (like signal and fopen) is undefined for certain arguments. Undefined is undefined, exiting the program with an admonition is one of the possible outcomes (as is formatting your hard drive.) In my opinion this is to be considered a good thing since it helps us adhere to the defined parts of the standards and not rely on something which is utterly unknown or unpredictable by the standards (but which happens to work on some platforms, no thanks to the standards.) Besides, we only found this an issue in three places: signal(), fopen() and strftime() functions. Not a huge thing to fix. Apart from these things, I must say that in my experience VC2005 is an surprisingly stable product. The whole program (link-step) optimization is a boon, and if combined with profile guided optimization (PGO), works wonders. VS2005 also can create binaries for the X64 windows platform, no small point, and the primary reason we started using it in the first place. I encourage people to look at the PCBuild8 directory in the current python trunk. Especially I would like suggestions and comments on how to better automate the PGO build process Cheers, Kristján -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin v. Löwis Sent: 17. júní 2006 08:26 To: Scott Dial Cc: Python Dev Subject: Re: [Python-Dev] Python 2.4 extensions require VC 7.1? Another reason is that I consider VS 2005 buggy, I hope that some of the breakage that Microsoft has done to the C library is reverted in a future release. VS2005 managed to break compatibility with C89 and C99 in a way that made Python fail to start up, also, it was possible to have the CRT abort just by calling the builtin open with the wrong arguments. There is now a work-around for that breakage, but still, I don't trust that VS 2005 is a good product. I'm hoping that Python can skip VS 2005 entirely, and go straight to VS 2007 (or whatever it will be called) for 2.6. ___ 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] Python 2.4 extensions require VC 7.1?
Kristján V. Jónsson wrote: I remember you voicing this point at the Texas sprint. I can't say I agree. The behaviour of certain function (like signal and fopen) is undefined for certain arguments. Undefined is undefined, exiting the program with an admonition is one of the possible outcomes (as is formatting your hard drive.) For fopen(3), you are right. For signal(3), VS2005 is in clear violation with ISO C, which specifies in 7.14.1.1 [#8] If the request can be honored, the signal function returns the value of func for the most recent successful call to signal for the specified signal sig. Otherwise, a value of SIG_ERR is returned and a positive value is stored in errno. The set of acceptable signals is deliberately implementation-defined, and it is consequential that an attempt to set an unsupported signal gives an error (ISO C cannot specify that the error is EINVAL, since EINVAL is not part of ISO C). In my opinion this is to be considered a good thing since it helps us adhere to the defined parts of the standards and not rely on something which is utterly unknown or unpredictable by the standards (but which happens to work on some platforms, no thanks to the standards.) Besides, we only found this an issue in three places: signal(), fopen() and strftime() functions. Not a huge thing to fix. For fopen and strftime, they could have achieved the same effect with just setting errno to EINVAL. The C runtime library just should never ever terminate the program unless explicitly asked to, just as Python should never ever terminate execution without giving the application a chance to intervene (e.g. by catching an exception). VS2005 also can create binaries for the X64 windows platform, no small point, and the primary reason we started using it in the first place. OTOH, you don't *need* VS2005 to create AMD64 binaries. I had been creating Itanium binaries for several years now with VS2003, and started producing AMD64 binaries for Python 2.5. 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] Python 2.4 extensions require VC 7.1?
Martin v. Löwis wrote:
For fopen(3), you are right. For signal(3), VS2005 is in clear
violation with ISO C
I'm nobody but I don't find your argument compelling. I suggest you go
read: http://msdn2.microsoft.com/en-us/library/ksazx244.aspx
In short, you can tell the CRT to do whatever you like when the
parameters are invalid, including returning EINVAL.
void VS2005_CRT_invalidParamHandler(const wchar_t* expression,
const wchar_t* function,
const wchar_t* file,
unsigned int line,
uintptr_t pReserved)
) { errno = EINVAL; }
int main() {
// Disable VS2005's parameter checking aborts
_set_invalid_parameter_handler(VS2005_CRT_invalidParamHandler);
// Disable message box assertions
_CrtSetReportMode(_CRT_ASSERT, 0);
...
}
I went back and read more of the older discussion. And I think your
position is that you just don't want to force another compiler on
people, but aren't developers used to this? And if the Express Edition
(free version) is the target, there is no monetary reason to avoid the
upgrade. And as others have said, a VS2005 version of python is faster.
For reference, http://msdn2.microsoft.com/en-us/library/ms235497.aspx
contains the list of CRT breakages according to MSFT.
--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
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] Python 2.4 extensions require VC 7.1?
Scott Dial wrote: For fopen(3), you are right. For signal(3), VS2005 is in clear violation with ISO C I'm nobody but I don't find your argument compelling. I suggest you go read: http://msdn2.microsoft.com/en-us/library/ksazx244.aspx In short, you can tell the CRT to do whatever you like when the parameters are invalid, including returning EINVAL. Sure, I can *make* the library conform to C 99. I could also write my own C library entirely to achieve that effect. The fact remains that VS 2005 violates standard C where VS 2003 and earlier did not: A conforming program will abort, instead of completing successfully. I went back and read more of the older discussion. And I think your position is that you just don't want to force another compiler on people, That also, yes. but aren't developers used to this? They can manage, sure, nobody will get injured. However, since somebody will be unhappy no matter what I do, I do what makes most people happy, i.e. no change. Also, I'm really upset by Microsoft's attitude towards their C compiler. They shouldn't have broken the C library like that, and they shouldn't have taken the VS Express 2003 release off the net without any prior warning. For reference, http://msdn2.microsoft.com/en-us/library/ms235497.aspx contains the list of CRT breakages according to MSFT. Unfortunately, they don't list the specific breakage that the parameter validation causes. They don't even document the effect of parameter validation on their signal() documentation: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_CRT_signal.asp In any case, I see little chance for a change in the build procedure for Python 2.5. Notice that none of the Python committers have spoken in favour of changing the procedure (and some against). 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] Python 2.4 extensions require VC 7.1?
One reason for not switching to VC 8, which hasn't yet been explicitly mentioned here, is that MinGW does not yet easily support linking to the msvcr80 runtime library. Some C extension modules, for instance those in SciPy, are primarily developed under Linux with GCC and hence are most easily built on Windows with MinGW. If the official Python distribution was linked to msvcr80.dll, many extension modules probably could not be built out of the box on Windows (with MinGW) anymore. The 64bit compiler in VS2005 is pretty handy, though. Regards, Stephan ___ 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] Python 2.4 extensions require VC 7.1?
Op za, 17-06-2006 te 10:25 +0200, schreef Martin v. Löwis: Another reason is that I consider VS 2005 buggy, I hope that some of the breakage that Microsoft has done to the C library is reverted in a future release. VS2005 managed to break compatibility with C89 and C99 in a way that made Python fail to start up, also, it was possible to have the CRT abort just by calling the builtin open with the wrong arguments. There is now a work-around for that breakage, but still, I don't trust that VS 2005 is a good product. Why should a C++ compiler be able to compile C89 and/or C99 code? -- Jan Claeys ___ 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] Python 2.4 extensions require VC 7.1?
Jan Claeys wrote: Op za, 17-06-2006 te 10:25 +0200, schreef Martin v. Löwis: Another reason is that I consider VS 2005 buggy, I hope that some of the breakage that Microsoft has done to the C library is reverted in a future release. VS2005 managed to break compatibility with C89 and C99 in a way that made Python fail to start up, also, it was possible to have the CRT abort just by calling the builtin open with the wrong arguments. There is now a work-around for that breakage, but still, I don't trust that VS 2005 is a good product. Why should a C++ compiler be able to compile C89 and/or C99 code? It shouldn't. It appears you think VC 7.1 is a C++ compiler only; that is not the case. It also offers support for (some sort of) C. 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
[Python-Dev] Python 2.4 extensions require VC 7.1?
A colleague recently posted this message: I'm trying to build a Python extension, and Python 2.4 insists on the MS Visual C++ compiler version 7.1, which is included with the MS VC++ 2003 toolkit. This toolkit is no longer available for download from Microsoft (superseded by the 2005 version), so I'm stuck. This seems sub-optimal. I'm afraid I don't follow the Windows track closely; has this been fixed for 2.5, or should it be reported as a bug? Bill ___ 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] Python 2.4 extensions require VC 7.1?
Bill Janssen [EMAIL PROTECTED] wrote: I'm trying to build a Python extension, and Python 2.4 insists on the MS Visual C++ compiler version 7.1, which is included with the MS VC++ 2003 toolkit. This toolkit is no longer available for download from Microsoft (superseded by the 2005 version), so I'm stuck. This seems sub-optimal. I'm afraid I don't follow the Windows track closely; has this been fixed for 2.5, or should it be reported as a bug? It was discussed before, and the agreement was to use VS 2003 for another cycle (i.e. 2.5). But the fact that VS 2003 is no longer available for download is an important fact, and we might want to rediscuss the issue. Giovanni Bajo ___ 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
