Is this the final nail in the coffin for Python3? Seems like it.
Who would use 3 if you could have CPython2 for existing code and write new code in Grumpy Python? This is the dream language for me. Python on the Go runtime.
Who would use 3 if you could have CPython2 for existing code and write new code in Grumpy Python? This is the dream language for me. Python on the Go runtime.
I'm hoping it becomes a permanent fork of Python2 that uses the Go runtime. That would really be great and exactly what they've got now.
This leaves us with more than 1 way to do things, like meta-class declaration.
There's a lot in Python 3 where changes were made to the syntax for 'clarity', but those worts weren't removed for any technical reason but because of the thought that since backwards compatability was being broken anyways, then we might as well get the most bang for our buck.
So two `builtin` modules, then?
What if someone does `sys.modules['builtin']`? Or any other kind of explicit string-based lookup?
How does pickle figure out which types to instantiate? There'd be a lot of types with same qualified names but different implementations with this approach...
It feels like the only way this would work reliably, is if you completely isolate the Py2 and Py3 universes. So if you e.g. pickle from Py2 code, it only looks at modules and types that Py2 universe knows, and vice versa.
But then what happens when code using the old library interacts with the new one (e.g. tries to pass objects around)? If that is prohibited, then you effectively still have two different languages, just with a single shared implementation - but no ability to gradually replace bits and pieces of code, for example, which would seem to be the biggest motivation for such a thing.
But the bigger problem other than lack of widescale user adoption is that the primary reason for Python3 (unicode) was botched. Go got this right, everything is a byte string and the assumed encoding is UTF8.