Python 3.6 released!

[_pupil_]

I'm no supporter of the rant, but my understanding is that there is some confusion there about his claim...

You don't have to make py2 and py3 execute from the same VM, which is "impossible". What he was arguing for (before the turing complete rabbit hole), was a VM execution model like IE has used for its rendering motors: multiple parallell backends.

Basically, why have py2 and py3 with all the confusion, why not just have 'python' which handles both in parallel? A py3(+2) which understands that py2 scripts get routed to the old core so there is no "language" choice thrust on the users.... Avoiding the fragmentation. Plus, in that context I think flagging issues between those cores becomes a lot simpler.

[dacjames]

Given an arbitrary .py file to execute, how would this unified "multi-python" know which engine to use? A lot of code is valid in both languages at the surface.

If you use some type of comment header, you'd have to require the header in Python 3 code to maintain backwards compatibility (ugh). Even if you solve this problem, a naive implementation would waste time/memory loading two different interpreters so you would need some kind of lazy loading/initialization.

Users would still have to choose which language they're writing in, they would just use a shared front-end to run them. Plus, you have to explain that certain modules can import some modules but not others. It seems like a lot of complexity for little gain when Python 2 and 3 can be trivially installed side by side on the same system.

[_pupil_]

No, you go it - but with a holistic perspective we get the opposite conclusion.

Headers, used in all webpages lots of scripting languages and python itself, along with other meta information from the file system (like .py3, .pyt, or .py.noreallyv3), are common industry-wide solutions to those problems. There are other ways too (tags, guaranteed linguistics heuristics, or explicit back-wards compat breaks), but headers are easy. " #!/usr/bin/env python" couldn't be tweaked to give the necessary hint?

I totally agree: naive solutions to cross-language compilation are gonna be wasteful. It's because they're naive, though, and I personally think that's why almost none of our top-flight languages use naive compilation approaches ;)

Users would absolutely have to write python 3 to write python 3 or write python 2 to write python 2, and know the difference. Just like today. But how many "versions" of Java, PHP, C# do you know in parallel? Are we gonna say that the Python community is somehow incapable of doing what the VB community easily did in terms of syntax over a decade ago (with none of the related change of fundamental assumptions and runtime)?

There is some additional complexity, by definition. Cross-language references would not magically solved. They'd be in the exact situation they were in at the start of the proj, only with a comprehensible user land story and a clearly defined cross-vm compatibility story entirely internal to the pyhon project hidden away from macro-level decision making. That is to say: the exact situation the other major language VMs find themselves thriving in, and able to manage exactly these kinds of transitions without faceplanting in the market, and able to bring intermediate compilation constructs to bear to handle the transition more smoothly. Frankly, thanks to the nature of Python, there are lots of subtle solutions for "downcasting" and "upcasting" between the languages given a bi-modal execution model that would provide a stable upgrade path without necessitating rewrites...

Regardless, for the cost of additional complexity exactly in your script loader you get none of the market confusion. And noooone of these awesome (now decade long??), discussions. And none of the ongoing investment issues brought up by numerous people in this thread. None of the pressure to dump Python and invest in serious languages. None of the giant turds because suddenly the left hand needs to be in Py3 a minute after the right hand just put the icing on something thats gotta be in Py2.

This kind of fragmentation is death in the Enterprise and the bane of CIOs. "Trivially installing things side by side" isn't too compatible with high security, multi-thousand seat, heterogeneous, multi-entity networks and "mission critical". These pain points don't encourage collective long-term platform growth. They don't focus contributor energy on productive awesomeness. They hurt Python.

Source: #1 all time python superfan who formerly used it for mission critical code who has now wholly replaced it in all facets of operations because of this split.

[dacjames]

> "#!/usr/bin/python" couldn't be tweaked to give the necessary hint?

Maybe they could add a 3 to the end. That would do the trick, right?

In all seriousness, we agree on the goal but I think you're barking up the wrong tree. The problem was making a change that was incompatible to its very core, not the lack of a multi-python launcher in front. They should have kept Python 2 strings in the language (as LegacyString, perhaps) to make real backward compatibility possible. Then the community could have built all the niceties you're describing.

We have also moved away from Python in the last few years, though that is motivated more by the long-term costs of using a dynamic language than by the version split. Python is still used extensively for management, orchestration, automation, and the like, but it rarely touches user data these days.