On Sat, Nov 29, 2014 at 9:07 AM, Nick Coghlan wrote:
> Guido wrote a specific micro-benchmark for that case in one of the
> other threads. On his particular system, the overhead was around 150
> ns per link in the chain at the point the data processing pipeline was
> shut down. In most scenarios
On 30 November 2014 at 02:45, Olemis Lang wrote:
> On 11/28/14, Guido van Rossum wrote:
> [...]
>>
>> @Olemis: You never showed examples of how your code would be used, so it's
>> hard to understand what you're trying to do and how PEP 479 affects you.
>>
>
> The intention is not to restart the d
On 11/28/14, Guido van Rossum wrote:
[...]
>
> @Olemis: You never showed examples of how your code would be used, so it's
> hard to understand what you're trying to do and how PEP 479 affects you.
>
The intention is not to restart the debate . PEP is approved , it's
done ... but ...
as a side-e
@Victor: I'm glad you found a work-around. Maybe you can let your users
control it with a flag? It is often true that straddling code pays a
performance cost. Hopefully the slight performance dip might be an
incentive for people to start thinking about porting to asyncio.
@Olemis: You never showed
correction ...
On 11/28/14, Olemis Lang wrote:
>
> try:
>...
> except RuntimeError:
>return
>
... should be
{{{#!py
# inside generator function body
try:
...
except StopIteration:
return
}}}
[...]
--
Regards,
Olemis - @olemislc
Apache(tm) Bloodhound contributor
http://issue
off-topic , not about asyncio but related to the PEP and other things
been discussed in this thread
On 11/28/14, Victor Stinner wrote:
> 2014-11-28 3:49 GMT+01:00 Nick Coghlan :
>
[...]
>
> So yes, it may help to have a new specialized exception, even if "it
> works" with RuntimeError.
>
This is
2014-11-28 3:49 GMT+01:00 Nick Coghlan :
> 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.
I modified Trollius to test such idea:
* Return inherits from Exception (not
On Fri, Nov 28, 2014 at 8:18 PM, Victor Stinner
wrote:
> 2014-11-28 10:12 GMT+01:00 Greg Ewing :
>> I don't understand. If I'm interpreting PEP 479 correctly, in
>> 'x = yield from foo', a StopIteration raised by foo.__next__()
>> doesn't get turned into a RuntimeError
>
> The Trollius coroutine u
2014-11-28 10:12 GMT+01:00 Greg Ewing :
> I don't understand. If I'm interpreting PEP 479 correctly, in
> 'x = yield from foo', a StopIteration raised by foo.__next__()
> doesn't get turned into a RuntimeError
The Trollius coroutine uses "raise Return(value)" which is basically a
"raise StopIterat
Guido van Rossum wrote:
The issue here is that asyncio only interprets StopIteration as
returning from the generator (with a possible value), while a Trollius
coroutine must use "raise Return()" to specify a return value;
this works as long as Return is a subclass of StopIteration, but PEP 479
On 28 November 2014 at 08:09, Victor Stinner wrote:
> 2014-11-27 22:54 GMT+01:00 Victor Stinner :
>> 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_don
On Fri, Nov 28, 2014 at 8:54 AM, Victor Stinner
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
2014-11-27 22:54 GMT+01:00 Victor Stinner :
> 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"?
When I talked with a friend about the transition from
2014-11-27 20:06 GMT+01:00 Guido van Rossum :
> The issue here is that asyncio only interprets StopIteration as returning
> from the generator (with a possible value),
I'm not sure that the issue is directly related to asyncio.
trollius_coro() raises a StopIteration to return the result to caller
On Thu, Nov 27, 2014 at 10:08 AM, Victor Stinner
wrote:
> I'm trying to follow the discussion about the PEP 479 (Change
> StopIteration handling inside generators), but it's hard to read all
> messages. I'm concerned by trollius and asyncio which heavily rely on
> StopIteration.
>
> Trollius curr
15 matches
Mail list logo
