3 ms·

When Python 3 broke compatibility, the Python team did exactly the thing you're supposed to do with code: first they made it correct (i.e., got all the changes

When Python 3 broke compatibility, the Python team did exactly the thing you're supposed to do with code: first they made it correct (i.e., got all the changes implemented and working as expected), then made it fast. "We're doing a huge rewrite already, let's pile on more scope" is a recipe for disaster.

bonzini 9y ago
It depends. It is really surprising that Python does not use tagged integers, which is a 50 year old technique used by pretty much any other dynamic language in existence. Using an extension API breakage as the excuse to introduce them would have made sense, since it also breaks the API. Now they cannot happen until Python 4.
- netheril96 9y ago
  And Guido says he won't break backwards compat again in Python 4 as he has learned the lesson. No tagged integers for life.
  - coldtea 9y ago
    He learned the wrong lesson then. Which wasn't "don't break backwards compatibility", but: 1) If you break it, break it for compelling reasons. 2) If you provide a tool to convert, don't make it as awful as 2to3
  - bonzini 9y ago
    Breaking language backwards-compatibility is one thing; breaking the extension API is less problematic, and breaking the extension ABI is better still.
- cdavid 9y ago
  I believe ABC, one of python's influence, used tagged pointers, but I can't find a quote on this. Not using tagged pointers was a conscientious decision from Guido (see e.g. https://github.com/dropbox/pyston/issues/181#issuecomment-62941865 https://github.com/dropbox/pyston/issues/181#issuecomment-62...) [edited] Something that people often overlook when talking about optimizing python is that the "simplicity" of the C Python API allowed the rich ecosystem of C extensions. GC, tagged pointers, etc... are great, and often used in modern VMs, but they tend to make integration w/ C code more difficult. Without rich C extensions, no numpy, no scipy, no scikit learn, no tensorflow/theano/etc... I am not sure this is completely incidental. [edit 2] Ah, found the quote I remembered about tagged pointers in ABC from Guido: https://mail.python.org/pipermail/python-dev/2004-July/046147.html https://mail.python.org/pipermail/python-dev/2004-July/04614...

bonzini 9y ago

It depends. It is really surprising that Python does not use tagged integers, which is a 50 year old technique used by pretty much any other dynamic language in existence. Using an extension API breakage as the excuse to introduce them would have made sense, since it also breaks the API. Now they cannot happen until Python 4.

netheril96 9y ago
And Guido says he won't break backwards compat again in Python 4 as he has learned the lesson. No tagged integers for life.
- coldtea 9y ago
  He learned the wrong lesson then. Which wasn't "don't break backwards compatibility", but: 1) If you break it, break it for compelling reasons. 2) If you provide a tool to convert, don't make it as awful as 2to3
- bonzini 9y ago
  Breaking language backwards-compatibility is one thing; breaking the extension API is less problematic, and breaking the extension ABI is better still.
cdavid 9y ago
I believe ABC, one of python's influence, used tagged pointers, but I can't find a quote on this. Not using tagged pointers was a conscientious decision from Guido (see e.g. https://github.com/dropbox/pyston/issues/181#issuecomment-62941865 https://github.com/dropbox/pyston/issues/181#issuecomment-62...) [edited] Something that people often overlook when talking about optimizing python is that the "simplicity" of the C Python API allowed the rich ecosystem of C extensions. GC, tagged pointers, etc... are great, and often used in modern VMs, but they tend to make integration w/ C code more difficult. Without rich C extensions, no numpy, no scipy, no scikit learn, no tensorflow/theano/etc... I am not sure this is completely incidental. [edit 2] Ah, found the quote I remembered about tagged pointers in ABC from Guido: https://mail.python.org/pipermail/python-dev/2004-July/046147.html https://mail.python.org/pipermail/python-dev/2004-July/04614...