Comment by xi | Hacker News Reader

Comment by xi | Hacker News Reader

Parent Full thread

While each of your individual complains may make sense, as a whole, they are amusingly self-contradictory.

You start with arguing for groundbreaking changes in the semantics and internal API, which practically render every single binary extension obsolete. Then you complain about minor semantics changes that forced you to do simple mechanical conversion.

Don't you think C extension authors would be equally or even more upset at having to rewrite their extensions from scratch? Even with the minimal incompatibilities on the C API level, it took ~2 years to port numpy/scipy, do you believe it would have ever happened if the changes you advocate for were introduced? Well, had the scope of Python 3 included removal of GIL and a JIT compiler, I doubt we had a single release yet while the usage of Python 2.x would be on decline (see the sad story of Perl 6).

Concerning your individual complaints.

It makes no effort to move towards the multicore era -- very minor changes would make the language potentially scale much better.

"Very minor changes"? I seriously doubt it. Besides, I'm sure you didn't miss the announcement: we are already in the "cloud" era. ;)

Print syntax changed.

It was probably done to remove two ugly special forms:

  print foo,
  print >>file, foo

You no longer have the same kind of tuple expansion in function calls.

Doesn't strike me as a good example. It was a problem both for introspection tools and C API, it was discouraged for a long time and hardly in use. I can't believe there's a single tear shed for the loss of it.

Oh. And just to be ass-backwards, we'll call the executable "python" just like in Python 2. If you install Python 3, and scripts begin with #!/usr/bin/python, suddenly your system breaks.

That's what `make altinstall` is for, which is thoroughly documented in the section "Installing multiple versions" of README. If somebody doesn't read installation instructions, perhaps it's their fault after all?

"very hard to optimize", "very minor changes", "seriously broken"

Seriously, it's not very specific. A lot of heat, not enough sense.

> While each of your individual complains may make sense, as a whole, they are amusingly self-contradictory.

I don't think they are. My basic take is that you break compatibility only when you really, really have to, and when it buys something significant. I don't see anything significant that Python 3 buys. I see a bunch of minor changes and tweaks to syntax, some of which are arguably better, and some of which are arguably worse. It's annoying and pointless. We'll have a split community for a decade so that print syntax can be slightly more consistent. Many corporate projects will just never move. On the other hand, it misses the whole multicore/GPGPU era coming up.

> Even with the minimal incompatibilities on the C API level, it took ~2 years to port numpy/scipy, do you believe it would have ever happened if the changes you advocate for were introduced? Well, had the scope of Python 3 included removal of GIL and a JIT compiler, I doubt we had a single release yet while the usage of Python 2.x would be on decline (see the sad story of Perl 6).

Perl 6's problem is that it is not released. It's a research project in language design. Larrry didn't design a target for what he was building, and so it had feature creep, and never shipped. It's got bits and pieces, but even now, it is unfinished. If Perl 6 had been the same language, but designed and shipped quickly, I doubt you would see the same problems (especially given source-level backwards compatibility -- Perl 6 can load Perl 5 modules).

Here, virtually all the development could be done incrementally, with a target design spec (we have models for changes from existing languages like Fortress), and in parallel in Python 2 and 3. I think it would be very possible to bound it in scope.

With regards to SciPy, Numpy, the answer is a resounding hell yes. Right now, the only reason they have for porting to Python 3 is because somebody tells them it is the future. The major problem with Numpy/Scipy for a very large number of users is speed. It is at least an order of magnitude slower than C. If a Python 3 port allowed me to write:

d=[(cos(x), sin(y)) for (x,y) in d]

And Python 3 could either JiT this to run at C speed, or better yet, fork it out to the GPU, I can assure you the porting process would be Numpy's/Scipy's top priority.

> If somebody doesn't read installation instructions, perhaps it's their fault after all?

Not when it's the recommended way of doing it to the point where distributions do it. Right now, you've got a situation where end-users have system installs where Python programs just don't work.

> Seriously, it's not very specific. A lot of heat, not enough sense

Because each of those is an essay, and was beaten to death elsewhere. See the Reddit articles, LWN articles, etc.

Reply on news.ycombinator.com