Re: [Python-Dev] Python and the Linux Standard Base (LSB)
Actually, I meant that (among other things) it should be clarified that it's alright to e.g. put .pyc and data files inside Python library directories, and NOT okay to split them up. Phillip, Just to be clear: I understand you are not in favour of re-packaging data from python projects (projects in the distutils sense), separately and I strongly agree with this view. Are you opposed to developers choosing to *not* bundle data as python package data ? How much, if any, of the setuptools / distutils conventions do you think could sensibly peculate up to the LSB ? There are a couple of cases in ubuntu/debian (as of 6.10 edgy) that I think are worth considering: python2.4 profile (pstats) etc, was removed due to licensing issues rather than FHS. Should not be an issue for python2.5 but what, in general, can a vendor do except break python if their licensing policy cant accommodate all of pythons batteries ? python2.4 distutils is excluded by default. This totally blows in my view but I appreciate this one is a minefield of vendor packaging politics. It has to be legitimate for Python / setuptools too provide packaging infrastructure and conventions that are viable on more than linux. Is it unreasonable for a particular vendor to decide that, on their platform, the will disable Python's packaging conventions ? Is there any way to keep the peace on this one ? Cheers, Robin On 27/11/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 02:38 PM 11/27/2006 +0100, Jan Matejek wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip J. Eby napsal(a): Just a suggestion, but one issue that I think needs addressing is the FHS language that leads some Linux distros to believe that they should change Python's normal installation layout (sometimes in bizarre ways) (...) Other vendors apparently also patch Python in various ways to support their FHS-based theories of how Python should install files. +1 on that. There should be a clear (and clearly presented) idea of how Python is supposed to be laid out in the distribution-provided /usr hierarchy. And it would be nice if this idea complied to FHS. It would also be nice if somebody finally admitted the existence of /usr/lib64 and made Python aware of it ;e) Actually, I meant that (among other things) it should be clarified that it's alright to e.g. put .pyc and data files inside Python library directories, and NOT okay to split them up. ___ 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/robinbryce%40gmail.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] Python and the Linux Standard Base (LSB)
On Tuesday 28 November 2006 23:19, Robin Bryce wrote: python2.4 profile (pstats) etc, was removed due to licensing issues rather than FHS. Should not be an issue for python2.5 but what, in general, can a vendor do except break python if their licensing policy cant accommodate all of pythons batteries ? That's a historical case, and as far as I know, unique. I can't imagine we'd accept any new standard library contributions (no matter how compelling) without the proper licensing work being done. python2.4 distutils is excluded by default. This totally blows in my view but I appreciate this one is a minefield of vendor packaging politics. It has to be legitimate for Python / setuptools too provide packaging infrastructure and conventions that are viable on more than linux. Is it unreasonable for a particular vendor to decide that, on their platform, the will disable Python's packaging conventions ? Is there any way to keep the peace on this one ? I still have no idea why this was one - I was also one of the people who jumped up and down asking Debian/Ubuntu to fix this idiotic decision. Personally, I consider any distributions that break the standard library into non-required pieces to be shipping a _broken_ Python. As someone who writes and releases software, this is a complete pain. I can't tell you how many times through the years I'd get user complaints because they didn't get distutils installed as part of the standard library. (The only other packaging thing like this that I'm aware of is python-minimal in Ubuntu. This is done for installation purposes and wacky dependency issues that occur when a fair chunk of the O/S is actually written in Python. It's worth noting that the entirety of the Python stdlib is a required package, so it doesn't cause issues.) Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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 and the Linux Standard Base (LSB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 28, 2006, at 8:53 AM, Anthony Baxter wrote: (The only other packaging thing like this that I'm aware of is python-minimal in Ubuntu. This is done for installation purposes and wacky dependency issues that occur when a fair chunk of the O/S is actually written in Python. It's worth noting that the entirety of the Python stdlib is a required package, so it doesn't cause issues.) There's a related issue that may or may not be in scope for this thread. For distros like Gentoo or Ubuntu that rely heavily on their own system Python for the OS to work properly, I'm quite loathe to install Cheeseshop packages into the system site-packages. I've had Gentoo break occasionally when I did this for example (though I don't remember the details now), so I always end up installing my own /usr/ local/bin/python and installing my 3rd party packages into there. Even though site-packages is last on sys.path, installing 3rd party packages can still break the OS if the system itself installs incompatible versions of such packages into its site-packages. Mailman's philosophy is to install the 3rd party packages it requires into its own 'pythonlib' directory that gets put first on sys.path. It does this for several reasons: I want to be able to override stdlib packages such as email with newer versions, I don't want to have to mess around at all with the system's site-packages, and I don't want updates to the system Python to break my application. I question whether a distro built on Python can even afford to allow 3rd party packages to be installed in their system's site-packages. Maybe Python needs to extend its system-centric view of site-packages with an application-centric and/or user-centric view of extensions? The only reason I can think of for Mailman /not/ using its own pythonlib is to save on disk space, and really, who cares about that any more? I submit that most applications of any size will have way more application data than duplicated Python libraries. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRWxVQ3EjvBPtnXfVAQIuMAQAkciyaHCwLnkN+8GwbhUro+vJuna+JObP AZaNzPKYABITqu5fKPl3aEvQz+9pNUvjM2c/q5p1m/9n34ZBURfgpHa3yk7QcbW0 sud8utdW6wMHMuWVw/1lQNaZ2GeJz9E4CgO93btfgiMLFIrcnBxr6uw5NqTrMwOc 4iIupbjYfUg= =Nxff -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] Distribution tools: What I would like to see
Talin schrieb: To that extent, it can be useful sometimes to have someone who is in the process of learning how to use the system, and who is willing to carefully analyze and write down their own experiences while doing so. I readily agree that the documentation can be improved, and applaud efforts to do so. And I have no doubts that distutils is difficult to learn for a beginner. In Talin's remarks, there was also the suggestion that distutils is in need of some serious refactoring. It is such remarks that get me started: it seems useless to me to make such a statement if they are not accompanied with concrete proposals what specifically to change. It also gets me upset because it suggests that all prior contributors weren't serious. 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 and the Linux Standard Base (LSB)
Robin Bryce schrieb: python2.4 profile (pstats) etc, was removed due to licensing issues rather than FHS. Should not be an issue for python2.5 but what, in general, can a vendor do except break python if their licensing policy cant accommodate all of pythons batteries ? If some vendor has a valid concern about the licensing of a certain piece of Python, they should bring that up while the LSB is being defined. python2.4 distutils is excluded by default. This totally blows in my view but I appreciate this one is a minefield of vendor packaging politics. It has to be legitimate for Python / setuptools too provide packaging infrastructure and conventions that are viable on more than linux. Again, that a decision for the LSB standard to make. If LSB defines that distutils is part of LSB (notice the *If*: this is all theoretical; the LSB doesn't yet define anything for Python), then each vendor can still chose to include distutils or not, if they don't, they wouldn't comply to that version of LSB. So it is *always* their choice what standard to follow. OTOH, certain customers demand LSB conformance, so a vendor that choses not to follow LSB may lose customers. I personally agree that Linux standards should specify a standard layout for a Python installation, and that it should be the one that make install generates (perhaps after make install is adjusted). Whether or not it is the *LSB* that needs to specify that, I don't know, because the LSB does not specify a file system layout. Instead, it incorporates the FHS - which might be the right place to define the layout of a Python installation. For the LSB, it's more import that import httplib gives you something working, no matter where httplib.py comes from (or whether it comes from httplib.py at all). 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] Distribution tools: What I would like to see
Martin v. Löwis wrote: Talin schrieb: To that extent, it can be useful sometimes to have someone who is in the process of learning how to use the system, and who is willing to carefully analyze and write down their own experiences while doing so. I readily agree that the documentation can be improved, and applaud efforts to do so. And I have no doubts that distutils is difficult to learn for a beginner. In Talin's remarks, there was also the suggestion that distutils is in need of some serious refactoring. It is such remarks that get me started: it seems useless to me to make such a statement if they are not accompanied with concrete proposals what specifically to change. It also gets me upset because it suggests that all prior contributors weren't serious. I'm sorry if I implied that distutils was 'misdesigned', that wasn't what I meant. Refactoring is usually desirable when a body of code has accumulated a lot of additional baggage as a result of maintenance and feature additions, accompanied by the observation that if the baggage had been present when the system was originally created, the design of the system would have been substantially different. Refactoring is merely an attempt to discover what that original design might have been, if the requirements had been known at the time. What I was reacting to, I think, is that it seemed like in some ways the 'diffness' of setuptools wasn't just in the documentation, but in the code itself, and if both setuptools and distutils had been co-developed, then distutils might have been someone different as a result. Also, I admit that some of this is hearsay, so maybe I should just back off on this one. 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 and the Linux Standard Base (LSB)
On 11/28/06, Barry Warsaw [EMAIL PROTECTED] wrote: For distros like Gentoo or Ubuntu that rely heavily on their own system Python for the OS to work properly, I'm quite loathe to install Cheeseshop packages into the system site-packages. I've had Gentoo break occasionally when I did this for example (though I don't remember the details now), so I always end up installing my own /usr/ local/bin/python and installing my 3rd party packages into there. Even though site-packages is last on sys.path, installing 3rd party packages can still break the OS if the system itself installs incompatible versions of such packages into its site-packages. One wishes distro vendors would install a separate copy of Python for their internal OS stuff so that broken-library or version issues wouldn't affect the system. That would be worth putting into the standard. -- Mike Orr [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 and the Linux Standard Base (LSB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 28, 2006, at 2:41 PM, Mike Orr wrote: On 11/28/06, Barry Warsaw [EMAIL PROTECTED] wrote: For distros like Gentoo or Ubuntu that rely heavily on their own system Python for the OS to work properly, I'm quite loathe to install Cheeseshop packages into the system site-packages. I've had Gentoo break occasionally when I did this for example (though I don't remember the details now), so I always end up installing my own /usr/ local/bin/python and installing my 3rd party packages into there. Even though site-packages is last on sys.path, installing 3rd party packages can still break the OS if the system itself installs incompatible versions of such packages into its site-packages. One wishes distro vendors would install a separate copy of Python for their internal OS stuff so that broken-library or version issues wouldn't affect the system. That would be worth putting into the standard. Agreed. But that would just eliminate one potential source of application conflict (defining the OS itself as just another application). - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRWyYEnEjvBPtnXfVAQJCKQP7BXVOYUIvbEBgFK7nWHieBqRGXzohhKNZ SN5qV4P6uZGnCtjp1Z4W8U82X8TH+X3Ovx02mS+GN+nrlyF7AVhDr/mSLXI90Kan 1dqOhAIz5rBeT03/k0SpAPSiBhonl4zF4ZmezGaz3lif2CjsH6PT9153Mv7wXb1N ut2QIhXnejA= =jhbd -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] ctypes and powerpc
Ronald Oussoren schrieb: On Friday, November 24, 2006, at 08:21PM, Thomas Heller [EMAIL PROTECTED] wrote: I'd like to ask for help with an issue which I do not know how to solve. Please see this bug http://python.org/sf/1563807 ctypes built with GCC on AIX 5.3 fails with ld ffi error Apparently this is a powerpc machine, ctypes builds but cannot be imported because of undefined symbols like 'ffi_call', 'ffi_prep_closure'. These symbols are defined in file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. The whole contents of this file is enclosed within a #ifdef __ppc__ ... #endif block. IIRC, this block has been added by Ronald for the Mac universal build. Now, it seems that on the AIX machine the __ppc__ symbols is not defined; removing the #ifdef/#endif makes the built successful. The defines were indeed added for the universal build and I completely overlooked the fact that ffi_darwin.c is also used for AIX. One way to fix this is #if ! (defined(__APPLE__) !defined(__ppc__)) ... #endif That is, compile the file unless __APPLE__ is defined but __ppc__ isn't. This more clearly documents the intent. Yes, this makes the most sense. I've taken this approach. Thanks, Thomas ___ 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 and the Linux Standard Base (LSB)
At 01:05 PM 11/28/2006 -0800, Guido van Rossum wrote: On 11/28/06, Barry Warsaw [EMAIL PROTECTED] wrote: There's a related issue that may or may not be in scope for this thread. For distros like Gentoo or Ubuntu that rely heavily on their own system Python for the OS to work properly, I'm quite loathe to install Cheeseshop packages into the system site-packages. I wonder if would help if we were to add a vendor-packages directory where distros can put their own selection of 3rd party stuff they depend on, to be searched before site-packages, and a command-line switch that ignores site-package but still searches vendor-package. (-S would almost do it but probably suppresses too much.) They could also use -S and then explicitly insert the vendor-packages directory into sys.path at the beginning of their scripts. And a .pth in site-packages could add vendor-packages at the *end* of sys.path, so that scripts not using -S would pick it up. This would be backward compatible except for the vendor scripts that want to use this approach. ___ 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 and the Linux Standard Base (LSB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 28, 2006, at 4:05 PM, Guido van Rossum wrote: On 11/28/06, Barry Warsaw [EMAIL PROTECTED] wrote: There's a related issue that may or may not be in scope for this thread. For distros like Gentoo or Ubuntu that rely heavily on their own system Python for the OS to work properly, I'm quite loathe to install Cheeseshop packages into the system site-packages. I wonder if would help if we were to add a vendor-packages directory where distros can put their own selection of 3rd party stuff they depend on, to be searched before site-packages, and a command-line switch that ignores site-package but still searches vendor-package. (-S would almost do it but probably suppresses too much.) I keep thinking I'd like to treat the OS as just another application, so that there's nothing special about it and the same infrastructure could be used for other applications with lots of entry level scripts. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRWzKAHEjvBPtnXfVAQK9AAQAsJS2Ag9yBO+dLGiZdJlaWAj64zWcd9oi zqaE95/y53iXBvMBynglROApDEdOsnv/1/XSx1+2gZVIkuFvHLplbqZWVCsZ56r+ nAcTzFXsM2zPBSECKWuSfxBUILKalRdaIXKOUjgd0iZTrCbt3EeTmZlxMTKq9sGU 1Scr8sHSpIE= =rNjl -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] Python and the Linux Standard Base (LSB)
I question whether a distro built on Python can even afford to allow 3rd party packages to be installed in their system's site-packages. Maybe Python needs to extend its system-centric view of site-packages with an application-centric and/or user-centric view of extensions? Agreed, I do not think that should be allowed. A system site-packages directory for a python install is a convenient bandaid but not a good idea for real world deployment of anything third party. It suffers from the same classic DLL Hell problem that windows has suffered with for eons with applications all including the same DLLs and putting them in the system directory. I'm fine if an OS distro wants to use site-packages for things the OS depends on in its use of python. I'm fine with the OS offering its own packages (debs or rpms or whatnot) that install additional python libraries under site-packages for use system wide or to satisfy dependancies from other system packages. Those are all managed properly for compatibility at the OS distro level. Whats bad is for third party (non-os-distro packaged) applications to touch site-packages. -greg ___ 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 and the Linux Standard Base (LSB)
On 11:45 pm, [EMAIL PROTECTED] wrote: I keep thinking I'd like to treat the OS as just another application, so that there's nothing special about it and the same infrastructure could be used for other applications with lots of entry level scripts. I agree. The motivation here is that the OS application keeps itself separate so that incorrect changes to configuration or installation of incompatible versions of dependencies don't break it. There are other applications which also don't want to break. This is a general problem with Python, one that should be solved with a comprehensive parallel installation or linker which explicitly describes dependencies and allows for different versions of packages. I definitely don't think that this sort of problem should be solved during the *standardization* process - that should just describe the existing conventions for packaging Python stuff, and the OS can insulate itself in terms of that. Definitely it shouldn't be changed as part of standardization unless the distributors are asking for it loudly. ___ 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 and the Linux Standard Base (LSB)
At 06:41 PM 11/28/2006 -0500, Barry Warsaw wrote: On Nov 28, 2006, at 4:19 PM, Phillip J. Eby wrote: At 01:05 PM 11/28/2006 -0800, Guido van Rossum wrote: On 11/28/06, Barry Warsaw [EMAIL PROTECTED] wrote: There's a related issue that may or may not be in scope for this thread. For distros like Gentoo or Ubuntu that rely heavily on their own system Python for the OS to work properly, I'm quite loathe to install Cheeseshop packages into the system site-packages. I wonder if would help if we were to add a vendor-packages directory where distros can put their own selection of 3rd party stuff they depend on, to be searched before site-packages, and a command-line switch that ignores site-package but still searches vendor-package. (-S would almost do it but probably suppresses too much.) They could also use -S and then explicitly insert the vendor- packages directory into sys.path at the beginning of their scripts. Possibly, but stuff like this can be a pain because your dependent app must build in the infrastructure itself to get the right paths set up for its scripts. ... Maybe there's no better way of doing this and applications are best left to their own devices. But in the back of my mind, I keep thinking there should be a better way. ;) Well, you can always use setuptools, which generates script wrappers that import the desired module and call a function, after first setting up sys.path. :) ___ 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 and the Linux Standard Base (LSB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 28, 2006, at 4:19 PM, Phillip J. Eby wrote: At 01:05 PM 11/28/2006 -0800, Guido van Rossum wrote: On 11/28/06, Barry Warsaw [EMAIL PROTECTED] wrote: There's a related issue that may or may not be in scope for this thread. For distros like Gentoo or Ubuntu that rely heavily on their own system Python for the OS to work properly, I'm quite loathe to install Cheeseshop packages into the system site-packages. I wonder if would help if we were to add a vendor-packages directory where distros can put their own selection of 3rd party stuff they depend on, to be searched before site-packages, and a command-line switch that ignores site-package but still searches vendor-package. (-S would almost do it but probably suppresses too much.) They could also use -S and then explicitly insert the vendor- packages directory into sys.path at the beginning of their scripts. Possibly, but stuff like this can be a pain because your dependent app must build in the infrastructure itself to get the right paths set up for its scripts. An approach I've used in the past is to put a paths.py file in the bin directory and force every script to import paths before it imports anything it doesn't want to get from the stdlib (including overrides). paths.py is actually generated though because the user could specify an alternative Python with a configure switch. What I'm moving to now though is a sort of 'shell' or driver script which does that path setup once, then imports a module based on argv [0], sniffing out a main() and then calling that. The trick then of course is that you symlink all the top-level user scripts to this shell. Works fine if all you care about is *nix wink, but it does mean an application with lots of entry-level scripts has to build all this infrastructure itself. Maybe there's no better way of doing this and applications are best left to their own devices. But in the back of my mind, I keep thinking there should be a better way. ;) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRWzJMXEjvBPtnXfVAQJHmAP/UhGUv1Wxt2AzGT08dM9/M0J4pahGnrF3 VwbrdRTF6Jt32iAKAJolrnTE+XlMaTGitYv+mu8v3SgJLWwe+aeJwpg8AdOn5jBL bSjBpE9UeqUSiMhaJmBbx/z5ISv4OioJLX+vzBv6u0yBTYv4uoYZPKoeMcCe6Afw 7e1gIL1WHL4= =scvm -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] Python and the Linux Standard Base (LSB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 28, 2006, at 7:10 PM, Phillip J. Eby wrote: Well, you can always use setuptools, which generates script wrappers that import the desired module and call a function, after first setting up sys.path. :) That's so 21st Century! Where was setuptools back in 1996? :) Seriously though, that does sound cool, and thanks for the tip. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRWzTtXEjvBPtnXfVAQKDwgP+N/nGkHm7e9ZK+DmTEx+gOxPkeQnpKcA2 AHLg9WLJhLHlrxlekftm3F1+YNQv9R6tthRKu6Zgz5fJTPs57MluJ4qAzPapDymT oGX5Y3HxCdaqrw0HWviuJeUr8euN7NIghUAsEbe51pppfbTs80dGnDrDRL4AfXGm 4/C9DW2URkQ= =pt5u -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
