[Python-Dev] PEP 479 and asyncio

[Chris Angelico]

On Fri, Nov 28, 2014 at 8:54 AM, Victor Stinner
<victor.stinner at gmail.com> wrote:
> def return_value(value):
>     if 0:
>         yield
>     raise Return(value)

This is one known significant backward-incompatibility issue with this
PEP - it'll be difficult to make this work on Python 2.7, where
"return value" would be a problem, and 3.7, where "raise
StopIteration" would be a problem. At present, I don't know of a
solution to this. In 3.x-only code, you could simply use 'return
value' directly; in 2.7 code, StopIteration doesn't seem to even
*have* a .value attribute (and .args[0] has to be used instead).

But I don't like the idea of a "from __past__" directive. It means
backward-compatibility code has to be maintained through eternity
(otherwise it just shifts the problem to "why did you remove my
__past__ directive, I want a from __paster__ import division"), which
means both the Python implementation code (every Python, not just
CPython) needs to cope, *and* everyone who reads Python code needs to
cope. For python-list, Stack Overflow, and other such coding help
places, this means more questions to ask about a piece of code. For
real-world usage, it means scanning back up to the top of the file
every time you read something that's been affected by a __past__
directive.

Plus, which __future__ directives need __past__ equivalents?
Personally, I wouldn't bother making "from __past__ import
lack_of_with_statement", but your friend is wanting "division", and
I'm sure "print_statement" would be wanted... and, this is the one
that'd split everyone and put the sides to war: "bytes_literals".
Personally, I would want python-dev to say "There will NEVER be a from
__past__ import bytes_literals directive", but there are going to be
others who say "But my code would be so much cleaner AND faster if you
do!", and IMO this is a good reason to avoid having any __past__
directives at all.

ChrisA