3 ms·

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 Pyth

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.

int_19h 10y ago
Everyone who likes the numerous new language features, or new syntax for old features, in Python 3?
- BuckRogers 10y ago
  Those can be built into Grumpy if anyone cares to do so. You don't need Python3 for that stuff. Someone, one developer, recently released a Python 2.8 that backported almost every new Python3 feature. 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.
  - int_19h 10y ago
    If you backport every new Python3 feature to Python2, it becomes Python3, by definition.
    - dismantlethesun 10y ago
      It could become Python 2.8, wherein the standard library has both the legacy versions and the new versions, and any cross-compatible syntax is allowed. 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.
      - int_19h 10y ago
        > It could become Python 2.8, wherein the standard library has both the legacy versions and the new versions, and any cross-compatible syntax is allowed. 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.
    - BuckRogers 10y ago
      Except that "Python3" would compile and run Python2 source code. So it would be "Python3" but backwards compatible. Which is exactly what everyone wanted (other than a performance boost).
fletom 10y ago
Python 3 is a more modern, better language, that's why. Hopefully, grumpy will support it soon enough, though it's understandable that they started with 2.7 to support Google's huge older codebase.
- BuckRogers 10y ago
  That's a bit of hyperbole. Python3 is technical churn, not technical innovation. They just stirred the pot and added some features that have no barrier to being added to Python2 and were, with Naftali Harris' Python 2.8. 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.

int_19h 10y ago

Everyone who likes the numerous new language features, or new syntax for old features, in Python 3?

BuckRogers 10y ago
Those can be built into Grumpy if anyone cares to do so. You don't need Python3 for that stuff. Someone, one developer, recently released a Python 2.8 that backported almost every new Python3 feature. 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.
- int_19h 10y ago
  If you backport every new Python3 feature to Python2, it becomes Python3, by definition.
  - dismantlethesun 10y ago
    It could become Python 2.8, wherein the standard library has both the legacy versions and the new versions, and any cross-compatible syntax is allowed. 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.
    - int_19h 10y ago
      > It could become Python 2.8, wherein the standard library has both the legacy versions and the new versions, and any cross-compatible syntax is allowed. 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.
  - BuckRogers 10y ago
    Except that "Python3" would compile and run Python2 source code. So it would be "Python3" but backwards compatible. Which is exactly what everyone wanted (other than a performance boost).

fletom 10y ago

Python 3 is a more modern, better language, that's why. Hopefully, grumpy will support it soon enough, though it's understandable that they started with 2.7 to support Google's huge older codebase.

BuckRogers 10y ago
That's a bit of hyperbole. Python3 is technical churn, not technical innovation. They just stirred the pot and added some features that have no barrier to being added to Python2 and were, with Naftali Harris' Python 2.8. 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.