On 4 January 2015 at 20:32, Andrew Barnert <abarnert@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 space. 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. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia