Re: [Python-Dev] Enhancing the shutil module
Tarek Ziadé wrote: > 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. +1 for that approach. These changes all sound like nice additions to shutil, and hooray for every module that gets adopted by an active maintainer :) 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] Enhancing the shutil module
On 18 Jan 2010, at 13:40 , Nick Coghlan wrote: > > Tarek Ziadé wrote: >> 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. > > +1 for that approach. These changes all sound like nice additions to > shutil, and hooray for every module that gets adopted by an active > maintainer :) Isn't it a bit weird to include that to shutil though? shutil advertises itself as "a number of high-level operations on files and collections of files." and from what I understood it was a bunch of shell-type utility functions to easily copy, move or remove files and directories (that's pretty much all there is in it at this time). Wouldn't it make more sense to put those "archive utils" functions/objects in a new module separate from shutil, dealing specifically with cross-archive APIs and linked from the current archive-specific modules (essentially, just take the current archive_util, move it to the toplevel of the stdlib and maybe rename it)? It would also make the module much easier to find when searching through the module listing, I think. ___ 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 Jan 18, 2010, at 8:34 AM, Masklinn wrote: On 18 Jan 2010, at 13:40 , Nick Coghlan wrote: Tarek Ziadé wrote: 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. +1 for that approach. These changes all sound like nice additions to shutil, and hooray for every module that gets adopted by an active maintainer :) Isn't it a bit weird to include that to shutil though? shutil advertises itself as "a number of high-level operations on files and collections of files." and from what I understood it was a bunch of shell-type utility functions to easily copy, move or remove files and directories (that's pretty much all there is in it at this time). Wouldn't it make more sense to put those "archive utils" functions/ objects in a new module separate from shutil, dealing specifically with cross-archive APIs and linked from the current archive-specific modules (essentially, just take the current archive_util, move it to the toplevel of the stdlib and maybe rename it)? It would also make the module much easier to find when searching through the module listing, I think. +1 ___ 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 18/01/2010 13:46, Doug Hellmann wrote: On Jan 18, 2010, at 8:34 AM, Masklinn wrote: On 18 Jan 2010, at 13:40 , Nick Coghlan wrote: Tarek Ziadé wrote: 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. +1 for that approach. These changes all sound like nice additions to shutil, and hooray for every module that gets adopted by an active maintainer :) Isn't it a bit weird to include that to shutil though? shutil advertises itself as "a number of high-level operations on files and collections of files." Well - isn't what's being proposed "a number of high-level operations on files and collections of files." ? and from what I understood it was a bunch of shell-type utility functions like tar and zip? :-) to easily copy, move or remove files and directories (that's pretty much all there is in it at this time). I don't think the additions are out of place prima-facie. Wouldn't it make more sense to put those "archive utils" functions/objects in a new module separate from shutil, dealing specifically with cross-archive APIs and linked from the current archive-specific modules (essentially, just take the current archive_util, move it to the toplevel of the stdlib and maybe rename it)? It would also make the module much easier to find when searching through the module listing, I think. +1 Proliferation of modules is itself a bad thing though. Michael ___ 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 Mon, Jan 18, 2010 at 2:57 PM, Michael Foord wrote: [..] >>> Wouldn't it make more sense to put those "archive utils" >>> functions/objects in a new module separate from shutil, dealing specifically >>> with cross-archive APIs and linked from the current archive-specific modules >>> (essentially, just take the current archive_util, move it to the toplevel of >>> the stdlib and maybe rename it)? It would also make the module much easier >>> to find when searching through the module listing, I think. >> >> +1 >> > > Proliferation of modules is itself a bad thing though. I am with Michael here. I think having this function in shutil is the right place. For the find problem, I think docs.python.org is easy to search now, as long as the shutil module documentation has an good set of examples for this new API. We could even add references in the tarfile, zipfile modules documentation pointing to these examples. 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 18 Jan 2010, at 14:57 , Michael Foord wrote: > > On 18/01/2010 13:46, Doug Hellmann wrote: >> >> On Jan 18, 2010, at 8:34 AM, Masklinn wrote: >> >>> On 18 Jan 2010, at 13:40 , Nick Coghlan wrote: Tarek Ziadé wrote: > 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. +1 for that approach. These changes all sound like nice additions to shutil, and hooray for every module that gets adopted by an active maintainer :) >>> >>> Isn't it a bit weird to include that to shutil though? shutil advertises >>> itself as "a number of high-level operations on files and collections of >>> files." > > Well - isn't what's being proposed "a number of high-level operations on > files and collections of files." ? > Well no those are high-level operations on a very restricted set of file types (archives). >>> and from what I understood it was a bunch of shell-type utility functions > > like tar and zip? :-) > Tar and zip have a module each at this time, so they're considered pretty big. I don't think anybody would consider "mv" big enough to give it a module on its own. >>> Wouldn't it make more sense to put those "archive utils" functions/objects >>> in a new module separate from shutil, dealing specifically with >>> cross-archive APIs and linked from the current archive-specific modules >>> (essentially, just take the current archive_util, move it to the toplevel >>> of the stdlib and maybe rename it)? It would also make the module much >>> easier to find when searching through the module listing, I think. >> >> +1 >> > > Proliferation of modules is itself a bad thing though. Yes, but so is the loss of focus of a module. I hate using that argument, but I fear this would be a step on a slippery slope of making shutil a monster-bag of anything that has to do with inodes, no matter how tenuous or removed the connection is. Plus having this as a toplevel module/package would open the window to moving all archive-related modules within it (in the py4 window), à la xml package without having to move itself. ___ 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 Mon, Jan 18, 2010 at 02:34:14PM +0100, Masklinn wrote: > Isn't it a bit weird to include that to shutil though? shutil advertises > itself as "a number of high-level operations on files and collections of > files." and from what I understood it was a bunch of shell-type utility > functions to easily copy, move or remove files and directories (that's pretty > much all there is in it at this time). > > Wouldn't it make more sense to put those "archive utils" functions/objects in > a new module separate from shutil, dealing specifically with cross-archive > APIs and linked from the current archive-specific modules (essentially, just > take the current archive_util, move it to the toplevel of the stdlib and > maybe rename it)? It would also make the module much easier to find when > searching through the module listing, I think. +1 Oleg. -- Oleg Broytmanhttp://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] Enhancing the shutil module
On Mon, Jan 18, 2010 at 3:56 PM, Masklinn wrote: [..] >> Well - isn't what's being proposed "a number of high-level operations on >> files and collections of files." ? >> > Well no those are high-level operations on a very restricted set of file > types (archives) not really: make_archive/unpack_archive, are also dealing with files and directories. [..] >> Proliferation of modules is itself a bad thing though. > Yes, but so is the loss of focus of a module. I hate using that argument, but > I fear this would be a step on a slippery slope of making shutil a > monster-bag of anything that has to do with inodes, no matter how tenuous or > removed the connection is. > > Plus having this as a toplevel module/package would open the window to moving > all archive-related modules within it (in the py4 window), à la xml package > without having to move itself. I am not sure why this would happen. For instance, shutil is already on the top of the os module since a few major versions IIRC, because it reads and writes files and directories. But it was not moved into the os package (or vice-versa) The shutil module uses APIs to read and write files. So if it works with archives, it's just a specific read/write API that is used, but that doesn't mean tarfile and zipfile might be reunited with shutil imho. If the shutil module is restricted to high-level files and directories manipulation, working with archives is just a target like another I think. But at the end I am 0- to create a new module, because what really matters to me is to take it out of Distutils :) 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 Jan 18, 2010, at 8:34 AM, Masklinn wrote: > On 18 Jan 2010, at 13:40 , Nick Coghlan wrote: >> >> Tarek Ziadé wrote: >>> 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. >> >> +1 for that approach. These changes all sound like nice additions to >> shutil, and hooray for every module that gets adopted by an active >> maintainer :) > > Isn't it a bit weird to include that to shutil though? shutil advertises > itself as "a number of high-level operations on files and collections of > files." and from what I understood it was a bunch of shell-type utility > functions to easily copy, move or remove files and directories (that's pretty > much all there is in it at this time). > > Wouldn't it make more sense to put those "archive utils" functions/objects in > a new module separate from shutil, dealing specifically with cross-archive > APIs and linked from the current archive-specific modules (essentially, just > take the current archive_util, move it to the toplevel of the stdlib and > maybe rename it)? It would also make the module much easier to find when > searching through the module listing, I think. As much of a pain as it is to get new modules accepted, I agree that mixing archiving functions into shutil is not the right way to do it and that a separate archive_util module would make much more sense and would give a logical place to put any extensions to archive handling. S ___ 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 Mon, 18 Jan 2010 10:56:05 -0500, "Steve Steiner (listsin)" wrote: > As much of a pain as it is to get new modules accepted, I agree that > mixing archiving functions into shutil is not the right way to do it > and that a separate archive_util module would make much more sense and > would give a logical place to put any extensions to archive handling. Looking at the source code and API for both shutil and archive_util, I think that the archive_util methods fit into shutil. shutil currently wraps some standard library facilities with convenience functions for operations you might otherwise perform at the shell command line using OS facilities. As far as I can tell, archive_util does the same, and seems quite within the shutil mission of "high level file operations". So +1 from me for putting these in shutil. -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls ___ 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
2010/1/18 R. David Murray : > On Mon, 18 Jan 2010 10:56:05 -0500, "Steve Steiner (listsin)" > wrote: >> As much of a pain as it is to get new modules accepted, I agree that >> mixing archiving functions into shutil is not the right way to do it >> and that a separate archive_util module would make much more sense and >> would give a logical place to put any extensions to archive handling. > > Looking at the source code and API for both shutil and archive_util, I > think that the archive_util methods fit into shutil. shutil currently > wraps some standard library facilities with convenience functions > for operations you might otherwise perform at the shell command line using > OS facilities. As far as I can tell, archive_util does the same, and > seems quite within the shutil mission of "high level file operations". > > So +1 from me for putting these in shutil. Conceptually, I'm happy with these going into shutil (and +1 on the rest of Tarek's proposal, too!) To my mind, shutil is a module for higher-level operations on files - the sort of things you'd do in shell commands, like move a batch of files around (mv), create a directory tree (mkdir -p). Tarring or zipping up a batch of files fits nicely into that space. Paul. ___ 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] PyCon Keynote
On Wed, 13 Jan 2010 10:51:14 -0800, Guido van Rossum wrote: > Please mail me topics you'd like to hear me talk about in my keynote > at PyCon this year. As a typical (but perphaps more vocal) python developer I would like to hear things that might aspire me and others to move to python 3. The way I see it is that python 2.x represents everyones comfort zone. It's safe and nobody got fired at work for using python 2.x I would like to hear how python 3 could be 'shaken' up with a slightly less conservative policy that has gone with the python 2.x series. The logic perhaps being that since only a minority use the 3.x series, it's functionality set is still more up in the air. imo it needs bigger batteries to give it more power than the 2.x series. This meaning that the stdlib could take an extra 5-10 packages not in the 2.x series. Just as one example, sphinx - a great documentation tool. I can easily name five or six others. I'd also like to hear more of your ideas on pypi and getting it to have as much who-ha as CPAN. You could do a lot to enlarge the developer group. Help us all get our priorities to be inline with your own wishes and expectations. If you ask us all to put in a big year and buy you a beer at the end.. I'm certain we all will. Every little bit of inspiration and direction counts for a lot... Best Regards David ___ 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
