On 9 August 2016 at 13:27, Guido van Rossum wrote:
> Just don't oversell run_until_complete() -- some people coming from
> slightly different event loop paradigms expect to be able to pump for
> events at any point, possibly causing recursive invocations. That doesn't
> work here (and it's a feat
Hello,
when I was reading the PEP, it surprised me that return is not allowed in
an async generator. You can transparently decompose an ordinary function,
and yield from was added to be able to do the same with generators, so it
seems natural to be able to decompose async generators the same way –
On Mon, Aug 8, 2016 at 11:17 PM, Greg Ewing
wrote:
> אלעזר wrote:
>
>> class Starship(tuple):
>> damage: int = 0 captain: str = "Kirk"
>>
>> Is an obvious syntax for
>> Starship = NamedTuple('Starship', [('damage', int), ('captain', str)])
>>
>
> But the untyped version of that alre
On 2016-08-09 10:18 AM, Adam Bartoš wrote:
[..]
I understand that having the concepts truly ortogonal would mean tons
of work, I just think it's pity that something natural doesn't work
only because of implementation reasons. However, introducing async
generators is an important step in the r
On Tue, Aug 9, 2016 at 7:13 AM, Nick Coghlan wrote:
>
> On 9 August 2016 at 13:27, Guido van Rossum wrote:
>
>> Just don't oversell run_until_complete() -- some people coming from
>> slightly different event loop paradigms expect to be able to pump for
>> events at any point, possibly causing re
Hi Yury,
Thank you for posting this PEP!
As an asyncio-based libraries user, author and contributor I
appreciate that topic of easy-writing of asynchronous generators is
being covered now.
I like how simple writing of async generators will be with this PEP,
same with consequent functionality (e.g.
Hi Vladimir,
On 2016-08-09 1:24 PM, Vladimir Rutsky wrote:
Hi Yury,
Thank you for posting this PEP!
As an asyncio-based libraries user, author and contributor I
appreciate that topic of easy-writing of asynchronous generators is
being covered now.
I like how simple writing of async generators
It's already possible to overload NamedTuple, in a way that will allow the
following abuse of notation:
@NamedTuple
def Starship(damage:int, captain:str): pass
The 'def' is unfortunate and potentially confusing (although it *is* a
callable definition), and the ": pass" is meaningless. But
Is this idea still alive?
Despite the bike shedding, I think that some level of consensus may have
been reached. So I suggest that either Neil (because it was your idea) or
Steven (because you've had a lot of opinions, and done a lot of the
homework) or both, of course, put together a reference im
FWIW. I first opined that people should just write their own utility
function. However, there are enough differences of opinion about the right
semantics that I support it being in the standard library now.
Those decisions may or may not be made the way I most prefer, but I think
an "official beha
On Tue, Aug 9, 2016 at 3:47 PM, אלעזר wrote:
> It's already possible to overload NamedTuple, in a way that will allow the
> following abuse of notation:
>
> @NamedTuple
> def Starship(damage:int, captain:str): pass
>
> The 'def' is unfortunate and potentially confusing (although it *is* a
On Tue, Aug 09, 2016 at 03:42:12PM -0700, Chris Barker wrote:
> Is this idea still alive?
>
> Despite the bike shedding, I think that some level of consensus may have
> been reached. So I suggest that either Neil (because it was your idea) or
> Steven (because you've had a lot of opinions, and don
On 08/09/2016 05:05 PM, Steven D'Aprano wrote:
On Tue, Aug 09, 2016 at 03:42:12PM -0700, Chris Barker wrote:
Is this idea still alive?
Despite the bike shedding, I think that some level of consensus may have
been reached. So I suggest that either Neil (because it was your idea) or
Steven (bec
Thank you!
On Tuesday, August 9, 2016 at 8:07:54 PM UTC-4, Steven D'Aprano wrote:
>
> On Tue, Aug 09, 2016 at 03:42:12PM -0700, Chris Barker wrote:
> > Is this idea still alive?
> >
> > Despite the bike shedding, I think that some level of consensus may have
> > been reached. So I suggest that
I just stumble upon on this precise use case yesterday, I solved it
unsatisfactorily by the following code (inlined)
value = max(lower, value)
value = min(upper, value)
So It's certainly a good thing to have
___
Python-ideas mailing list
Python-ideas@py
15 matches
Mail list logo
