keywords and backward compatibility

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 preamble. Barry

On Mon, May 14, 2018 at 2:08 AM, Barry Scott <barry@barrys-emacs.org> wrote:
A future import always [1] 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 several versions. 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. ChrisA [1] Except for "barry_as_FLUFL", the April Fools one, although even it has one, technically. Kinda.

On Mon, May 14, 2018 at 2:08 AM, Barry Scott <barry@barrys-emacs.org> wrote:
A future import always [1] 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 several versions. 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. ChrisA [1] Except for "barry_as_FLUFL", the April Fools one, although even it has one, technically. Kinda.
participants (2)
-
Barry Scott
-
Chris Angelico