Re: [Python-ideas] Trial balloon: adding variable type declarations in support of PEP 484

[Guido van Rossum]

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 already has a meaning --
> it's a tuple subclass with two extra class attributes
> that are unrelated to its indexable items.
>
> I thought that type annotations weren't meant to change
> runtime semantics?


Correct, but we can invent a new base class that has these semantics. It's
no different from Enum.

Anyway, I think this will have to be an add-on to be designed after the
basics are done.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 525: Asynchronous Generators

[Adam Bartoš]

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 – using
(await) yield from and return.

I found the explanation in the section about async yield from, but maybe a
link to that section might be added as explanation why return produces a
SyntaxError.

In ideal world it seems that the transition from ordinary functions to
generators and the transition from ordinary functions to async functions
(coroutines) are orthogonal, and async gnerators are the natural
combination of both transitions. I thing this is true despite the fact that
async functions are *implemented* on top of generators. I imagine the
situation as follows: being a generator adds an additional output channel –
the one leading to generator consumer, and being an async function adds an
additional output channel for communication with the scheduler. An async
generator somehow adds both these channels.

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 right way. Thank you for that.

Regards, Adam Bartoš
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 525: Asynchronous Generators

[Nick Coghlan]

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 feature it doesn't).
>

Ah, interesting - I'd only ever used it for the "synchronous code that just
wants this *particular* operation to run asynchronously in the current
thread" case, which it handles nicely :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/