4 ms·

> 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

by sho_hn 14y ago

> 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.

gouranga 14y ago
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.
- alex-g 14y ago
  > 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?
  - gouranga 14y ago
    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.
    - sho_hn 14y ago
      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/ 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.
    - SoftwareMaven 14y ago
      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."
      - gouranga 14y ago
        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 http://bugs.python.org/issue4565
        hynek 14y ago
        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)
pdeuchler 14y ago
"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.
- gouranga 14y ago
  My problem entirely!
- hynek 14y ago
  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.
  - pdeuchler 14y ago
    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.
    - hynek 14y ago
      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.

by sho_hn 14y ago

gouranga 14y ago

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.

alex-g 14y ago
> 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?
- gouranga 14y ago
  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.
  - sho_hn 14y ago
    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/ 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.
  - SoftwareMaven 14y ago
    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."
    - gouranga 14y ago
      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 http://bugs.python.org/issue4565
      - hynek 14y ago
        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)

pdeuchler 14y ago

"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.

gouranga 14y ago
My problem entirely!
hynek 14y ago
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.
- pdeuchler 14y ago
  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.
  - hynek 14y ago
    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.