Hacker News Reader

Comment by shadowmint | Hacker News Reader

I kinda of like this... but then again I'm kind of wary.

Isn't the standard library the place where packages go to die?

Isn't the reason pip is actually useful because has a nice health release cycle (http://www.pip-installer.org/en/latest/news.html) and isn't frozen into the standard-library ice age of the past?

Won't this make it even harder to build a compliant version of python that runs on mobile devices where you can't install packages (>_> iOS)?

I get that it's convenient, I'm not 100% convinced its a good idea.

Edit: Reading the PEP in detail its now clear that this is not bundling pip with python (see 'Including pip directly in the standard library'). This is bundling a pip installer as part of the standard library. Much better.

View on HN

It looks like they're taking a new strategy with this move. Pip isn't actually going to be moved to the standard library to live; rather, a new "ensurepip" command that installs "pip" will be a part of Python proper.

However, a distributable version of pip will be included with each release so that ensurepip does not have to contact the PyPI servers during an install. And with each maintenance release of Python, this pre-included version will be updated to match the then-current pip release.

But, the bottom line is that pip still lives outside of the standard library. Python 3.4+ is just guaranteeing that you have a version installed.

According to the pep ensurepip was rejected: http://www.python.org/dev/peps/pep-0453/#including-ensurepip...

For backporting to 3.3/2.7. 3.4 has it.

Is it the "norm" that, when accepted into the standard library, packages "die" - or is it because this has happened to some packages, the popular perception is that the standard library is where packages go to die.

I'm just not understanding how it's OK that a standard acceptance of a Python package really means that it should go to the graveyard.

The standard library only gets new features when a minor or major Python release happens. That doesn't happen very often which slows down development of anything in the stdlib significantly to the point that packages in the stdlib effectively "die".

To some extent this is intentional because anything that requires more frequent changes is probably not stable enough for inclusion in the stdlib, in practice it does cause some unintentional issues for example rather lacking timezone support.

Ya, this is a good thing. Ruby started shipping with rubygems since 1.9 and it's worked great.

And Node started shipping NPM in 0.6.3 --- which has also worked great.

> Won't this make it even harder to build a compliant version of python that runs on mobile devices where you can't install packages (>_> iOS)?

Why wouldn't you be able to install packages? iOS stops you from making executable pages, but cpython runs bytecode anyway.

Reply on news.ycombinator.com