[rdtsc]

> The Unicode support that comes with Python 3 is "kind of like eating your vegetables", he said. It is good for you, but it doesn't really excite developers

Saddly I agree with that. There needs to be either a big stick (Python 2 being really bad, but it is actually pretty good) or a large carrot ("Oh look 3x performance improvement!").

Something like a carrot was presented during Pycon and that was gradual types (optional types). These reduce some cases covered by unit tests, make code more readable for new developers, help with IDE support, and of course assist with general static checkers. According to Guido 3.5 should start having a partial support for it.

But in general I would have liked either one of these instead (some are contradictory, arbitrary hard, or downright impossible):

* At least 2-3x performance improvement

* No GIL

* Merge greenlet library in the core (to make eventlet or gevent work)

* Some kind of an ahead of time compiler that bundles just the needed interpreter library parts into an executable

* Firefox and Chrome agree to add browser suport for it

* Mobile support (native Android support or Apple ditches Swift and uses Python instead).

[bjwbell]

Firefox added Python support in the past and there was no uptake. Brendan Eich has a hnews comment on it.

I think 2x-3x perf improvement /is/ possible. I mean we have the example of javascript that went from terrible perf to almost native parity. Of course Mozilla & Google each dedicated an entire team to get there.

We already have the example of PyPy too which /today/ averages a >5x (http://speed.pypy.org/) speed up with CPython!

[juliangregorian]

Looks like this https://news.ycombinator.com/item?id=3096459 is the Brendan Eich comment.

[BrendanEich]

And again, recently:

https://news.ycombinator.com/item?id=9188011

[masklinn]

> I mean we have the example of javascript that went from terrible perf to almost native parity.

It didn't have the ecosystem of C extensibility and mature extensions Python has, which drive much of its adoption in e.g. scientific computing (a big factor for Pypy having trouble making inroads).

[jeffbr13]

> There needs to be either a big stick (Python 2 being really bad, but it is actually pretty good)

Doing any non-ASCII string-processing in Python 2 with any regularity is a more than regular-enough beating for me.

[the_mitsuhiko]

> Doing any non-ASCII string-processing in Python 2 with any regularity is a more than regular-enough beating for me.

Can you elaborate on this? Unicode processing is the same on 2.x and 3.x for the most part. There are some differences in interpreter internals, how string literals are represented and the internal representation was changed (and obviously the literal defaults and bytestrings were removed), but other than that the unicode support is more or less equivalent.

[Matumio]

The big issue with Python2 is that it's easy to accidentally mix unicode and byte strings during development, and it works fine until some user has a non-ascii home directory or similar. You get bugtracker conversations like "it crashes on XP but works on Vista", "I can't find this traceback file you mentioned", "what is a file system encoding?", etc.

Or you write a logfile parser and it works great for half a year, until in March where you get an UnicodeEncodeError because March is "März" in German, the only month with an Umlaut.

[mrweasel]

I strongly disagree, in regards to Unicode. Unicode in Python 3 alone makes it worth switching from Python 2.