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

[Andrew Barnert]

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

> On 6 January 2015 at 19:29, Andrew Barnert <abarnert at yahoo.com> wrote:
>> On Jan 6, 2015, at 5:43, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> 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.).
> 
> Yes, there's certainly a lot of value in adopting an existing
> specialist toolkit when writing rich client applications. The key
> problem is that it isn't easy to start with the provided Tcl/Tk
> support in the standard library (to avoid introducing a large external
> dependency) and then later migrate to one of the other third party
> toolkits (if the basic functionality proves insufficient).

> While an asyncio-style pluggable solution may be one possible option
> for that (i.e. provide default implementations of features which may
> be fairly basic, but allow them to be replaced by full featured
> implementations backed by Gtk/Qt/wxWidgets/etc), that kind of
> abstraction layer design is extraordinarily difficult to design well.
> It's hard enough even in cases like wsgiref and asyncio that are
> relatively simple compared to the services a full rich client
> application will expect to have available.

Yes, and even besides the difference in complexity, even the most basic elements--the API for the runloop and message maps (wx), signals/slots (Qt), event handlers (Tk), etc.--are pretty hard to abstract away. For servers, a reactor is a reactor, but for GUIs, a signal/slot system is not a message pump/message map system. And whichever abstraction you pick, adapting it to work with the other abstractions is no fun. (Look at how  long the TkAqua Cocoa port took, and how much Cocoa functionality is still missing.)