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

Nick Coghlan ncoghlan at gmail.com
Sun Jan 4 14:01:08 CET 2015

On 4 January 2015 at 20:32, Andrew Barnert <abarnert at yahoo.com> wrote:
> 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?)

Right, a useful first step might be a "Tools for writing rich client
applications in Python" overview page. That's out of scope for any of
the current *.python.org documentation set (it doesn't fit under
docs.python.org *or* packaging.python.org, nor anywhere on the main
site), but if it's written in an appropriate tone (i.e. making it
clear that these are default starting points, and recommendations for
further evaluation, rather than universally applicable definitive
conclusions), then a future "ecosystem.python.org" guide could start
the same way p.p.o did, as a separate Sphinx project hosted on
ReadTheDocs that was later blessed with a python.org subdomain.

https://packaging.python.org/en/latest/deployment.html is an example
skeleton of such a page for package deployment tools. We haven't
filled that one *in* yet, but hopefully it conveys the general idea.
https://packaging.python.org/en/latest/extensions.html is another one
reviewing binary extensions, and some of the tools available in that

For those curious as to "Why not the wiki?", a Sphinx project hosted
on a pull request capable service like GitHub, BitBucket or Kallithea
offers a much nicer workflow for reviewing of proposed changes,
together with an integrated issue tracker for submitting proposals for
updates (https://github.com/pypa/python-packaging-user-guide/ is the
project behind packaging.python.org, for example).

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

Just describing the problem space can be incredibly valuable for
newcomers - one of the hardest things to learn as a beginner is the
difference between "this is hard because I don't know what I'm doing"
and "this is hard because I'm working on an unsolved problem" (with
"this is deceptively easy because I'm setting myself up for problems
later on" being an interesting variant that's hard to detect no matter
how experienced you are).

I see this is a *lot* when working with the scientific community -
they actually have much higher expectations of cross-platform tooling
than professional developers do. From the outside, the political,
personal and commercial meta-issues that combine to make
cross-platform standards development an unholy nightmare aren't
immediately obvious, and nor are the trade-offs between "lowest common
denominator" (or Java-style "reinvent all the wheels") functionality
that works everywhere, and providing access to advanced platform
specific functionality.

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

While I think it's better to leave the question open rather than try
to pre-empt an answer, I do believe we can at least say *now* isn't
the right time to be adding "move to trash" functionality to the
standard library - the functionality isn't mature enough within the
broader ecosystem to determine an appropriate answer.


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

More information about the Python-ideas mailing list