[Python-ideas] Adding `pathlib.Path` method that would send file to recycle bin

Andrew Barnert abarnert at yahoo.com
Sat Jan 3 11:28:52 CET 2015


On Jan 3, 2015, at 3:18, Chris Angelico <rosuav at gmail.com> wrote:

> On Sat, Jan 3, 2015 at 12:50 PM, Steven D'Aprano <steve at 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.

I think this may be an accident of the fact that cmd.exe didn't include a trash command, neither did OS X, and the idea was dropped from xdg-trash; we've all been trained for a couple decades now that you can't trash from the command line. I'm not sure that's a good thing. But it is nevertheless a thing that can't be ignored.

> 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

In some GUI applications, it does make sense to trash things via a menu or other user interaction. (Except maybe when you're using Apple's versions/history thingy or some similar mechanism.) One of the things Aquamacs adds to the standard emacs distribution is a move-to-trash command that you can use in diredit mode, for example. Although I guess you could argue that counts as "unless you're replacing the file manager", and maybe the same is true of most other such examples... 

But not all. When I worked on TuneUp, we had a feature to move selected duplicate tracks from quarantine to trash, which I thought was stupid and unnecessary (the quarantine folder is already effectively an app-level trash can...). But when we removed it, we got hundreds of user complaints, and a nasty blog post saying we were trying to deliberately destroy out users' music collections on behalf of the RIAA or something.

And:

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

The Mac version also does the move-to-trash; it has perfectly acceptable performance. (Actually, old versions were terribly slow at trashing a torrent with a lot of top-level files or dirs, but newer versions seem to do a single operation per torrent instead, which works fine.) And I'm actually glad it does this. At least twice, I've downloaded an ISO, mounted it, then trashed the torrent with all files; if they were deleted instead of trashed, I would have had to repeat the download to update my VMs... You could argue that I'm an idiot for doing this, and you'd be right, but I'm probably not the only such idiot; in fact, that's kind of what trash is for in the first place.

> 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 agree with this, but it still might be nice to mention that third-party module in shutil and/or pathlib. Whether that's send2trash or a complete trash management module as Steven (I think?) envisioned or a reference to the platform APIs and the various ways to get at them, it would be useful. (In fact, some prominent reference to PyWin32, PyObjC, GObject, and PyQt/PySide for non-GUI-but-still-desktop apps in the docs might be helpful for lots of reasons.)

Honestly, I think one of the big things people want is the ability to write the "trash" tool for use on the command line that all of the major desktop systems are missing. It feels like it should be a 3-line Python script, and the fact that it isn't possible looks like a weakness. But really, I don't think that's a problem. OS X comes with a Python with PyObjC; a GNOME or KDE system can install python-gobject or PySide in one apt-get/urpmi/port/etc. command; Windows' function is accessible via the built-in ctypes. I have such scripts on my Mac and Fedora boxes; the fact that they're _different_ 3-line scripts is hardly a serious problem.


More information about the Python-ideas mailing list