[Python-Dev] Enhancing the shutil module

[Masklinn]

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.