On 28 November 2014 at 08:09, Victor Stinner <victor.stin...@gmail.com> wrote:
> 2014-11-27 22:54 GMT+01:00 Victor Stinner <victor.stin...@gmail.com>:
>> I don't see how it would work.
>
> If it cannot be fixed, would it make sense to allow trollius to
> continue to work as it currently works with something like "from
> __past__ import generator_dont_stop"?
I think between contextlib and Trollius, the case is starting to be
made for raising an UnhandledStopIteration subclass of RuntimeError,
rather than a generic RuntimeError. We have at least two known cases
now where code that works with generators-as-coroutines has a valid
reason for wanting to distinguish "arbitrary runtime error" from
"unhandled StopIteration exception". While catching RuntimeError and
looking for StopIteration in __cause__ *works*, it feels messier and
harder to explain than just naming the concept by giving it a
dedicated exception type.
Trollius would still need an adapter to be called from asyncio,
though. Something like:
def implicit_stop(g):
try:
yield from g
except UnhandledStopIteration as exc:
return exc.__cause__.value
Then Victor's example would become:
class Return(StopIteration):
pass
def return_value(value):
if 0:
yield
raise Return(value)
def add_one(gen):
value = (yield from gen)
return value + 1
def consume_generator(gen):
while True:
try:
next(gen)
except StopIteration as exc:
return exc.value
gen1 = return_value(3)
if PEP479:
gen1 = implicit_stop(gen1)
gen2 = add_one(gen1)
print(consume_generator(gen2))
> When I talked with a friend about the transition from Python 2 to
> Python 3, he asked me why there was not "from __past__ import
> division". He wants to add this to his code to not have to worry that
> a division may fail "somewhere" in his code.
>
> Maybe it would ease upgrades to newer versions of Python if we
> consider keeping the old behaviour for people who don't have time to
> port their old code (for no immediate benefit), but need to upgrade
> because newer OS only provide newer version of Python.
>
> (What is the cost of keeping the old behaviour: maintain the code and
> runtime overhead?)
The main problem with *never* deprecating anything is an
ever-increasing cognitive burden in learning the language, as well as
losing the ability to read code in isolation without knowing what
flags are in effect.
Currently, folks that only work in Python 3 don't need to know how
division worked in Python 2, or that print was ever a statement, etc.
If those old behaviours could be selectively turned back on, then
everyone would still need to learn them, and you couldn't review code
in isolation any more: there may be a __past__ import at the top of
the module making it do something different.
If organisations really want to let their code bitrot (and stay on the
treadmill of big expensive high risk updates every decade or so), they
can, but they have to do it by running on old versions of Python as
well - that gives maintainers a clear understanding that if they want
to understand the code, they have to know how Python X.Y worked,
rather than being able to assume modern Python.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
