Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The Red Hat family of distros being decades behind isn't really an indication that things they aren't using are new and shiny. Plenty of modern distros ship Python 3 as the default Python, including Ubuntu. RHEL6 still uses Python2.6! It's horrid.

I'm also a sysadmin, and not a programmer. But I do a lot of my automation scripting in python, and have worked on a few larger projects in python, including one that's requirements meant it had to be Python2/3 compatible. I am not a fan of Python prior to 2.7 at all, and I think 2.7 is really just a bunch of bandaids trying to pull together a pretty crappy language, whereas 3.x is a joy to work with.



> The Red Hat family of distros being decades behind isn't really an indication that things they aren't using are new and shiny.

I talk about how a sysadmin perceives the state of Python, and a sysadmin usually works with stable OSes. And you know what? Most of the major distributions commonly used for servers use Python 2 as the default interpreter. The list of these distributions includes Red Hat/CentOS 7, Debian stable (Jessie) and soon-to-be-stable (Stretch), and Ubuntu 16.04 LTS.

> Plenty of modern distros ship Python 3 as the default Python, including Ubuntu. RHEL6 still uses Python2.6! It's horrid.

Erm... You compare "modern distros" with a release that is on its LTS? You know you're being unreasonable, right? Not to mention that Python 2.7 was released in 2010, the very same year as RHEL 6. It's hard to hold it against Red Hat having this in mind.

And how Ubuntu ships Python 3 as the default version? From what I see, in Ubuntu Zesty (17.04, i.e. the most recent release) package "python" has version 2.7.13-2.

> I am not a fan of Python prior to 2.7 at all,

Because...?

> [...] I think 2.7 is really just a bunch of bandaids trying to pull together a pretty crappy language,

Like...?

> [...] whereas 3.x is a joy to work with.

Becuase, in contrast to 2.x, it has the feature of...?


You do need to be careful when arguing about names: the official upstream advice from the Python core team is that, for example, invoking "python" (just "python") should always execute Python 2 (or report "command not found" if no Python 2 is available). Invoking Python 3 should always be "python3".

(the reason for this is to avoid breaking ancient scripts which naively assumed that "python" would always refer to Python 2, and allowing Python-3-aware scripts to be explicit about what version they were targeting)


Debian has included Python 3 since Squeeze.

The Ubuntu 16.04 Canonical provided AMIs on AWS don't even include Python 2, though it appears to be back in 16.10 and 17.04 from my double checking - but on 16.04, there is literally no python27 without installing it via apt.

RHEL and Cent have had Python 3 available in software collections since 6

And yes, since 6 is still not EOL the fact that they are still on 2.6 by default is something I can hold against them.

But per PEP standards, python should always be python2.x, and if it's not installed, not work at all. python3 should always be python3.

As for why I didn't like 2.6: 'io' performance was quite low, and much of what I've worked on makes heavy use of it. The C rewrite solves this. Lack of support in logging for logging over TCP. Being restricted to a single context manager when using with. Optparse instead of argparse. The lack of dictionary comprehensions (and I guess set comprehensions too, but I don't really use sets too frequently).

Why is Python 2.7 still not at Python 3 levels? I do a lot of work with international characters. That right there is enough, really. Outside of that? Just so much stupidity. Parts of the standard library with inconsistent names. Why are some libraries capitalized? Queue vs queue. Lack of asyncio.


> The Ubuntu 16.04 Canonical provided AMIs on AWS don't even include Python 2, [...] there is literally no python27 without installing it via apt.

Guess what? Freshly debootstrapped Debian doesn't have Python installed at all, too. And guess why? Because all the essential tooling in Debian is compiled. But then there is optional tooling, and Python 3 is yet to be used there.

But we were not talking about what interpreters are in a default installation. We were talking about Python 3 being the default Python.

> And yes, since 6 is still not EOL the fact that they are still on 2.6 by default is something I can hold against them.

No, you cannot. The primary thing RHEL provides is stability.

> Lack of support in logging for logging over TCP.

(1) Not like you cannot add it trivially. (2) It's not a good idea to work in Python's logging with unreliable things like network. You should always isolate Python logging from those things by using spooler. BTDTGTS.

> The lack of dictionary comprehensions (and I guess set comprehensions too, but I don't really use sets too frequently).

Of course, because those are essential part that cannot be trivially emulated by dict() constructor.

From all you said, only I/O performance, context managers, and lack of argparse are somewhat sensible arguments. They sum up to too little for me to consider them a significant difference in how it feels to write code (not to mention that optparse is adequate and I don't see argparse as much of a progress), but then I normally use half a dozen of other languages and runtimes, so I have a different perspective.


Python is Ubuntu's preferred language for system tools, and these now run under Python 3. Both Debian and Ubuntu have policies of using Python 3 wherever possible. The "python" command still invokes Python 2 to make sysadmins' lives easier.[1]

[1] https://www.python.org/dev/peps/pep-0394/


>> [...] whereas 3.x is a joy to work with. >Becuase, in contrast to 2.x, it has the feature of...? Unicode strings makes my life a lot easier when dealing with anything international. Pretty much every difference made was better for the language.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: