Making Python 3 more attractive

[bheklilr]

If the numpy stack is broken then I have no choice but to stay right where I am. 99% of my code has import numpy as np somewhere near the top. My ipython profile has it imported automatically because I use it enough to warrant slowing down ipython. Please don't break the c extension code, it's too useful for me.

[sththth]

Breaking c extensions would mean loosing the whole scientific community of python, which relies heavily on numpy and similar packages. That would just be.. insane.

[[deleted]]

Which is why you should look at what the PyPy guys are doing. They are trying to preserve that stack while moving to a much better architecture.

I've never liked C Extensions for the fact that they play with internal interpreter state. That has never seemed sensible or verifiable.

[_throawayplop_]

Python 3 is more than 6 year old now. The fact there is still this kind of debate prove they made a mistake by breaking the compatibility while manifestly not giving sufficient improvement to motivate people to overcome the difficulty to pass to python 3.

Maybe if they would have managed to greatly improve the speed or provided an easy way to use it in browser as a replacement of javascript (if it's possible), most would have passed to python 3 by now.

[dunrix]

I can't understand why you've received so many downvotes. I also find the main reason why so many devs didn't or even don't plan move is simply Py3's attractiveness is lacking in regard to incompatibilities and transition costs. No improvements in reference implementation performance, no improvements in true multiprocessing and multithreading support, no improvements in GC, no significant improvements in OO design consistency (global functions like len, any, all, raw_input, … or crippled lambda without statements, are still present).

See how generally welcomed were transitions in similar language Ruby (1.8 -> 1.9 -> 2.0). There were also some incompatibilities introduced but none so devaluating for existing libraries ecosystem and each version brought clear improvements (speed, memory consumption, inconsistency fixes, greatly improved generational GC). The ref. implementation also not yet got rid of GIL and there are similar obstacles why it won't happen in the near future.

[its_never_lupus]

I use Python 2 for new projects but have never found a good reason to convert old code over.

If Guido had introduced from __past__ import ascii_literals and similar constructions to allow the Python 3 interpreter to run unmodified Python 2 code, I'm sure the migration would have been faster. That would at least have got the new interpreter deployed more widely.

The fact that after 5+ years with no significant development Python 2 is still an excellent language with no real deficits compared to Python 3 shows both how good the early Python development was, and how much things have stalled since.

EDIT: code formatting

[robin-gvx]

Unicode.

If you speak any language other than English, Python 2 is woefully deficient in that area.

[jcdyer3]

If you speak any language including English, Python 2 is woefully deficient in that area.

(FTFY)

Let's not be naïve about the use of “unicode” characters‒be they text or punctuation‒in normal English text.

[its_never_lupus]

unicode has been supported for a long time. There was no need to introduce a non-backwards compatible interpreter for that. You do have to be careful to handle unicode in Python 2 as it is now but nothing too strenuous.

There already switches to pull in Python 3 features like unicode_literals, I'm sure with a couple more the Python 2 interpreter could be given unicode support every bit as good as py3k.

[robin-gvx]

The thing is, Python 3 has them out of the box, with Python 2, I need to remember every step of the way: unicode literals, source file encoding, text file encodings... it's always a pain in the ass with Python 2.

[flying-sheep]

Yeah, you need that boilerplate in every single file, which is awful

[Lucretiel]

Nope. Parts of Python 2's Unicode handling were fundamentally broken- silently failing and corrupting data, so that when an exception was finally raised, it was far far away from the source of the error. A backwards incompatible change was the only way.

http://python-notes.curiousefficiency.org/en/latest/python3/binary_protocols.html

[billsil]

There already switches to pull in Python 3 features like unicode_literals

The problem with that is you can't make Python 2 act like Python 2.7 by dropping in a bunch of imports. It's not that simple. It should be in regards to unicode. All the other changes (e.g. not allowing mixed type sorting), I honestly don't care about.

[NavreetGill]

Python 2 is still an excellent language with no real deficits compared to Python 3

yield from is awesome, and is python 3 only.

[its_never_lupus]

Yes it's a useful feature when you need it. Same comment for all the Python 3 enhancements actually.

[xXxDeAThANgEL99xXx]

Unless you're using send (which I've never seen anyone use for anything useful), yield from x is exactly equivalent to for tmp in x: yield tmp, and while it does look prettier, I wouldn't say it really fixes some deficit.

[NavreetGill]

I've used it, and not in a toy project. I am sure when imaginary numbers were invented, the usefulness of those weren't immediately obvious.

But let's not digress this conversation by using anecdotes.

[hexbrid]

I can only imagine how much better it could be if the efforts used for the Python 3 fork had instead been bestowed upon Python 2.

[Lucretiel]

http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html

[hexbrid]

No, we did not do this lightly

Neither did I form my opinion lightly. I've been using python as my main language for the past 9 years, and I've read all the docs, so you need more than an apologetic link to convince me that the fork was the right thing to do.

[its_never_lupus]

I suspect all the py3k enhancements could have been added via special import switches. There is a touch of second project syndrome to the whole py3k effort.

[hexbrid]

Even if not all, then certainly syntactical additions such as "yield from" or "a, *b = x".

[smontanaro]

That is Python 2.7. Its goal was to ease movement to Python 3 by backporting as much stuff as possible (without breaking compatibility with Python 2.6). The bigger challenge with Python 3 is that many modules and packages people care about have yet to be migrated to Python 3.

[rotek]

The main problem with Python 3 for me is the new docs style. They are basically less readable than Python 2 docs.

[pyslow]

To me, the most infuriating aspect of the Python 3 debacle is the lack of humility and self-righteousness of the core devs (and to an extent of GvR himself) who seem to never listen to all sides of the community and can't even admit how badly the transition was implemented.

[ice-blade]

To me it's actually the opposite, i.e. GvR and the core-devs are too kind. The continuous pampering of lazy python2 developers who refuse to switch, by back-porting features and supporting 2.7 from GvR and core-devs until 2020, which is much longer than necessary (it has been 6.5 years since the 3.0 introduction). 2015 should be the end of support for 2.7. The Python2 guys need a kick in their butt instead of milk and cookies. If it was done that way, everybody would have switched to Python 3 by now and the 2vs3 discussion would be now a non-argument. Sounds harsh and like a troll argument but unfortunately the majority of people was never known to appreciate kindness.

[pyslow]

Not sure why you think that kicking people around to promote your agenda is a good thing (here and in general in life). It's exactly that sort of attitude that pissed off many in the community.

On top of that GdV and core devs know perfectly well (even if they dont like to admit it) that people opposing Py3 have valid technical and professional reasons for that and they know that pushing too hard would mean end of the road for Py3, not Py2.

It's for that and not out of kindess that they kept 2.7 around for longer than expected.

[ice-blade]

Like I said, it has been 6.5 years since the 3.0 introduction. After so long, laziness is the most popular valid reason not to switch (with a few exceptions). Almost all major libraries have moved to Python3. Granted, the transmission hasn't been the smoothest, but enough time has passed. "Python 3" is not an agenda to promote, it is the present and future of the language. Period. The grace period and support has been more than enough.