On Mon, Sep 19, 2016 at 06:38:00PM +1000, Chris Angelico wrote:
> Sounds good to me. This is definitely sounding complicated and messy
> enough to justify (a) writing a function to clear the screen, and (b)
> testing that function thoroughly as a PyPI module before pushing
> anything into the stdlib.
This isn't Node.js where standard operating procedure
is to rely on the third-party npm ecosystem even for tiny, ten line
functions. And we should be *glad* that's not the case:
People don't often install minor or small packages off PyPI as a matter
of course: they either roll their own, or do without, depending on which
is more painful, or whether they are even allowed to download
third-party software (not everybody is), or whether managing the
dependency is more or less work than writing their own.
I get it that not everything belongs in the std lib, and I get it that
for *some* people (but not all) its easy to rely on packages in PyPI.
But there's quite considerable friction in getting *small* things off
PyPI. For starters, you have to know it exists, you have to trust that
its functional and well-written. There is a huge amount of junk,
abandoned and "version 0.1" packages on PyPI that nobody in their right
mind should use. Dependencies don't come for free, they add complexity
and cost to a project. Not everything belongs as a package on PyPI either.
If the cost of dealing with the added dependency is greater than
the benefit gained, people won't use third-party packages on PyPI. For
small but useful functionality, saying "Put it on PyPI" is effectively
just a dismissal.
For relatively small pieces of functionality, if it is useful enough, we
should just add it to the std lib, and if it isn't, we should just say
it isn't useful enough. We shouldn't condemn supporters of the idea to
this false hope that if they can convince a thousand, or a million,
people to download their package, it will be added to PyPI.
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/