Re: [Python-Dev] 3.1.2 / 2.6.5 maintenance releases?
Ned Deily wrote: > I've recently seen a couple of references to 3.1.2 go by in checkins > which made me wonder whether dates have been proposed yet for updates to > either 3.1 or 2.6. I don't recall seeing any and I didn't see any > references in the PEPs. Some advance warning would be nice. I assume > that some critical problem could trigger planning for an update on short > notice; is there a time-limit trigger as well? Barry was once proposing time-based releases; this idea didn't really catch on. It's the release manager who decides when the next bug fix release will be made, often in response to developers asking for one. 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
Re: [Python-Dev] 3.1.2 / 2.6.5 maintenance releases?
Ned Deily acm.org> writes: > > I've recently seen a couple of references to 3.1.2 go by in checkins > which made me wonder whether dates have been proposed yet for updates to > either 3.1 or 2.6. I don't recall seeing any and I didn't see any > references in the PEPs. Some advance warning would be nice. There are a couple of release blockers right now. Once they are fixed or deferred, I think it would be nice to have a 3.1.2. Why do you need "some advance warning" though? ___ 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] 3.1.2 / 2.6.5 maintenance releases?
Antoine Pitrou wrote: > Ned Deily acm.org> writes: >> I've recently seen a couple of references to 3.1.2 go by in >> checkins which made me wonder whether dates have been proposed yet >> for updates to either 3.1 or 2.6. I don't recall seeing any and I >> didn't see any references in the PEPs. Some advance warning would >> be nice. > > There are a couple of release blockers right now. Once they are fixed > or deferred, I think it would be nice to have a 3.1.2. Why do you > need "some advance warning" though? Advance warning does allow interested users that would consider upgrading to schedule time for testing before the maintenance release comes out. This is particularly useful in helping to make a 1-week RC period effective in picking up issues that might otherwise lead to a brown paper bag release to fix major issues that slipped through our own automated test coverage. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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] 3.1.2 / 2.6.5 maintenance releases?
In article <[email protected]>, Nick Coghlan wrote: > Antoine Pitrou wrote: > > Ned Deily acm.org> writes: > >> I've recently seen a couple of references to 3.1.2 go by in > >> checkins which made me wonder whether dates have been proposed yet > >> for updates to either 3.1 or 2.6. I don't recall seeing any and I > >> didn't see any references in the PEPs. Some advance warning would > >> be nice. > > There are a couple of release blockers right now. Once they are fixed > > or deferred, I think it would be nice to have a 3.1.2. Why do you > > need "some advance warning" though? > > Advance warning does allow interested users that would consider > upgrading to schedule time for testing before the maintenance release > comes out. This is particularly useful in helping to make a 1-week RC > period effective in picking up issues that might otherwise lead to a > brown paper bag release to fix major issues that slipped through our own > automated test coverage. That. and resource contention: there are always potential fixes in the pipeline that could or should be bumped in priority if one knows there is a code cutoff approaching. -- Ned Deily, [email protected] ___ 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] Enhancing the shutil module
Hello, For 2.7/3.2, I am in the process of removing modules in Distutils that can be replaced by calls to existing functions in stdlib. For instance, "dir_util" and "file_util" (old modules from the Python 1.x era) are going away in favor of calls to shutil (and os), so the Distutils package gets lighter. Another module I would like to move away from Distutils is "archive_util". It contains helpers to build archives, whether they are zip or tar files. I propose to move those useful functions into shutil, as this seems the most logical place. I also propose to maintain this "shutil" module for now on (no one is declared as a maintainer in maintainers.rst) since Distutils will become a heavy user of its functions. Any objections/opinions ? Regards, Tarek -- Tarek Ziadé | http://ziade.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] Enhancing the shutil module
On 17/01/2010 19:51, Tarek Ziadé wrote: Hello, For 2.7/3.2, I am in the process of removing modules in Distutils that can be replaced by calls to existing functions in stdlib. For instance, "dir_util" and "file_util" (old modules from the Python 1.x era) are going away in favor of calls to shutil (and os), so the Distutils package gets lighter. Another module I would like to move away from Distutils is "archive_util". It contains helpers to build archives, whether they are zip or tar files. I propose to move those useful functions into shutil, as this seems the most logical place. I also propose to maintain this "shutil" module for now on (no one is declared as a maintainer in maintainers.rst) since Distutils will become a heavy user of its functions. Any objections/opinions ? Regards, Tarek I think it's a great idea. :-) Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] Enhancing the shutil module
On Sun, Jan 17, 2010 at 11:51, Tarek Ziadé wrote: > Hello, > > For 2.7/3.2, I am in the process of removing modules in Distutils that > can be replaced by calls to existing functions in stdlib. For > instance, "dir_util" and "file_util" (old modules from the Python 1.x > era) are going away in favor of calls to shutil (and os), so the > Distutils package gets lighter. > > Another module I would like to move away from Distutils is > "archive_util". It contains helpers to build archives, whether they > are zip or tar files. I propose to move those useful functions into > shutil, as this seems the most logical place. > If it's archive-agnostic then shutil is probably the best place. > > I also propose to maintain this "shutil" module for now on (no one is > declared as a maintainer in maintainers.rst) since Distutils will > become a heavy user of its functions. > > Great! > Any objections/opinions ? > No objections from me. -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
Re: [Python-Dev] Enhancing the shutil module
Tarek Ziadé gmail.com> writes: > > Another module I would like to move away from Distutils is > "archive_util". It contains helpers to build archives, whether they > are zip or tar files. I propose to move those useful functions into > shutil, as this seems the most logical place. Are these functions portable? Do they rely on external programs? > I also propose to maintain this "shutil" module for now on (no one is > declared as a maintainer in maintainers.rst) since Distutils will > become a heavy user of its functions. It's ok for me. Regards Antoine. ___ 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] Enhancing the shutil module
On Sun, Jan 17, 2010 at 8:55 PM, Brett Cannon wrote: > > > On Sun, Jan 17, 2010 at 11:51, Tarek Ziadé wrote: >> >> Hello, >> >> For 2.7/3.2, I am in the process of removing modules in Distutils that >> can be replaced by calls to existing functions in stdlib. For >> instance, "dir_util" and "file_util" (old modules from the Python 1.x >> era) are going away in favor of calls to shutil (and os), so the >> Distutils package gets lighter. >> >> Another module I would like to move away from Distutils is >> "archive_util". It contains helpers to build archives, whether they >> are zip or tar files. I propose to move those useful functions into >> shutil, as this seems the most logical place. > > If it's archive-agnostic then shutil is probably the best place. In more details: It allows the creation of gzip, bzip2, tar and zip files through a single API. There's a registry of supported formats and the API is driven by a format identifier. To do the work it uses stdlib's compression modules. Although it tries the "zip" system command as a fallback if the "zipfile" module is not present. (notice that I've removed the support of "compress" (.Z) some time ago) Regards Tarek -- Tarek Ziadé | http://ziade.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] Enhancing the shutil module
On 17/01/2010 20:04, Antoine Pitrou wrote: Tarek Ziadé gmail.com> writes: Another module I would like to move away from Distutils is "archive_util". It contains helpers to build archives, whether they are zip or tar files. I propose to move those useful functions into shutil, as this seems the most logical place. Are these functions portable? Do they rely on external programs? I believe that part of the work that Tarek has been doing has been to make these distutils commands use the Python standard library and not depend on external programs. In which case they seem like *excellent* additions to the shutil module. Of course Tarek can speak for himself... Michael I also propose to maintain this "shutil" module for now on (no one is declared as a maintainer in maintainers.rst) since Distutils will become a heavy user of its functions. It's ok for me. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] Enhancing the shutil module
On Sun, Jan 17, 2010 at 9:15 PM, Michael Foord wrote: [..] >> Are these functions portable? Do they rely on external programs? >> >> > > I believe that part of the work that Tarek has been doing has been to make > these distutils commands use the Python standard library and not depend on > external programs. In which case they seem like *excellent* additions to the > shutil module. yes, in the past the "tar" files where created using the "tar" command but this has been changed. For a while now, they are portable and they use stdlib code only. A recent addition is to be able to define user/group permissions in the tar files, thanks to Lars' work in the tarfile module. There's one remaining external call for "zip" done if the zip module is not found, but I am happy to remove it and throw an exception if it's not found, and keep the external "zip" call on Distutils side, so shutil stays 100% stdlib-powered. > Of course Tarek can speak for himself... Thanks for explaining it ! :) Regards Tarek -- Tarek Ziadé | http://ziade.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] Enhancing the shutil module
On 1/17/2010 12:09 PM, Tarek Ziadé wrote: On Sun, Jan 17, 2010 at 8:55 PM, Brett Cannon wrote: > On Sun, Jan 17, 2010 at 11:51, Tarek Ziadé wrote: >> Another module I would like to move away from Distutils is >> "archive_util". It contains helpers to build archives, whether they >> are zip or tar files. I propose to move those useful functions into >> shutil, as this seems the most logical place. > If it's archive-agnostic then shutil is probably the best place. In more details: It allows the creation of gzip, bzip2, tar and zip files through a single API. There's a registry of supported formats and the API is driven by a format identifier. Will it also allow decompression of the said archive types? Distribute has some utility code to handle zip/tar archives. So does PyPM. This is because the `tarfile` and `zipfile` modules do not "just work" due to several issues. See http://gist.github.com/279606 Take note of the following in the above code: 1) _ensure_read_write_access 2) *File.is_valid 3) ZippedFile.extract ... issue 6510 4) ZippedFile.extract ... issue 6609 5) TarredFile.extract ... issue 6584 6) The way unpack() detects the unpacked directory. -srid ___ 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] Enhancing the shutil module
On Sun, Jan 17, 2010 at 10:50 PM, Sridhar Ratnakumar wrote: [..] > Will it also allow decompression of the said archive types? No but it would make sense having this one as well. Distribute/Setuptools' "unpack_archive" (used by easy_install) was implemented using the same principle as Distutils' "make_archive". I can add it as well while I am at it : it has been successfully used for years by easy_install. > Distribute has > some utility code to handle zip/tar archives. So does PyPM. This is because > the `tarfile` and `zipfile` modules do not "just work" due to several > issues. > > See http://gist.github.com/279606 > > Take note of the following in the above code: > > 1) _ensure_read_write_access > 2) *File.is_valid > 3) ZippedFile.extract ... issue 6510 > 4) ZippedFile.extract ... issue 6609 > 5) TarredFile.extract ... issue 6584 Looks like some of these are already fixed (I just looked quickly in the bug tracker though) If its not already done and pending, it would be great if you could refactor your fixes into patches for the remaining issues for each one of those modules Regards Tarek -- Tarek Ziadé | http://ziade.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] 3.1.2 / 2.6.5 maintenance releases?
On Jan 17, 2010, at 4:21 AM, Martin v. Löwis wrote: > Barry was once proposing time-based releases; this idea didn't really > catch on. I'm still a proponent of this, but it doesn't seem like there's enough support for it. > It's the release manager who decides when the next bug fix release will > be made, often in response to developers asking for one. I'm happy to make a 2.6.5 release whenever it makes sense. -Barry ___ 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
