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

[Nick Coghlan]

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.

Cheers,
Nick.

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