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

[Andrew Barnert]

On Jan 4, 2015, at 7:05, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 3 January 2015 at 21:04, Andrew Barnert
> <abarnert at yahoo.com.dmarc.invalid> wrote:
>> On Jan 3, 2015, at 11:39, Chris Angelico <rosuav at gmail.com> wrote:
>> 
>>> On Sat, Jan 3, 2015 at 9:28 PM, Andrew Barnert <abarnert at yahoo.com> wrote:
>>>> I agree with this, but it still might be nice to mention that third-party module in shutil and/or pathlib.
>>> 
>>> Maybe. Is there a mention of other third-party packages in stdlib
>>> docs? It's a slippery slope; which ones deserve mention? Maybe just
>>> something like "Note that moving objects to the trash can is possible
>>> in OS-dependent ways; packages are available on PyPI to make this
>>> easier", without naming any.
>> 
>> The impression I get is that this is a slope that Python (or at least Nick Coghlan) wants to start sliding down--with the advent of wheels and pre-installed pip, keeping things out of the stdlib but still accessible for most users is now possible, and often desirable. But I could be putting words (or complete ideas) in people's mouths.
> 
> Your parenthetical qualification is correct - while I personally think
> providing authoritative recommendations of third party modules is a
> good idea, this is far from a universally held opinion amongst the
> core development team. My own caveat on the idea is that any such
> explicit recommendations should only cover projects that potentially
> *could* be included in the standard library from an API design
> perspective, but we don't want to include them (yet, or perhaps ever)
> for project governance reasons, such as their update cycles for
> feature releases needing to be faster than those of the standard
> library.
> 
> The "pro" case for this approach is primarily about lowering barriers
> to entry: for folks just learning Python, "not in the standard
> library" is currently functionally equivalent in many cases to "Python
> can't do this". New users often won't yet have the skills needed to do
> their own research and evaluate competing solutions to their problem,
> and teaching someone how to find a module on the internet, evaluate
> the trustworthiness of the people publishing it, get it onto their
> computer, and update it appropriately over time is genuinely difficult
> (even with pip provided by default - that helps with the last two
> steps, but the first two are still genuinely difficult, in a way
> experienced open source developers often take for granted). Providing
> authoritative recommendations of third party projects in the standard
> library documentation helps resolve that situation without needing to
> resort to making the standard library larger (with the additional long
> term maintenance complications the latter approach entails).
> 
> You see a similar dynamic operating in a slightly different way with a
> project like Django - when the Django developers are significantly
> more experienced in web development than you are, their opinionated,
> all-inclusive approach to web framework design is a *feature*, not a
> defect. It's only when you become more experienced with web service
> development yourself, and need to deal with problems that don't fit
> neatly into the SQL-backed three-tier web application model, or need
> to integrate with other systems which weren't built with Django in
> mind, that less opinionated frameworks like Flask or Pyramid become
> interesting - those frameworks leave many more decisions to the
> developers using them, which is exactly what you want in many
> situations as an experienced developer, but constantly asking people
> to make decisions they aren't yet qualified to make poses a huge
> barrier to entry. It's a potential problem when less experienced folks
> are put off by the request to make those decisions (since not
> understanding the questions you're being asked by your tools makes for
> a terrible user experience), and decide to go learn something else
> that places fewer demands on them, but it's even worse for everyone
> trying to deploy and manage the resulting software systems when folks
> happily make the decisions these advanced DIY integration frameworks
> ask of them without even realising they're not yet qualified to make
> them.
> 
> djangopackages.com is also incredibly useful as a tool for finding
> peer evaluations of projects in the Django ecosystem. I'm not yet
> aware of any successful attempts to expand that model to other plugin
> ecosystems, but the core grid concept of assembling a set of criteria,
> providing answers across a set of related projects, and publishing the
> results to provide a starting point for anyone doing their own
> research in that topic area is a wonderful one.
> 
> The "con" case is that providing default recommendations can be
> controversial - when there are multiple competing projects in an area,
> being the default recommendation of the CPython core development team
> can be a huge popularity boost, since reputation is to some degree
> transitive. If someone trusts CPython, and we trust another project
> enough to recommend it, then a lot of folks will use that
> recommendation as a substitute for doing their own research (even when
> they *can* do that research themselves, the default recommendation is
> likely to be good enough, letting them defer investigation of
> alternatives until after they've tried the default option).
> 
> I suspect that objection could potentially be dealt with the same way
> we deal with any other standard library design decisions: if a module
> maintainer is comfortable making a recommendation based on their own
> expertise they can, but broader recommendations spanning several
> modules would require at least a discussion on python-dev, and
> potentially even a PEP.

The question here, then, is how this applies to desktop/shell functionality like moving to trash, administering trash in all the ways someone (Steven?) wanted, other features that someone else raised (aliases/bookmarks/shortcuts/desktop files), and maybe additional stuff (accessing the desktop's extension/file-type mapping). Some of that stuff is already in the stdlib (or might be confusing to novices--e.g., IIRC, on XDG desktops, some things that are done with aliases on Mac are done with desktop files, but in some cases you just use symlinks, so a Linux novice might not even realize he's not writing cross-platform code...).

For a GUI app, it's not at all clear that choosing Qt or Wx or one of the platform-specific libraries automatically solves all of these problems for you, while choosing Tk doesn't. For a command-line app, it's even worse. Most Windows users probably have no idea they're asking for desktop integration rather than OS support when they ask how to move a file to the trash or create a shortcut, because Windows intentionally buries that distinction. So when they see that neither os nor shutil nor anything else in the stdlib can help them, they're not going to think, "Oh, I need to go find a platform-specific or cross-platform desktop integration library." (And they're also not going to think "Well, Perl and Ruby and Node don't have these either, so why should I expect Python to?") So, I think in this case it would be useful to recommend something. The question is _what_ to recommend (and where). 

I think for platform-specific code there are pretty clear winners (PyWin32, PyObjC, GObject, and PyQt/PySide, for the big four). Some might argue for including the XDG package (e.g., if you want to do the same thing as one of the XDG-utils tools, you don't need Gtk or Qt for that), and Mac users might also want a link to the ScriptingBridge guide or something (because some things that are done by API on Windows are done by scripting System Events or Finder or something else), and people using a third-tier desktop on Linux may not have Gtk or Qt libraries to bind to, etc., but I think those are minor questions compared to whether it would be useful to have pointers to these packages for novices. (I think it goes without saying that none of these packages should be added to the stdlib, right?)

But for cross-platform code there really isn't an answer. (Well, PyQt/PySide would work, but it's still non-trivial to install and configure on Mac and Windows, and it's overkill.) So, maybe what we need here is for someone to first create the desktop package, and then we can worry about whether it should be added to the stdlib, recommended in the stdlib, or neither.

And that still leaves open the possibility that some small subset of this functionality might be separable enough and useful enough to put in the stdlib, or in a small package linked from the stdlib. After all, the equivalent of start/open/xdg-open is already there for some platforms, and webbrowser.open and some of the stuff in shutil. I don't think moving to trash is part of such a subset (for the reasons I gave earlier), but I could be wrong.