Hacker News Reader

Comment by sho_hn | Hacker News Reader

> I assume this is why a large number of Linux distributions are stuck on 2.6 and 2.7 still.

This doesn't match my experience at all. Most distributions I can think of had no problem replacing 2.6 with 2.7, and have offered fresh Python 3 packages alongside them as well for years now. My distro of choice (Fedora) has dozens of Python 3 libs packaged.

Ubuntu is aiming for "no Python 2 in main" by 2014 now, and Arch even switched to Python 3 by default already.

I'd go as far as claiming that the distros are actually at the forefront of and partly driving the transition right now.

View on HN

"Most distributions I can think of had no problem replacing 2.6 with 2.7, and have offered fresh Python 3 packages alongside them as well for years now."

That may be well and good for startups, or smaller companies, but larger companies with infrastructure running on CentOS/RedHat (and old-ish versions of them at that) still have trouble with Python 3. In CentOS 5 if you change the default python distribution to 3.0 > yum completely dies. Not to mention various other little bits and pieces.

Hm, so? It's not like you need /usr/bin/python to be Python 3 to use Python 3, especially considering that Python upstream is recommending for it to remain pointed at Python 2 for now and essentially guaranteeing/mandating the existence of /usr/bin/python3. I doubt there's any Python 3 code out there that is meant for public consumption and relies on /usr/bin/python being Python 3.

Please note I do make the distinction of the default python distribution (aka /usr/bin/python). Some companies that aren't startups cannot or will not (policy or otherwise) either maintain separate installs of python on hundreds of servers, or require use of the default install.

Even if that separate install is a regular package of the distribution? I get not wanting to install from third-party repositories or even building your own (I try hard to avoid both myself, and there are good reasons not to want to invite that deployment overhead), but consider regular packages to be non-scary.

Uhm I don’t get this: yum uses /usr/bin/python, why should it care about /anywhere/python3?

Also we have many CentOS 5 servers but won’t let dictate our Python based software development by their Python 2.4. So we just rolled our own RPMs and put our python binary outside PATH. We deploy only via virtualenvs, so it’s not problem.

Not every company has the luxury of going "Oh, that's cool, we'll just completely switch to virtualenv for everything and start rolling our own RPMs." /magicwand

Sometimes the best solution to your problem is economically untenable, sometimes you currently don't have the engineering talent to allocate, etc etc.

And what exactly has that to do with Python 3.3? You spoke about overwriting CentOS’ /usr/bin/python with Python 3 but don’t have enough “engineering talent” to do proper deployments?

You speak about economical factors, but doing broken deployments and using ancient Python versions (I’m talking 2.4 vs. 2.7 here, not Python 3) costs you much more money on the long run than building a new RPM every few months.

Nevertheless 2.7 (which was released two years ago) still gets bug fixes and no new features. So I really don’t get what this comment thread is about.

My problem entirely!

I'm using stable Debian and RHEL in server environments though.

Fedora, Arch and Ubuntu are orders of magnitude too unstable for me to go near and I'm sure the same is true for a lot of other people.

More conservative distributions tread very carefully.

> More conservative distributions tread very carefully.

Well, yes, that's what conservative means. You're using stable distros, with older versions of Python, and it sounds from your original post like you're not interested in using newer versions right now. So... what's the problem exactly?

I would rather like to use newer versions but the rate of change since 3.0 was introduced is slightly scary and hard to quantify. I'd rather not try to hit moving targets.

Python appears to be a playground for features versus a stable, reliable well tested and well thought out language these days.

I don't think that's really fair, considering they even had a _moratorium_ on language changes in place for two years: http://www.python.org/dev/peps/pep-3003/

And as for the standard lib, a lot of the additions e.g. in 3.3 is simply stuff that's been around and proven for years: virtualenv, mock ...

I mean, I respect that you feel that way, but I just don't see the same sort of cause for concern I guess.

New features != unreliable

Python has an extensive set of comparability tests and the system is quite modular. It also follows the maxim that complex systems that work are built from simple systems that work.

You don't have to use the new features. You don't even need to use Python3. Sounds more like "Damn kids and their loud rock and roll."

Not at all. People need stuff that works, not half baked stuff.

Fine example here (there are loads more like this):

http://bugs.python.org/issue4565

I’m not sure what’s half-baked about a 3 years old ticket for a Python version that has never been declared as usable. (3.2 was the first production-ready Python 3)

Reply on news.ycombinator.com