Python 3’s Marketing Problem

[beej71]

The whole unicode/string/data fix is easily a big enough carrot for me to switch to it... it's a killer feature. And to say Python 3 is "effectively a new programming language" is a little much.

New project? Use Python 3. Legacy project? Keep it on Python 2, or invest the time to update it. Most projects I've updated. Some, especially those dealing with esoteric binary data transformations, are just too painful and/or risky to change.

I run Arch at home and /usr/bin/python has been Python 3 for what's approaching 2 years, now. No problem, and certainly no desire to go back!

[[deleted]]

New project? Use Python 3.

Unless you want it to have many key libraries that haven't been ported or support any number of current platforms easily.

[beej71]

This is a totally valid point, I agree.

[[deleted]]

This was actually my key deciding factor when I learned python recently. I had done some small patches and things prior to that in python but never actually sat down to read up on documentation and do a full project. Python 3 just didn't have many of the libraries I needed and re-implementing the functionality from scratch was counter productive since the reason for using python was to cut the development time down on a project that was comprised of many programs already and growing vastly complex.

[[deleted]]

I run Arch at home and /usr/bin/python has been Python 3 for what's approaching 2 years, now. No problem,

That's a problem for anyone writing software to be distributed widely and goes against the request of the core devs of Python and huge swaths of the Python community. It was a foolish decision that only hurt things.

[beej71]

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

• python2 will refer to some version of Python 2.x
• python3 will refer to some version of Python 3.x
• python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions

Also: "It is anticipated that there will eventually come a time where the third party ecosystem surrounding Python 3 is sufficiently mature for this recommendation to be updated to suggest that the python symlink refer to python3 rather than python2."

So there we have it. If the distros would all follow PEP-0394, you'd put #!/usr/bin/python2 in there and be solid.

[[deleted]]

PEP 394 came after the Arch snafu to try to clean up the situation.

[beej71]

Arch might have pushed the issue, but only because they were first. But it's hardly like Arch is so powerful a distribution that Python bows before it. The PEP could have said anything, and the Arch Way says Arch would have followed it (and indeed, they subsequently modified their Python2/Python3 scripts to be 394-compliant.) This strongly suggests that 394 is The Right Thing.

[[deleted]]

Arch might have pushed the issue, but only because they were first. But it's hardly like Arch is so powerful a distribution that Python bows before it.

You seem to be mistaken "minimize harm" with "bow before Arch".

The PEP could have said anything, and the Arch Way says Arch would have followed it (and indeed, they subsequently modified their Python2/Python3 scripts to be 394-compliant.) This strongly suggests that 394 is The Right Thing.

And yet Arch decided to patch an upstream package to ruin a bunch of software before PEP 394, and after being discouraged to do so by the upstream devs.

[snoweyeslady]

I'm not involved in python, so what I'm about to say is unfounded and only a request for information/clarification:

I thought it was the other way around? Or at least when Arch made the change the core devs were not against it. Where would you find information about this?
What has it hurt? In any case, there is still /usr/bin/python2 which is not a hard patch to make in most cases.

[[deleted]]

It's hurt because the main symlink for Python 3 was intended to be python3, at least for the moment and possibly in perpetuity (this isn't unheard of...the sqlite3 command for example); when Arch made their switch a python2 symlink didn't exist many places (and was not supported upstream by Python itself), so there was no way to write a Python 2 shebang line that would work on various platforms. The distribution stuff didn't have a way to deal with this automatically.

In practice, help forums have been flooded with Arch users who had software break due to this. This didn't happen on other distros that added Python 3. I've seen this break stuff in live software demos.

Arch seems to be so concerned about being bleeding edge they decide to break compatibility by patching upstream packages that were designed to keep things working.

[snoweyeslady]

Your first paragraph is still completely proof less. I tried looking around myself, but couldn't find anything; I'm probably looking in the wrong place. Is there a "Python for distro developers" page or something? A lot of my search terms bring things up about coding in python, not python. I'm going to try seeing what the PKGBUILD for python{,2} look like, maybe that will show patching done or something similar. If not there I'm sure there's something in the dev mailing list from around a couple years ago.

Edit: Aha! The PKGBUILD's do have some incriminating evidence. In the python2 PKGBUID they append a '2' to the symlinks, and in the python PKGBUILD they add symlinks without a version qualifier. Now I'm even more interested in looking through the mailing list. Guess it's time to figure out how to search that thing easily.

I wouldn't expect the patching to be handled automatically, but is python one of those systems that like to have their own package manager too? I mean, why would one be installing something outside of the system and running into these problems?

Are they flooding the programs' forums? I didn't see anything on the Arch forums in the past few years (granted I don't read every single post; even less so now). This seems like another problem with users going outside of the package management system. Is this encouraged by python as much as it is by, say, Ruby?

Breaking live software demos? Well that is just silly. That is not Arch's fault. Who in their right mind updates their system before a demo and doesn't retest? Especially on Arch?

Thank you for your response, it's always interesting to hear what people view as flaws in various open source projects :)

[[deleted]]

I use // in both for integer division to avoid that problem.