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

[Andrew Barnert]

On Jan 6, 2015, at 5:43, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 5 January 2015 at 20:38, David Wilson <dw+python-ideas at hmmz.org> wrote:
>> I have no problem with this being included somehow in the standard
>> library, but pathlib to me is all about the filesystem, whereas (as
>> others have pointed out), the Recycle Bin and associated concepts on
>> other OS relate pretty uniformly to the OS shell.
>> 
>> There are many shell-related concepts that could be nicely exposed, but
>> again I don't think any of them belong in pathlib. For example,
>> labels/tags, owner application, icon, visibility flags, etc.
> 
> Better tools for accessing typical extended file metadata would indeed
> be highly desirable (thumbnails/previews are another one that comes to
> mind). As with the recycle bin though, the generally preferred
> approach for standard library additions is incorporating existing
> modules that have been available through PyPI for some time, or else
> creating a derivative of such a project that meets other constraints
> of standard library inclusion (e.g. ipaddress vs the project it was
> based on, ipaddr).
> 
> Unfortunately, most of the folks that need these cross-platform
> integration features are likely to be using a C/C++ toolkit that
> provides them (e.g. Gtk, Qt, wxWidgets), which significantly reduces
> the incentive for anyone to create a Python-specific abstraction that
> would be suitable for eventual inclusion in the standard library.

I'm not sure that's really unfortunate.

First, a framework like Qt or wx is maintained by people who think about nothing but desktop and GUI integration on the major platforms. They track changes pretty quickly (especially compared to the Python stdlib). A few years back, when Apple got rid of legacy-style preference files, I had a Qt app that I was able to fix just by updating to the next version of Qt, and a non-Qt app that I had to fix by reseatching, writing, and testing, a wrapper that "temporarily" (of course it's still there in 2015...) stashes the entire legacy file as an encoded string in the new-style prefs database. What are the odds a Python stdlib solution (or even a third-party Python lib with less than 1/20th the user base, community, and corporate support) would have fixed it for me automatically in time for my next release the way Qt did?

Also, the fact that Qt and wx are complete frameworks means they can make assumptions that allow for simpler solutions. A Qt library knows how to check whether there's a runloop and, if there is, knows it'll be a Qt runloop, and, if not, knows how to create a short-term blocking runloop and background thread, and it also knows how to pass signals from background threads to the runloop, and so on; this means Qt could just use the (10.5+, and still not deprecated as of 10.10) NSWorkspace API for trashing on Mac, because none of its deficiencies apply to any Qt app. A library meant to be used generally across all kinds of apps can't do that. Obviously this is also a weakness, because not all cross-platform desktop-integration apps really need a full framework… but many do. 

And again, many simple tools don't need to be cross-platform (like my completely separate 3-line trash tools for each platform that I use), or don't need full generality (my Mac trash tool doesn't need to work on 10.6, or to be App Store compliant; my Ubuntu trash tool doesn't have to know how Unity deals with trashing over CIFS because I only have two CIFS mounts and they both do server-side automatic recycling; etc.).