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

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 definition. If your use of "coroutine" matches the textbook definition of the

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

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. Not the term, the *idea*. But PEP 492 is not based on that idea, so I don't a

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

Nathaniel Smith wrote: (I suspect this may also be the impetus behind Greg's request that it just be treated the same as unary minus. IMHO it matters much more that the rules be predictable and teachable than that they allow or disallow every weird edge case in exactly the right way.) Exactly

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

Paul Moore wrote: I agree. While I don't use coroutines/asyncio, and I may never do so, I will say that I find Python's approach very difficult to understand. Well, I tried to offer something easier to understand. The idea behind PEP 3152 is that writing async code should be just like writing t

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

Belt and suspenders. :-) We may need help with the implementation though -- PEP 479 is still waiting on implementation help with __future__ too AFAIK. On Wed, Apr 29, 2015 at 8:01 PM, Nick Coghlan wrote: > On 30 April 2015 at 12:31, Guido van Rossum wrote: > > On Wed, Apr 29, 2015 at 7:07 PM,

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

On 2015-04-29 11:01 PM, Nick Coghlan wrote: On 30 April 2015 at 12:31, Guido van Rossum wrote: >On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan wrote: >> >>[...] >>Yeah, I'm coming around to the idea. For the async pseudo-keyword, I >>can see that the proposal only allows its use in cases that

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

On 30 April 2015 at 12:31, Guido van Rossum wrote: > On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan wrote: >> >> [...] >> Yeah, I'm coming around to the idea. For the async pseudo-keyword, I >> can see that the proposal only allows its use in cases that were >> previously entirely illegal, but I'm

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

On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan wrote: > [...] > Yeah, I'm coming around to the idea. For the async pseudo-keyword, I > can see that the proposal only allows its use in cases that were > previously entirely illegal, but I'm not yet clear on how the PEP > proposes to avoid changing t

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

Nick, On 2015-04-29 9:52 PM, Nick Coghlan wrote: On 30 April 2015 at 10:33, Yury Selivanov wrote: To really understand all implementation details of this line you need to read PEP 3156 and experiment with asyncio. There is no easier way, unfortunately. I can't add a super detailed explanation

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

One more thing to discuss: 7. StopAsyncIteration vs AsyncStopIteration. I don't have a strong opinion on this, I prefer the former because it reads better. There was no consensus on which one we should use. Thanks, Yury ___ Python-Dev mailing list P

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

On 30 April 2015 at 11:12, Guido van Rossum wrote: > On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan wrote: >> It is also makes things more painful than they need to be for syntax >> highlighters. > > Does it? Do highlighters even understand __future__ imports? I wouldn't mind > if a highlighter al

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

On 30 April 2015 at 10:33, Yury Selivanov wrote: > To really understand all implementation details of this line > you need to read PEP 3156 and experiment with asyncio. There > is no easier way, unfortunately. I can't add a super detailed > explanation how event loops can be implemented in PEP 49

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

On Thu, Apr 30, 2015 at 11:03 AM, Stephen J. Turnbull wrote: > Note that even if you have a UTF-8 input source, some users are likely > to be surprised because IIRC Python doesn't canonicalize in its > codecs; that is left for higher-level libraries. Linux UTF-8 is > usually NFC normalized, while

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

Hi python-dev, New version of the PEP is attached. Summary of updates: 1. Terminology: - *native coroutine* term is used for "async def" functions. - *generator-based coroutine* term is used for PEP 380 coroutines used in asyncio. - *coroutine* is used when *native coroutine* or *generator b

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

On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan wrote: > On 30 April 2015 at 10:21, Ethan Furman wrote: > > From the PEP: > > > >> Why not a __future__ import > >> > >> __future__ imports are inconvenient and easy to forget to add. > > > > That is a horrible rationale for not using an import. By

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

Adam Bartoš writes: > I am in Windows and my terminal isn't utf-8 at the beginning, but I > install custom sys.std* objects at runtime and I also install > custom readline hook, IIRC, on the Linux console and in an uxterm, PYTHONIOENCODING=utf-8 in the environment does what you want. (Can't t

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

On 30 April 2015 at 10:21, Ethan Furman wrote: > From the PEP: > >> Why not a __future__ import >> >> __future__ imports are inconvenient and easy to forget to add. > > That is a horrible rationale for not using an import. By that logic we > should have everything in built-ins. ;) It is also ma

[Python-Dev] Clarification of PEP 476 "opting out" section

Hi folks, This is just a note to highlight the fact that I tweaked the "Opting out" section in PEP 476 based on various discussions I've had over the past few months: https://hg.python.org/peps/rev/dfd96ee9d6a8 The notable changes: * the example monkeypatching code handles AttributeError when lo

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

Hi Ethan, On 2015-04-29 8:21 PM, Ethan Furman wrote: From the PEP: Why not a __future__ import __future__ imports are inconvenient and easy to forget to add. That is a horrible rationale for not using an import. By that logic we should have everything in built-ins. ;) Working example .

[Python-Dev] PEP 492 quibble and request

>From the PEP: > Why not a __future__ import > > __future__ imports are inconvenient and easy to forget to add. That is a horrible rationale for not using an import. By that logic we should have everything in built-ins. ;) > Working example > ... The working example only uses async def and a

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

On Wed, Apr 29, 2015 at 5:05 PM, Yury Selivanov wrote: > Nathaniel, > > On 2015-04-29 7:58 PM, Nathaniel Smith wrote: >> >> On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov >> wrote: >>> >>> Nathaniel, >>> >>> On 2015-04-29 7:35 PM, Nathaniel Smith wrote: What I do feel strongly about >>

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

Nathaniel, On 2015-04-29 7:58 PM, Nathaniel Smith wrote: On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov wrote: Nathaniel, On 2015-04-29 7:35 PM, Nathaniel Smith wrote: What I do feel strongly about is that whatever syntax we end up with, there should be*some* accurate human-readable descrip

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

Guido, On 2015-04-29 7:52 PM, Guido van Rossum wrote: On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov wrote: Nathaniel, On 2015-04-29 7:35 PM, Nathaniel Smith wrote: What I do feel strongly about is that whatever syntax we end up with, there should be*some* accurate human-readable descript

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

On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov wrote: > Nathaniel, > > On 2015-04-29 7:35 PM, Nathaniel Smith wrote: >> >> What I do feel strongly about >> is that whatever syntax we end up with, there should be*some* >> accurate human-readable description of*what it is*. AFAICT the PEP >> curren

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

On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov wrote: > Nathaniel, > > On 2015-04-29 7:35 PM, Nathaniel Smith wrote: > >> What I do feel strongly about >> is that whatever syntax we end up with, there should be*some* >> accurate human-readable description of*what it is*. AFAICT the PEP >> curren

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

Nathaniel, On 2015-04-29 7:35 PM, Nathaniel Smith wrote: What I do feel strongly about is that whatever syntax we end up with, there should be*some* accurate human-readable description of*what it is*. AFAICT the PEP currently doesn't have that. How to define human-readable description of how u

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

On Wed, Apr 29, 2015 at 3:46 PM, Greg Ewing wrote: > Yury Selivanov wrote: >> >> I'm not sure >> why Greg is pushing his Grammar idea so aggressively. > > > Because I believe that any extra complexity in the grammar > needs a very strong justification. It's complexity in the > core language, like

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

On Wed, Apr 29, 2015 at 3:46 PM, Greg Ewing wrote: > Yury Selivanov wrote: > >> I'm not sure >> why Greg is pushing his Grammar idea so aggressively. >> > > Because I believe that any extra complexity in the grammar > needs a very strong justification. It's complexity in the > core language, like

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

Greg, On 2015-04-29 6:46 PM, Greg Ewing wrote: Yury Selivanov wrote: Won't that prevent some existing generator-based coroutines (ones not decorated with @coroutine) from calling ones implemented with 'async def'? It would. But that's not a backwards compatibility issue. It seems to go ag

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

Greg, On 2015-04-29 6:46 PM, Greg Ewing wrote: Yury Selivanov wrote: I'm not sure why Greg is pushing his Grammar idea so aggressively. Because I believe that any extra complexity in the grammar needs a very strong justification. It's complexity in the core language, like a new keyword, so it

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

Yury Selivanov wrote: I'm not sure why Greg is pushing his Grammar idea so aggressively. Because I believe that any extra complexity in the grammar needs a very strong justification. It's complexity in the core language, like a new keyword, so it puts a burden on everyone's brain. Saying "I do

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

Yury Selivanov wrote: Won't that prevent some existing generator-based coroutines (ones not decorated with @coroutine) from calling ones implemented with 'async def'? It would. But that's not a backwards compatibility issue. It seems to go against Guido's desire for the new way to be a 100%

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

On 2015-04-29 3:24 PM, Isaac Schwabacher wrote: On 15-04-29, Yury Selivanov wrote: Hi Ethan, [..] So I want to make this syntactically incorrect: Does this need to be a syntax error? -"hello" raises TypeError because str doesn't have a __neg__, but there's no reason a str subclass couldn'

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 :) Sorry :-) > Guido proposed to call them "native coroutines". Some people > think that "async functions" is a better name. Greg loves > his "cofunction" term. If it helps, ignore my opinion -

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

Maybe it would help to refer to PEP 342, which first formally introduced the concept of coroutines (as a specific use case of generators) in Python. Personally I don't care too much which term the PEP uses, as logn as it defines its terms. The motivation is already clear to me; it's the details tha

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

On Wed, Apr 29, 2015 at 1:14 PM, Skip Montanaro wrote: > > On Wed, Apr 29, 2015 at 2:42 PM, Yury Selivanov > wrote: >> >> Anyways, I'd be OK to start using a new term, if "coroutine" is >> confusing. > > > According to Wikipedia, term "coroutine" was first coined in 1958, so > several generations

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

On Wed, Apr 29, 2015 at 2:42 PM, Yury Selivanov wrote: > Anyways, I'd be OK to start using a new term, if "coroutine" is > confusing. > According to Wikipedia , term "coroutine" was first coined in 1958, so several generations of computer science graduates

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

Paul, On 2015-04-29 3:19 PM, Paul Moore wrote: On 29 April 2015 at 19:42, Yury Selivanov wrote: Here's how it might look like (this is the same pseudo-code but tailored for PEP 492, not a real something) q = asyncio.Queue(maxsize=100) async def produce(): # you might want to wra

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

Hi Nathaniel, BTW, I'm going to reply to you in the other thread about context-local objects soon. I have some thoughts on the topic. On 2015-04-29 3:14 PM, Nathaniel Smith wrote: On Apr 29, 2015 11:49 AM, "Yury Selivanov" wrote: Hi Ethan, On 2015-04-29 2:32 PM, Ethan Furman wrote: On 04/

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

On 29 April 2015 at 19:42, Yury Selivanov wrote: > Here's how it might look like (this is the same pseudo-code > but tailored for PEP 492, not a real something) > > q = asyncio.Queue(maxsize=100) > > async def produce(): > # you might want to wrap it all in 'while True' I think the "loo

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

I am in Windows and my terminal isn't utf-8 at the beginning, but I install custom sys.std* objects at runtime and I also install custom readline hook, so the interactive loop gets the input from my stream objects via PyOS_Readline. So when I enter u'α', the tokenizer gets b"u'\xce\xb1'", which is

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

On Apr 29, 2015 11:49 AM, "Yury Selivanov" wrote: > > Hi Ethan, > > > On 2015-04-29 2:32 PM, Ethan Furman wrote: >> >> On 04/29, Yury Selivanov wrote: >>> >>> On 2015-04-29 1:25 PM, Ethan Furman wrote: cannot also just work and be the same as the parenthesized version. >>> >>> Becau

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

Hi Ethan, On 2015-04-29 2:32 PM, Ethan Furman wrote: On 04/29, Yury Selivanov wrote: On 2015-04-29 1:25 PM, Ethan Furman wrote: cannot also just work and be the same as the parenthesized version. Because it does not make any sense. I obviously don't understand your position that "it does not

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

On 29 April 2015 at 19:32, Ethan Furman wrote: > On 04/29, Yury Selivanov wrote: >> On 2015-04-29 1:25 PM, Ethan Furman wrote: >>> cannot also just work and be the same as the parenthesized >>> version. >> >> Because it does not make any sense. > > I obviously don't understand your position that "

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

Hi Paul, On 2015-04-29 2:26 PM, Paul Moore wrote: On 29 April 2015 at 18:43, Jim J. Jewett wrote: Rationale and Goals === Current Python supports implementing coroutines via generators (PEP 342), further enhanced by the ``yield from`` syntax introduced in PEP 380. This approac

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

On 04/29, Yury Selivanov wrote: > On 2015-04-29 1:25 PM, Ethan Furman wrote: >> cannot also just work and be the same as the parenthesized >> version. > > Because it does not make any sense. I obviously don't understand your position that "it does not make any sense" -- perhaps you could explain a

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

On 29 April 2015 at 18:43, Jim J. Jewett wrote: >> Rationale and Goals >> === >> >> Current Python supports implementing coroutines via generators (PEP >> 342), further enhanced by the ``yield from`` syntax introduced in PEP >> 380. This approach has a number of shortcomings: >> >>

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

Hi Jim, On 2015-04-29 1:43 PM, Jim J. Jewett wrote: On Tue Apr 28 23:49:56 CEST 2015, Guido van Rossum quoted PEP 492: Rationale and Goals === Current Python supports implementing coroutines via generators (PEP 342), further enhanced by the ``yield from`` syntax introduced in

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

On Wed, Apr 29, 2015 at 09:40:43AM -0700, Guido van Rossum wrote: > I suspect the interactive session is *not* always in UTF8. It probably > depends on the keyboard mapping of your terminal emulator. I imagine in > Windows it's the current code page. Even worse: in w32 it can be an OEM codepa

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

Ethan, On 2015-04-29 1:25 PM, Ethan Furman wrote: cannot also just work and be the same as the parenthesized version. Because it does not make any sense. Yury ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/

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

On Tue Apr 28 23:49:56 CEST 2015, Guido van Rossum quoted PEP 492: > Rationale and Goals > === > > Current Python supports implementing coroutines via generators (PEP > 342), further enhanced by the ``yield from`` syntax introduced in PEP > 380. This approach has a number of short

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

On 04/29, Yury Selivanov wrote: > On 2015-04-29 11:29 AM, Ethan Furman wrote: >> Python is not lisp, and await is not a >> function, so parens should not be needed in the common case. > > Which common case you mean? The common case of not wanting to write parenthesis. ;) Seriously, why are the

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

I suspect the interactive session is *not* always in UTF8. It probably depends on the keyboard mapping of your terminal emulator. I imagine in Windows it's the current code page. On Wed, Apr 29, 2015 at 9:19 AM, Adam Bartoš wrote: > Yes, that works for eval. But I want it for code entered during

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

— Sent from Mailbox On Wednesday Apr 29, 2015 at 7:14 PM, Yury Selivanov , wrote:Also please see this: https://hg.python.org/peps/rev/d048458307b7 FWIW, 'await await fut' isn't something that you likely to see in your life; 'await -fut' is 99.999% just a bug. Agree.​ I'm not sure why G

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

Yes, that works for eval. But I want it for code entered during an interactive session. >>> u'α' u'\xce\xb1' The tokenizer gets b"u'\xce\xb1'" by calling PyOS_Readline and it knows it's utf-8 encoded. But the result of evaluation is u'\xce\xb1'. Because of how eval works, I believe that it would

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

Also please see this: https://hg.python.org/peps/rev/d048458307b7 FWIW, 'await await fut' isn't something that you likely to see in your life; 'await -fut' is 99.999% just a bug. I'm not sure why Greg is pushing his Grammar idea so aggressively. Yury On 2015-04-29 11:33 AM, Yury Selivanov wrot

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

Ethan, On 2015-04-29 11:29 AM, Ethan Furman wrote: Python is not lisp, and await is not a function, so parens should not be needed in the common case. Which common case you mean? Please see this table https://www.python.org/dev/peps/pep-0492/#syntax-of-await-expression Yury ___

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

On 04/29, Yury Selivanov wrote: > On 2015-04-29 5:12 AM, Greg Ewing wrote: >> Yury Selivanov wrote: >>> Looking at the grammar -- the only downside of the current >>> approach is that >>> you can't do 'await await fut'. I still think that it reads better with >>> parens. If we put 'await' to 'fa

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

Le 29 avr. 2015 10:36, "Adam Bartoš" a écrit : > Why I'm talking about PyCF_SOURCE_IS_UTF8? eval(u"u'\u03b1'") -> u'\u03b1' but eval(u"u'\u03b1'".encode('utf-8')) -> u'\xce\xb1'. There is a simple option to get this flag: call eval() with unicode, not with encoded bytes. Victor _

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

Greg, On 2015-04-29 5:12 AM, Greg Ewing wrote: Guido van Rossum wrote: On Mon, Apr 27, 2015 at 8:07 PM, Yury Selivanov mailto:yselivanov...@gmail.com>> wrote: > Why StopAsyncIteration? ''' I keep wanting to propose to rename this to AsyncStopIteration. +1, that

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

Yury Selivanov writes: > Agree. Do you think it'd be better to combine comprehensions > and async lambdas in one section? No, I'd keep them separate. For one thing, given Guido's long-standing lack of enthusiasm for lambda, they'll need to be separate PEPs. ___

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

Greg, On 2015-04-29 5:13 AM, Greg Ewing wrote: Yury Selivanov wrote: On 2015-04-28 11:59 PM, Greg wrote: On 29/04/2015 9:49 a.m., Guido van Rossum wrote: *But* every generator-based coroutine *must* be decorated with `asyncio.coroutine()`. This is potentially a backwards incom

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

Greg, On 2015-04-29 5:12 AM, Greg Ewing wrote: Yury Selivanov wrote: It's important to at least have 'iscoroutine' -- to check that the object is a coroutine function. A typical use-case would be a web framework that lets you to bind coroutines to specific http methods/paths: @http.get('

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

On 2015-04-29 5:12 AM, Greg Ewing wrote: Yury Selivanov wrote: Looking at the grammar -- the only downside of the current approach is that you can't do 'await await fut'. I still think that it reads better with parens. If we put 'await' to 'factor' terminal we would allow await -fut # a

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

On 2015-04-29 5:13 AM, Greg Ewing wrote: Yury Selivanov wrote: 3. GenObject __iter__ and __next__ raise error *only* if it has CO_NATIVE_COROUTINE flag. So iter(), next(), for..in aren't supported only for 'async def' functions (but will work ok on asyncio generator-based coroutines) What

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

Yury Selivanov wrote: It's just like unary minus ;) I'm confused. I thought you were arguing that your grammar is better because it's *not* just like unary minus? If being just like unary minus is okay, then why not just make it so? -- Greg ___ Pyt

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

Yury Selivanov wrote: 3. GenObject __iter__ and __next__ raise error *only* if it has CO_NATIVE_COROUTINE flag. So iter(), next(), for..in aren't supported only for 'async def' functions (but will work ok on asyncio generator-based coroutines) What about new 'async def' code called by existin

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

Yury Selivanov wrote: On 2015-04-28 11:59 PM, Greg wrote: On 29/04/2015 9:49 a.m., Guido van Rossum wrote: *But* every generator-based coroutine *must* be decorated with `asyncio.coroutine()`. This is potentially a backwards incompatible change. See below. I worry about backwar

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

Guido van Rossum wrote: On Mon, Apr 27, 2015 at 8:07 PM, Yury Selivanov > wrote: > Why StopAsyncIteration? ''' I keep wanting to propose to rename this to AsyncStopIteration. +1, that seems more consistent to me too. And since

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

Yury Selivanov wrote: I also like Guido's suggestion to use "native coroutine" term. I'll update the PEP (I have several branches of it in the repo that I need to merge before the rename). I'd still prefer to avoid use of the word "coroutine" altogether as being far too overloaded. I think eve

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

Guido van Rossum wrote: I don't care for await await x. But do you dislike it enough to go out of your way to disallow it? -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: htt

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

Guido van Rossum wrote: There's a cost to __future__ imports too. The current proposal is a pretty clever hack -- and we've done similar hacks in the past There's a benefit to having a __future__ import beyond avoiding hackery: by turning on the __future__ you can find out what will break when

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

Yury Selivanov wrote: Looking at the grammar -- the only downside of the current approach is that you can't do 'await await fut'. I still think that it reads better with parens. If we put 'await' to 'factor' terminal we would allow await -fut # await (-fut) Is there really a need to dis

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

Yury Selivanov wrote: It's important to at least have 'iscoroutine' -- to check that the object is a coroutine function. A typical use-case would be a web framework that lets you to bind coroutines to specific http methods/paths: @http.get('/spam') async def handle_spam(request):

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

This situation is a bit different from coding cookies. They are used when we have bytes from a source file, but we don't know its encoding. During interactive session the tokenizer always knows the encoding of the bytes. I would think that in the case of interactive session the PyCF_SOURCE_IS_UTF8

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

On 29 April 2015 at 06:20, Adam Bartoš wrote: > Hello, > > is it possible to somehow tell Python 2.7 to compile a code entered in the > interactive session with the flag PyCF_SOURCE_IS_UTF8 set? I'm considering > adding support for Python 2 in my package > (https://github.com/Drekin/win-unicode-co