On Sat, Jan 3, 2015 at 12:50 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Otherwise, consider that the great bulk of scripts that are written in Python don't do any file management at all, other than perhaps reading or writing a few files. So even if Python gained this functionality, it wouldn't have any impact on most scripts and applications.[1]
I've always thought of a trash can as an inherently human-controlled feature. When you go in using a GUI file manager and delete a file, it lands in trash. When you use another application, it's always felt surprising - for instance, BitTorrent on Windows deletes things by moving them to trash. (Which has abysmal performance if you select a huge bunch of things and wipe them all out at once; trashing gobs of stuff across thousands of files seems to trigger an O(N*N) repeated search for which files "fall out" of trash - not to mention that this probably means a fairly arbitrary subset of the freshly-deleted is in trash, and little or nothing from previous deletions remains.) Most apps should do file management at the file system level, unless they're specifically replicating/replacing the file manager. So a "move to trash" feature is something that (a) isn't going to be needed by most apps, and especially (b) would be an attractive nuisance. A third-party module has that extra little hump of having to be consciously sought, so it can be there for those who want it but not waving itself around at those who really should be looking at os.remove(). I'm -0.5 on adding a "move to trash" function to the stdlib, ever, and a definite -1 on adding one now. ChrisA