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

[Joao S. O. Bueno]

Indeed - importing as NOP would surely be broken -

The nice fix would be to be able to do
from __future__ import jaberwock

and have a plain "ImportError" that could be catched.

But, as Chris Angelico put it, it might be complicated.
Manually testing sys.version seens to be the way to go
Because,  even if making __future__ imports raise
ImportError, taht would also only be available from
Py 3.5/3.6 onwards.

(Otherwise
from __future__ import from__future__import_ImportError
seens fun enough to actually be created)



On 18 May 2015 at 10:16, MRAB <python at mrabarnett.plus.com> wrote:
> 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.
>>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/