Live data from Hacker News

About Python 3

alexgaynor.net

21–30 of 358 posts

Re: About Python 3

#21

What is really needed is a 3to2. I have been very impressed with 2to3, the amount of work it does is pretty impressive. But as somebody who tends and prefers to work in python 3 but often needs my scripts to run in python 2, I have no choice but write those in python 2. I can see the same dilemma for somebody who writes an open source library and hope for as much usage as possible.

That wouldn't solve the main issue, which is the [non-negative] amount of work in porting existing Py2 codebases.

Besides, 3to2 (which does exist but isn't maintained) and 2to3 are both bad ideas. They miss edge cases, even common ones, and they add even more complexity to the build/test/install process which people already find hard.

Re: About Python 3

#22
post #6

I used Python 3 for the first time a few days ago (I've been programming in Python for 18 years). When I used python heavily (I've switched back to C++ and now Go) I depended a lot on a small number of really good libraries- ElementTree, NumPy, SciPy, etc. Unless/until all of those get ported to Python 3 (along with hundreds of other programs), and those ports are considered Correct (in the QA validation sense), it's…

ElementTree has always been in 3.x. I believe NumPy and SciPy are finally making the leap just about now.

Re: About Python 3

#23
I like to think of engineering as "solving problems within a system of constraints". In the physical world, engineering constraints are things like the amount of load a beam will bear. One of the primary easily-overlooked constraints in the software world is backwards compatibility or migration paths.

There are many examples of systems where many look at them today and say: "This is terrible, I could design a better/less-complicated system with the same functionality in a day". Some examples of this dear to my heart are HTML, OpenID, and SPDY. It's important to recognize the reason these systems succeeded is they sacrificed features, good ideas, and sometimes even making sense to provide the most critical piece: compatibility with the existing world or a migration plan that works piecemeal. Because without such a story, even the most perfect jewel is difficult to adopt.

The OP, about Python 3, is right on except for when it claims making Python 3 parallel installable with 2 was a mistake; doing that would make it even more impossible to migrate to 3 (unless the single binary was able to execute Python 2 code). (Also related: how Arch screwed up Python 3 even more: https://groups.google.com/d/topic/arch-linux/qWr1HHkv83U/dis... )

Re: About Python 3

#24
This seems like a reasonable perspective, but I wonder how much will change when Python 3 starts shipping with Linux distributions (and probably OS X eventually).

It won't change anything for the shop that has a million LOC, but it might start to budge that 2% number.

Re: About Python 3

#25
post #7

Python 3 came from a good place, and it definitely fixes many problems that sorely needed fixing, but it was doomed to failure from the start (and many developers said that in 2008 already). For all intents and purposes, Python 3 is pretty much a new, separate programming language. Sure, it's very close to Python 2.x, but you don't have out of the box retro-compatibility so that pretty much kills it right there. Pyth…

> but you don't have out of the box retro-compatibility so that pretty much kills it right there. I don't know if that's necessarily a foregone conclusion. Scala releases aren't always/usually backwards-compatible, and you'd be hard-pressed to find people still using much older versions.

Scala releases are usually not BINARY backwards compatible. Very different from SOURCE backwards compatible.

Re: About Python 3

#26
post #7

Python 3 came from a good place, and it definitely fixes many problems that sorely needed fixing, but it was doomed to failure from the start (and many developers said that in 2008 already). For all intents and purposes, Python 3 is pretty much a new, separate programming language. Sure, it's very close to Python 2.x, but you don't have out of the box retro-compatibility so that pretty much kills it right there. Pyth…

This sounds remarkably like Perl 5/6.

I am not at all up-to-date on the Perl side, but Python 3 is real, whereas

> Perl 6 is currently being developed by a team of dedicated and enthusiastic volunteers. (http://perl6.org/)

Re: About Python 3

#27
post #5

Something that might help is OS vendors shipping with 3.x installed, rather than 2.x most seem to. OS X ships with 2.7.5. For a casual python user, sticking with what is there and working is safe, especially when the benefits of 3.x are unclear.

Canonical has been working on making 3.x default for Ubuntu for a while. From https://wiki.ubuntu.com/Python/3

> It is a release goal for Ubuntu 14.04 LTS to have only Python 3 on the desktop CD images. Also, we won't be allowing Python 2 on the Ubuntu touch images.

Re: About Python 3

#28
post #7

Python 3 came from a good place, and it definitely fixes many problems that sorely needed fixing, but it was doomed to failure from the start (and many developers said that in 2008 already). For all intents and purposes, Python 3 is pretty much a new, separate programming language. Sure, it's very close to Python 2.x, but you don't have out of the box retro-compatibility so that pretty much kills it right there. Pyth…

This sounds remarkably like Perl 5/6.

Perl 6 is vaporware. Python 3 is here, it's widely supported, it's faster than Python 2.7, and while Guido didn't do us any favors with his migration strategy, I don't see what the big deal is. Python 3.3 makes writing code that is compatible with both almost trivial.

People aren't using Python 3 enough because it's not the default in Debian/Ubuntu. That's about to change with Ubuntu 14.04. I expect that to tip the scales.

Re: About Python 3

#29
For all its goodness I think it was a mistake to make syntax changes and other non-backward compatible changes in Python 3.

My current projects are currently compatible with Python 3 and it's my main target whenever possible (depending on the dependancies).

But all in all this is one of these little things that make developping in Python less fun than before. This is not my preferred language anymore.

Re: About Python 3

#30
post #22
post #6

I used Python 3 for the first time a few days ago (I've been programming in Python for 18 years). When I used python heavily (I've switched back to C++ and now Go) I depended a lot on a small number of really good libraries- ElementTree, NumPy, SciPy, etc. Unless/until all of those get ported to Python 3 (along with hundreds of other programs), and those ports are considered Correct (in the QA validation sense), it's…

ElementTree has always been in 3.x. I believe NumPy and SciPy are finally making the leap just about now.

That's nice. I don't care.
Post reply on HN