[Python-ideas] Making it easy to prepare for PEP479

[MRAB]

On 2015-05-18 13:00, Steven D'Aprano wrote:
> On Mon, May 18, 2015 at 11:14:31AM +0300, Ram Rachum wrote:
>> Hi everybody,
>>
>> I just heard about PEP479, and I want to prepare my open-source projects
>> for it.
>>
>> I have no problem changing the code so it won't depend on StopIteration to
>> stop generators, but I'd also like to test it in my test suite. In Python
>> 3.5 I could use `from __future__ import generator_stop` so the test would
>> be real (i.e. would fail wherever I rely on StopIteration to stop a
>> generator). But I can't really put this snippet in my code because then it
>> would fail on all Python versions below 3.5.
>
> Sometimes you have to do things the old fashioned way:
>
> if sys.version_info[:2] < (3, 5):
>      # write test one way
> else:
>      # write test another way
>
> At least it's not a change of syntax :-)
>
> You can also move tests into a separate file that is version specific.
> That's a bit of a nuisance with small projects where you would a single
> test file, but for larger projects there's nothing wrong with splitting
> tests across multiple files.
>
>
>> This makes me think of two ideas:
>>
>> 1. Maybe we should allow `from __future__ import whatever` in code, even if
>> `whatever` wasn't invented yet, and simply make it a no-op? This wouldn't
>> help now but it could prevent these problems in the future.
>
> from __future__ import spelling_mistaek
> # code that depends on spelling_mistake feature will now behave weirdly
>
Suppose I used:

     from __future__ import unicode_literals

in Python 2.5 and it didn't complain.

I'd then be puzzled why my plain string literals weren't Unicode.

>
>> 2. Maybe introduce a way to do `from __future__ import generator_stop`
>> without including it in code? Maybe a flag to the `python` command? (If
>> something like this exists please let me know.)
>
> I don't think that is important enough to require either an environment
> variable or a command line switch.
>