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

Nick Coghlan ncoghlan at gmail.com
Tue Jan 6 11:25:01 CET 2015


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.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list