[Python-ideas] keywords and backward compatibility
rosuav at gmail.com
Sun May 13 12:58:46 EDT 2018
On Mon, May 14, 2018 at 2:08 AM, Barry Scott <barry at barrys-emacs.org> wrote:
> There seems to be a recurring theme of ideas wanting a new keyword
> but not being able to have one because of backwards compatibility.
> What if I have a way to ask for the new keyword? Would that make it
> easier to accept and implement some of the new ideas?
> The "given" keyword for example could be allow with a statement like:
> from __future__ import keyword_given
> If this method of extending the python language was used for a while
> I can see that the downside would be that an author of a new module
> will end up potentially putting a lot of from __future__ statements as a
A future import always  has a target version beyond which its
effect becomes automatic. For instance, "from __future__ import
generator_stop" means that StopIteration leaking out of a generator
function is an error, but starting with Python 3.7, the altered
behaviour happens whether you have the directive or not. So a future
import does not replace backward compatibility considerations; it
simply allows the feature to be brought in progressively across
The main problem with creating keywords is that APIs get broken. Let's
suppose that I have a module which has "def given(...)" in it. If you
import my module and try to call that function, you have to go to some
crazy shenanigans to avoid writing "mymodule.given()", which isn't
going to work. The point of a future directive is to make changes on a
module-by-module basis; that's fine for some ("division" changes the
byte code created for the slash operator, "print_function" changes the
way the word 'print' is compiled, "generator_stop" flags the generator
function), but not everything can be implemented that way.
Creating a new keyword is still a high cost.
 Except for "barry_as_FLUFL", the April Fools one, although even it
has one, technically. Kinda.
More information about the Python-ideas