Hacker News Reader

Comment by PythonicAlpha | Hacker News Reader

The problem is not only Unicode.

If it only where for unicode, the problem would not so big. But they seemed not to bother at all about backwards compatibility at all in the first Py3 version. Later, they did try to change some things, that unnecessarily(!!) blocked adoption, but many projects already decided to ignore Py3.

I guess, you don't mean what you said in the last paragraph? Was it just a joke?

Unless you can replace all libraries that exist only as Python 2 version, you can not move -- you can use zero Python 3. That is a huge problem to real projects -- of course, if you only have some University (educational) - projects, all is fine and you can play around as you like.

Also there is the problem, that it is not trivial to have Python2+3 on the same installation. Most Linux distros still run with Py2.

View on HN

> Also there is the problem, that it is not trivial to have Python2+3 on the same installation. Most Linux distros still run with Py2. >

Actually, it's trivial nowadays with projects like pyenv. You can even have different python versions in a per-project-directory basis.

Check out the installation guide (https://github.com/yyuu/pyenv#installation) and a commands reference (https://github.com/yyuu/pyenv/blob/master/COMMANDS.md)

There's also an extension that provides virtualenv integration - https://github.com/yyuu/pyenv-virtualenv

Thanks, that looks interesting. I will note it for the time, I have the problem.

This is the same problem addressed by the ancient, universally known tool named virtualenv. How are you delivering pronouncements about the unsuitability of Python 3 when you don't have solid knowledge of how things are done in Python?

I did not "deliver pronouncements about the unsuitability of Python 3". I did only say, that it is not trivial to have both versions on one installation.

And who are you, something like the "Python purity police"?

I will ask you something, that you did not work with till now -- and when you give a wrong or incomplete answer, I will also say "how dare you"!

In what distros is that a problem? I have Python2+3 on Debian running fine side-by-side.

When you have several Python programs, where does /usr/bin/python point to?

I must admit, that I did not think to much about it until now, but normally there is only /usr/bin/python in the scripts.

Of course, if everybody has /usr/bin/python3 inside his Python3 programs, everything could work (unless some of your apps need special environment vars like PYTHONPATH, what could make it troublesome again).

But still, the standard installation of Debian (and others, as much I know) does not include Python3 by default, you at least have to add it to your installation. That is something, you must tell your customers, when you ship Python3 programs.

Most package managers allow you to specify a dependency on Python 3, so you shouldn't even need to tell your customers. Otherwise, you can always use virtualenv and ship Python with your code.

And yes, if you're targeting Debian or Debian-like systems, make a deb. It's really not that hard, especially with newer tools like fpm.

Thank you for mentioning fpm, I'd never heard of it and often wished for something like it. Commenting to bring attention to it, and so I don't forget!

/usr/bin/python should never point to Python 3. Because of the compatibility break, the convention (and default for the Python build scripts) is to always name the Python 3 binary python3, so there should be no conflict. It's understood that during the (very long) transition period there will be need to run both side by side.

A handful of ditros have gone ahead and named it python anyway. A stated motivation has been to encourage adoption of Python 3, but practically they're just shooting themselves and their users in the foot, and ensuring incompatibility with the shebangs defined for every other OS. (I don't think there's any plan to ever switch the default binary name from python3 to python, so this incompatibility may never be resolved.)

Arch switched from Python 2 to Python 3, keeping the /usr/bin/python binary as pointing to their newest version of Python before the convention of naming it /usr/bin/python3 was standardised.

It was specifically in response to the troubles caused by having /usr/bin/python be python3 in Arch that the guideline came about: http://legacy.python.org/dev/peps/pep-0394/

Thanks for the reference; I somehow failed to find the origin of this convention in previous searches.

> When you have several Python programs, where does /usr/bin/python point to?

/usr/bin/python should always point to python 2 (or nothing) /usr/bin/python2 should always point to python 2 (or nothing) /usr/bin/python3 should always point to python 3 (or nothing)

scripts using a shebang line should not, however, rely on /usr/bin/python pointing to python2, and should only use it when they are source-compatible with both python2 and python3.

http://legacy.python.org/dev/peps/pep-0394/

Reply on news.ycombinator.com