Comment by overgard | Hacker News Reader

Comment by overgard | Hacker News Reader

I agree with this 100%.

Python 3 is a disaster. The problem is they made the entire thing out to be a Big Deal, but they didn't really offer any compelling reason to upgrade. I mean, the unicode is... kinda better, and iterators are a bit improved, but couldn't those things have been point releases? 2.8? They basically said that python 3 was a new language, and then offered no significant reason you should use this new language. So we all kept using actual python, quirks and all. To me, as a python developer, Python 3 is a failed fork. Harsh but true.

IMO, if they were going to do that sort of thing, they should have had at least one killer feature. Like maybe if python 3 had been based off pypy they could be saying "Look! We're 5x faster! Want to upgrade now?". That would have been compelling. But their message was: "we cleaned up some stuff that most of you don't care about, and broke a bunch of things". Think about pitching that sort of upgrade to your boss. "Well it doesn't solve any of our problems, and it creates a ton of new ones, but it's the right thing to do because it makes some code slightly cleaner arguably! Convinced yet?"

If I were in charge of python, I would do this: announce python 4, have it be based on the pypy interpreter, and keep compatibility with python 2 the language while reforming the C extension APIs to be more future proof (for getting rid of the GIL and so on). (Or maybe get rid of them entirely and just have people use CFFI.)

"... they should have had at least one killer feature"

Or if Python 3 had included reliable (and updated) package and environment managers; and/or a default GUI framework (QT maybe) - out of the box.

The fragmentation between Python 2 and Python 3 is killing the language. Not to mention the community. Python needs a united front.

> "... they should have had at least one killer feature"

I already commented on it and I agree. Python 2 is great and Python 3 is a little bit greater. But just not better enough to switch.

> Or if Python 3 had included reliable (and updated) package and environment managers;

I remember being at Pycon and distutils2 was announced. There was an aura of coolness, enthusiasm and hope in the air. Someone asked "but what about RPM packages?" they laughed at him and Tarek hid behind the podium in a funny gesture. Years later I am still using the default old included distutils package and building RPMs with it.

> a default GUI framework

Tkinter is Python's "default GUI framework". At least, that's what they continue to claim (https://wiki.python.org/moin/TkInter), and it's the GUI library I ran into first when I first learned Python.

How does it look and feel once you get started? Well, let's just say it's a bad sign if a GUI framework website has no screenshots. Even with increasingly hacky theming engines layered on top, it still is hard to get anything feeling close to native: http://tktable.sourceforge.net/tile/screenshots/macosx.html

Go ahead, you can start laughing...

(for anybody that is saddened by the above, there are thankfully binding libraries for Qt and Wx, both of which do get you fairly decent cross-platform widgets from within Python, and either of which would be better default GUI libraries in 2014.)

People have been making the argument that QT or Wx should be the default for a while, the problem is and remains A: licensing or B: complexity of shipping "batteries included" distributions. For A, PyQT's license might surprise you: [1]. Python can not distribute this with the rest of the essentially-BSD-licensed Python distribution. For B, for instance, none of the linux distributions particularly want "Python", which is often a base requirement, to pull in either of Wx or QT, both of which are quite sizable, and require their own stack of other things to come piling in too.

It's sad, but I'm not sure how to resolve the problem, and nobody else has been either in the past 10 years.

[1]: http://www.riverbankcomputing.com/software/pyqt/license

There's a new alternative to pyqt, though its name escapes me now.

PySide, though PyQt still has certain advantages if you can live with the licensing (which is either GPLv3 or a £350 per developer commercial license).

PySide (thanks lambda) appears to be LGPL; "better" than PyQT, but still not shippable in the core Python distro without changing the license of the core distro.

I think that's as "good" as a QT binding can be, too; QT itself is LPGL (or commercial license).

The solution is to stop shipping with batteries included and let people install via pip. Python could have an official opinion on what the best libraries are (might not be such a bad idea, actually), but they shouldn't bundle them unless they're very, very stable, tested and almost unchanging.

Requests might make a good addition to the standard library at some point. PyQT definitely shouldn't though.

Unrelated:

You do know that pypy also uses GIL.

CFFI is to call C functions from Python. It won't allow you to run C extensions for CPython (something should implement Python C API).

I do know that; although they've done some interesting work with STM recently and hopefully that works out.

I remember in the past hearing about someone actually submitting a patch to cpython remove the GIL about 10 years ago, but it was rejected because it made the language about 2-10x slower. IMO, that decision was INSANE. I have a 16 core machine right now and it can only really use 1/16th of it. Nobody uses python for it's speed, and people that need it are probably using C extension libraries like numpy, so if you were to cut the language's speed in half for a short term I'm going to say that pretty much nobody would care, especially if it were to solve a problem that everybody hates. Ruby is already about 10x slower than python on most of tasks, and it's just not a big deal. GVR is optimizing for the wrong thing.

> Ruby is already about 10x slower than python on most of tasks

No it isn't - both are roughly in the same ballpark. Even before YARV it wasn't anywhere near an order of magnitude in the general case.

Not everyone's needs are the same. I'll not say that my concerns are better than anyone else's (of course), but they're certainly different than yours.

If Python were 10x slower than it is, I'd use Perl. When I started using Python for real (2004), I'd have stuck with Perl if Python had been 2x slower. (Note that I very much dislike Perl, and thought of Python as a nicer Perl when I first learned it.) I care about speed, and I also care about convenience. Python has a very nice balance of the two for me.

On the other hand, I only use threads in one script that I've ever written (and the GIL isn't a problem with it). So I just don't care about the GIL.

(Edit: re-worded second paragraph)

Have you tried multiprocessing? My experience is that people seriously overestimate how expensive processes are, especially on Unixy operating systems.

Reply on news.ycombinator.com