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
Hi,
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 currently supports running asyncio coroutines: a trollius
coroutine
16 matches
Mail list logo
