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 28 November 2014 at 02:52, Guido van Rossum wrote:
> On Thu, Nov 27, 2014 at 3:04 AM, Nick Coghlan wrote:
>> If compatibility with older Python versions is needed, then you could
>> put something like the following in a compatibility module:
>>
>> try:
>> from itertools import allo
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
On Thu, Nov 27, 2014 at 3:04 AM, Nick Coghlan wrote:
> On 27 November 2014 at 11:15, Guido van Rossum wrote:
> > On Wed, Nov 26, 2014 at 2:53 PM, Nick Coghlan
> wrote:
> >>
> >> On 27 Nov 2014 06:35, "Guido van Rossum" wrote:
> >>
> >> [...]
> >>
> >> > I think we can put a number to "much fas
On 27 November 2014 at 23:43, Jesus Cea wrote:
> On 27/11/14 13:42, Victor Stinner wrote:
>> 2014-11-27 13:41 GMT+01:00 Victor Stinner :
>>> I am amused about the "/)" suffix in the signature. It happens to all
>>> magic methods.
>>
>> If I remember correctly, it means that the function does not
On 27/11/14 13:42, Victor Stinner wrote:
> 2014-11-27 13:41 GMT+01:00 Victor Stinner :
>> I am amused about the "/)" suffix in the signature. It happens to all
>> magic methods.
>
> If I remember correctly, it means that the function does not accept keywords:
I don't understand. Is that internal
2014-11-27 13:41 GMT+01:00 Victor Stinner :
> I am amused about the "/)" suffix in the signature. It happens to all
> magic methods.
If I remember correctly, it means that the function does not accept keywords:
>>> (3).__lt__(4)
True
>>> (3).__lt__(value=4)
Traceback (most recent call last):
F
2014-11-27 13:41 GMT+01:00 Victor Stinner :
> 2014-11-27 13:28 GMT+01:00 Jesus Cea :
>> http://bugs.python.org/issue20530#msg231584
>
> Copy/paste of the message:
>
> Preparing a presentation about Python Magic methods I found something
> weird: (Python 3.4)
>
> """
help(int.__lt__)
> Help on
2014-11-27 13:28 GMT+01:00 Jesus Cea :
> http://bugs.python.org/issue20530#msg231584
Copy/paste of the message:
Preparing a presentation about Python Magic methods I found something
weird: (Python 3.4)
"""
>>> help(int.__lt__)
Help on wrapper_descriptor:
__lt__(self, value, /) <- THIS!!
Re
http://bugs.python.org/issue20530#msg231584
--
Jesús Cea Avión _/_/ _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/
Twitter: @jcea_/_/_/_/ _/_/_/_/_/
jabber / xmpp:j...@jabber.org _/_/
On 27 November 2014 at 09:50, Guido van Rossum wrote:
> On Wed, Nov 26, 2014 at 3:15 PM, Nick Coghlan wrote:
>> This is actually the second iteration of this bug: the original
>> implementation *always* suppressed StopIteration. PJE caught that one before
>> Python 2.5 was released, but we didn't
On 27 November 2014 at 11:15, Guido van Rossum wrote:
> On Wed, Nov 26, 2014 at 2:53 PM, Nick Coghlan wrote:
>>
>> On 27 Nov 2014 06:35, "Guido van Rossum" wrote:
>>
>> [...]
>>
>> > I think we can put a number to "much faster" now -- 150 nsec per
>> > try/except.
>> >
>> > I have serious misgiv
16 matches
Mail list logo