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