[Python-Dev] ABCs - Re: PEP 492: async/await in Python; version 4

Stefan Behnel schrieb am 02.05.2015 um 06:54: > Yury Selivanov schrieb am 01.05.2015 um 20:52: >> I don't like the idea of combining __next__ and __anext__. > > Ok, fair enough. So, how would you use this new protocol manually then? > Say, I already know that I won't need to await the next item th

Re: [Python-Dev] PEP 492 quibble and request

Guido van Rossum wrote: On Sat, May 2, 2015 at 1:18 PM, Arnaud Delobelle > wrote: Does this mean that somehow "await x" guarantees that the coroutine will suspend at least once? No. First, it's possible for x to finish without yielding. But even if x yield

Re: [Python-Dev] PEP 492 and types.coroutine

Ethan, at this point your continued arguing is not doing anybody anything good. Please stop. On Sat, May 2, 2015 at 2:31 PM, Ethan Furman wrote: > On 05/02, Yury Selivanov wrote: > > On 2015-05-02 2:14 PM, Ethan Furman wrote: > >> On 05/02, Yury Selivanov wrote: > >>> On 2015-05-02 1:04 PM, Etha

Re: [Python-Dev] PEP 492 and types.coroutine

On 05/02, Yury Selivanov wrote: > On 2015-05-02 2:14 PM, Ethan Furman wrote: >> On 05/02, Yury Selivanov wrote: >>> On 2015-05-02 1:04 PM, Ethan Furman wrote: >> And yet in current asyncio code, random generators can be accepted, and not >> even the current asyncio.coroutine wrapper can gaurantee

Re: [Python-Dev] PEP 492 quibble and request

On Sat, May 2, 2015 at 1:18 PM, Arnaud Delobelle wrote: > On 1 May 2015 at 20:59, Guido van Rossum wrote: > > On Fri, May 1, 2015 at 12:49 PM, Ron Adam wrote: > >> > >> > >> Another useful async function might be... > >> > >>async def yielding(): > >>pass > >> > >> In a routine is t

Re: [Python-Dev] PEP 492 quibble and request

On 05/02/2015 04:18 PM, Arnaud Delobelle wrote: On 1 May 2015 at 20:59, Guido van Rossum wrote: >On Fri, May 1, 2015 at 12:49 PM, Ron Adam wrote: >> >> >>Another useful async function might be... >> >>async def yielding(): >>pass >> >>In a routine is taking very long time, just in

Re: [Python-Dev] PEP 492 and types.coroutine

On 2015-05-02 2:14 PM, Ethan Furman wrote: On 05/02, Yury Selivanov wrote: On 2015-05-02 1:04 PM, Ethan Furman wrote: If I'm understanding this correctly, type.coroutine's only purpose is to add a flag to a generator object so that await will accept it. This raises the question of why can't

Re: [Python-Dev] Unicode literals in Python 2.7

I think I have found out where the problem is. In fact, the encoding of the interactive input is determined by sys.stdin.encoding, but only in the case that it is a file object (see https://hg.python.org/cpython/file/d356e68de236/Parser/tokenizer.c#l890 and the implementation of tok_stdin_decode).

Re: [Python-Dev] PEP 492 and types.coroutine

On 05/02, Yury Selivanov wrote: > On 2015-05-02 1:04 PM, Ethan Furman wrote: >> If I'm understanding this correctly, type.coroutine's only purpose is to add >> a flag to a generator object so that await will accept it. >> >> This raises the question of why can't await simply accept a generator >>

Re: [Python-Dev] PEP 492 and types.coroutine

On 2015-05-02 1:04 PM, Ethan Furman wrote: According to https://www.python.org/dev/peps/pep-0492/#id31: The [types.coroutine] function applies CO_COROUTINE flag to generator-function's code object, making it return a coroutine object. Further down in https://www.python.org/dev/peps/pep

[Python-Dev] PEP 492 and types.coroutine

According to https://www.python.org/dev/peps/pep-0492/#id31: The [types.coroutine] function applies CO_COROUTINE flag to generator-function's code object, making it return a coroutine object. Further down in https://www.python.org/dev/peps/pep-0492/#id32: [await] uses the yield from imp

Re: [Python-Dev] Unicode literals in Python 2.7

Adam Bartoš writes: > I'll describe my picture of the situation, which might be terribly wrong. > On Linux, in a typical situation, we have a UTF-8 terminal, > PYTHONENIOENCODING=utf-8, GNU readline is used. When the REPL wants input > from a user the tokenizer calls PyOS_Readline, which calls

[Python-Dev] Sub-claasing pathlib.Path seems impossible

Hello. In this post , I have noticed a problem with the following code. from pathlib import Path > class PPath(Path): > def __init__(self, *args, **kwargs): > super().__init__(

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Out of curiosity, how much of a breaking change would making unary operators stack arbitrarily be? On 4/30/2015 23:57, Nathaniel Smith wrote: On Apr 30, 2015 8:40 PM, "Guido van Rossum" > wrote: > > On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith

Re: [Python-Dev] What's missing in PEP-484 (Type hints)

* Dima Tisnek [2015-04-30 13:41:53 +0200]: > # lambda > Not mentioned in the PEP, omitted for convenience or is there a rationale? > f = lambda x: None if x is None else str(x ** 2) > Current syntax seems to preclude annotation of `x` due to colon. > Current syntax sort of allows lamba return type

Re: [Python-Dev] PEP 492: What is the real goal?

Hello, On Thu, 30 Apr 2015 18:53:00 +1200 Greg Ewing wrote: > Skip Montanaro wrote: > > According to Wikipedia , > > term "coroutine" was first coined in 1958, so several generations > > of computer science graduates will be familiar with the textbook > >

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On 1 May 2015 at 20:24, Yury Selivanov wrote: > On 2015-05-01 3:19 PM, Ethan Furman wrote: [...] >> If we must have __aiter__, then we may as well also have __anext__; >> besides >> being more consistent, it also allows an object to be both a normol >> iterator >> and an asynch iterator. > > > And

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On 1 May 2015 at 21:27, Yury Selivanov wrote: > On 2015-05-01 4:24 PM, Arnaud Delobelle wrote: >> >> On 1 May 2015 at 20:24, Yury Selivanov wrote: >>> >>> On 2015-05-01 3:19 PM, Ethan Furman wrote: >> >> [...] If we must have __aiter__, then we may as well also have __anext__; besi

Re: [Python-Dev] PEP 492: What is the real goal?

On 29 April 2015 at 20:42, Yury Selivanov wrote: > Everybody is pulling me in a different direction :) > Guido proposed to call them "native coroutines". Some people > think that "async functions" is a better name. Greg loves > his "cofunction" term. > > I'm flexible about how we name 'async def