Re: [Python-Dev] Backports of standard library modules
:) is that, when I go to the downloads page for Python 2.3, in addition to downloading Python, I could download all the compatible libraries which were included in later versions as a single installable file. When 2.6 comes out, this extras package would be upgraded to include any new modules in 2.6. Not a lot of fun for people who live on the bleeding edge, but very useful for people who are stuck with an older version for political or other reasons. If you, or someone else, is willing to do the work to do this, I don't think anyone would mind. There is (as Martin also stated) zero chance that I will do this additional work. It scratches no itches for me, and has the potential to add an enormous amount to my workload of doing a new release. 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] Backports of standard library modules
Patrick Maupin schrieb: Although it is often quite easy to find and download a module for use with a prior version of Python, it would be really convenient if all of these modules were bundled up together and available as a single download, especially when it comes to Windows users and extension modules. I don't know how precisely you imagine this to happen: there is clearly zero chance that a future 2.5.x release (say, 2.5.2) will include modules that are about to appear with 2.6 only. If you think of an independent release: who should produce it? I would not expect that any of the current release people are willing to take more load (I know that I wouldn't); so it clearly needs more volunteers. Given the past experience with such proposals (e.g. creation of a Jumbo distribution), I'm skeptical that volunteers will materialize (unless, of course, you are volunteering). If it is indeed you who would volunteer, I'd suggest that you don't have to go through a PEP process. Instead, just do it: bundle the modules that you want to see in earlier Python versions, and publish it. If you want to see it appear on python.org, that could certainly be arranged. 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] Backports of standard library modules
[EMAIL PROTECTED] schrieb: This does raise an interesting question, though, since I'm about to get into PEP authorship myself. Have I missed an official way to propose alternatives or resurrect a languishing PEP? See PEP 1. The PEP champion is obliged to integrate feedback into the PEP, to avoid repeated discussions. If the PEP champion is unresponsive, I think that ownership should be transferred to a new champion, although PEP 1 doesn't explain how this should happen. Historically, champions who lost interest were always willing to transfer ownership. If the champion merely records negative feedback without actually changing the proposal, you can come up with a counter-proposal, as a separate PEP. For example, I wrote PEP 244 to counter PEP 236. Clearly, one of them will get rejected eventually in favor of the other. 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] Backports of standard library modules
Please forgive me if this has already been discussed -- I only recently started paying any attention to this list. Many versions of python include new standard library modules that could (or often do already) work fine with previous versions. Some of the modules are brand-new, written explicitly for the standard library, and others are preexisting modules that, by community consensus, are added to the library. It seems that once a new library module is added, if it doesn't rely heavily on new core language features, it should also be added for previous versions. Obviously, it doesn't make sense to re-release an old version of Python just because a new library is available (or even to include the new library in the old version), but it might make sense to have a separate package of extras or backported modules that is re-released for prior versions whenever a new (compatible) module is added to the standard library. Although it is often quite easy to find and download a module for use with a prior version of Python, it would be really convenient if all of these modules were bundled up together and available as a single download, especially when it comes to Windows users and extension modules. If this seems useful to others, I could try to start a PEP on how the process would work (but since I'm fairly new, it would be great if someone could help out a bit by validating my verbiage against some of the process requirements). Regards, Pat ___ 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] Backports of standard library modules
On 3/11/07, Patrick Maupin [EMAIL PROTECTED] wrote: Please forgive me if this has already been discussed -- I only recently started paying any attention to this list. Many versions of python include new standard library modules that could (or often do already) work fine with previous versions. Some of the modules are brand-new, written explicitly for the standard library, and others are preexisting modules that, by community consensus, are added to the library. It seems that once a new library module is added, if it doesn't rely heavily on new core language features, it should also be added for previous versions. Obviously, it doesn't make sense to re-release an old version of Python just because a new library is available (or even to include the new library in the old version), but it might make sense to have a separate package of extras or backported modules that is re-released for prior versions whenever a new (compatible) module is added to the standard library. Although it is often quite easy to find and download a module for use with a prior version of Python, it would be really convenient if all of these modules were bundled up together and available as a single download, especially when it comes to Windows users and extension modules. A problem with doing this is whether this will put any extra burden on python-dev. It's fine if people want to pull out of the stdlib, package them, and do that work, but in no way should we have to maintain version compatibility or worry about backporting fixes once the package is released. I would personally rather have an informal package done to completely avoid these issues. That way no one feels obliged to keep doing this after every release. -Brett ___ 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] Backports of standard library modules
On 11 Mar, 10:32 pm, [EMAIL PROTECTED] wrote: If this seems useful to others, I could try to start a PEP on how the process would work (but since I'm fairly new, it would be great if someone could help out a bit by validating my verbiage against some of the process requirements). Isn't this PEP 297? This does raise an interesting question, though, since I'm about to get into PEP authorship myself. Have I missed an official way to propose alternatives or resurrect a languishing PEP? I'd like very much to propose to obsolete PEP 355 with twisted's FilePath object that I've previously discussed, but ... does that mean adding text to 355? writing a new PEP and referencing it? Also, the language/library evolution PEP I would like to write is basically an expanded version of PEP 5, but that is apparently moribund (and not followed, according to MvL). Above all, how can I help to motivate timely yea-or-nay decisions from the BDFL or his chosen consultants? PEP 1 seems to defer all of these questions to emailing the PEP editor; is that really the best way to go? ___ 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] Backports of standard library modules
On 3/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 11 Mar, 10:32 pm, [EMAIL PROTECTED] wrote: If this seems useful to others, I could try to start a PEP on how the process would work (but since I'm fairly new, it would be great if someone could help out a bit by validating my verbiage against some of the process requirements). Isn't this PEP 297? I'd say it's almost a subset of PEP 297. This does raise an interesting question, though, since I'm about to get into PEP authorship myself. Have I missed an official way to propose alternatives or resurrect a languishing PEP? I'd like very much to propose to obsolete PEP 355 with twisted's FilePath object that I've previously discussed, but ... does that mean adding text to 355? writing a new PEP and referencing it? The introduction to PEP 342 would be a good starting point; it was built on a number of prior PEPs. Above all, how can I help to motivate timely yea-or-nay decisions from the BDFL or his chosen consultants? PEP 1 seems to defer all of these questions to emailing the PEP editor; is that really the best way to go? From my own experience, the best way is tight, focused discussion that avoids or short-circuits interminable bikeshedding threads; see Ben North's exemplary work on the (ultimately rejected) PEP on dynamic attribute access syntax from February 2007 (http://mail.python.org/pipermail/python-dev/2007-February/, search for his name). Collin Winter ___ 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] Backports of standard library modules
On 3/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Isn't this PEP 297? Thanks for pointing that out. I looked for a relevant PEP, but didn't notice this one. I think this is complementary, but (if I am reading it correctly) it is not exactly the same. The alternate search path is a necessary part of what I am suggesting, but the meat of my proposal (which Brett correctly discerned would require ongoing effort :) is that, when I go to the downloads page for Python 2.3, in addition to downloading Python, I could download all the compatible libraries which were included in later versions as a single installable file. When 2.6 comes out, this extras package would be upgraded to include any new modules in 2.6. Not a lot of fun for people who live on the bleeding edge, but very useful for people who are stuck with an older version for political or other reasons. Regards, Pat ___ 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
