A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2010-January/097375.html below:

[Python-Dev] Enhancing the shutil module

[Python-Dev] Enhancing the shutil moduleDoug Hellmann doug.hellmann at gmail.com
Mon Jan 18 14:46:05 CET 2010
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


More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4