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 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
