Hello,
On Wed, 29 Apr 2015 20:33:09 -0400
Yury Selivanov yselivanov...@gmail.com wrote:
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
On 30 April 2015 at 09:58, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Ethan Furman wrote:
Having gone through the PEP again, I am still no closer to understanding
what happens here:
data = await reader.read(8192)
What does the flow of control look like at the interpreter level?
Are
On Tue, Apr 28, 2015 at 11:13 AM, Victor Stinner
victor.stin...@gmail.com wrote:
Hi,
2015-04-27 16:02 GMT+02:00 Petr Viktorin encu...@gmail.com:
A macro like this would reduce boilerplate in stdlib and third-party C
extensions. It would ease porting C extensions to Python 3, where rich
Hello,
On Mon, 27 Apr 2015 08:48:49 +0100
Mark Shannon m...@hotpy.org wrote:
On 27/04/15 00:13, Guido van Rossum wrote:
But new syntax is the whole point of the PEP. I want to be able to
*syntactically* tell where the suspension points are in coroutines.
Doesn't yield from already do
On 30 April 2015 at 06:39, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Aaargh, this is what we get for overloading the word
coroutine. The Wikipedia article is talking about a
technique where coroutines yield control to other
explicitly identified coroutines.
Yep, I understand that. It's
On 30 April 2015 at 02:52, Nick Coghlan ncogh...@gmail.com wrote:
This request isn't about understanding the implementation details,
it's about understanding what Python *users* will gain from the PEP
without *needing* to understand the implementation details.
For that, I'd like to see some
Yury Selivanov wrote:
Sorry, but I'm not sure where when I had any troubles
predicting the consequences..
You said you wanted 'await a() * b()' to be a syntax
error, but your grammar allows it.
--
Greg
___
Python-Dev mailing list
Hello,
On Tue, 28 Apr 2015 19:44:53 +0100
Mark Shannon m...@hotpy.org wrote:
[]
A coroutine without a yield statement can be defined simply and
concisely, thus:
@coroutine
def f():
return 1
[]
A pure-python definition of the coroutine decorator is
given below.
[]
from
On Tue, Apr 28, 2015 at 4:59 PM, Barry Warsaw ba...@python.org wrote:
On Apr 28, 2015, at 11:13 AM, Victor Stinner wrote:
It would be nice to have a six module for C extensions. I'm quite sure
that many projects are already full of #ifdef PYTHON3 ... #else ...
#endif macros.
Maybe
Hello,
On Wed, 29 Apr 2015 20:19:40 +0100
Paul Moore p.f.mo...@gmail.com wrote:
[]
Thanks for that. That does look pretty OK. One question, though - it
uses an asyncio Queue. The original code would work just as well with
a list, or more accurately, something that wasn't designed for async
On 30.04.2015 02:33, Nick Coghlan wrote:
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
Chris Angelico writes:
It's legal Unicode, but it doesn't mean what he typed in.
Of course, that's obvious. My point is Welcome to the wild wacky
world of soi-disant 'internationalized' software, where what you see
is what you get regardless of what you type.
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
On 15-04-29, 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.
Because it does not make any sense.
I obviously don't
On 15-04-29, Yury Selivanov wrote:
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
On Thu, 30 Apr 2015 10:02:17 +0100
Paul Moore p.f.mo...@gmail.com wrote:
Of course, if asyncio and the PEP *are* only really relevant to
network protocols, then my impressions are actually correct and I
should drop out of the discussion. But if that's the case, it seems
like a lot of
Yury Selivanov wrote:
3. CO_NATIVE_COROUTINE flag. This enables us to disable
__iter__ and __next__ on native coroutines while maintaining
full backwards compatibility.
I don't think you can honestly claim full backwards
compatibility as long as there are some combinations
of old-style and
Hello,
On Tue, 28 Apr 2015 21:00:17 +0100
Mark Shannon m...@hotpy.org wrote:
[]
CO_COROUTINE = 0x0080
CO_GENERATOR = 0x0020
def coroutine(f):
'Converts a function to a generator function'
old_code = f.__code__
new_code = CodeType(
Hi Mark,
Mark Shannon wrote:
Hi,
I still think that there are several issues that need addressing with
PEP 492. This time, one issue at a time :)
async
The Rationale and Goals of PEP 492 states that PEP 380 has 3
shortcomings. The second of which is:
It is not possible to
Nathaniel Smith wrote:
Even if we put aside our trained intuitions about arithmetic, I think
it's correct to say that the way unary minus is parsed is: everything
to the right of it that has a tighter precedence gets collected up and
parsed as an expression, and then it takes that expression as
Skip Montanaro wrote:
According to Wikipedia http://en.wikipedia.org/wiki/Coroutine, 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
Hello,
On Tue, 28 Apr 2015 20:59:18 +0100
Mark Shannon m...@hotpy.org wrote:
On 28/04/15 20:24, Paul Sokolovsky wrote:
Hello,
[snip]
Based on all this passage, my guess is that you miss difference
between C and Python functions.
This is rather patronising, almost to the point of
does this not work for you?
from __future__ import unicode_literals
On 4/28/2015 16: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
Ethan Furman wrote:
Having gone through the PEP again, I am still no closer to understanding
what happens here:
data = await reader.read(8192)
What does the flow of control look like at the interpreter level?
Are you sure you *really* want to know? For the sake
of sanity, I recommend
On Thu, 30 Apr 2015 09:59:34 +0200
M.-A. Lemburg m...@egenix.com wrote:
Can we please make the monkeypatch a regular part of Python's
site.py which can enabled via an environment variable, say
export PYTHONHTTPSVERIFY=0.
-1 (already explained in the bug below).
See
# Syntactic sugar
Beautiful is better than ugly, thus nice syntax is needed.
Current syntax is very mechanical.
Syntactic sugar is needed on top of current PEP.
# internal vs external
@intify
def foo() - int:
b = 42
return b # check 1
x = foo() // 2 # check 2
Does the return type
On Thu, Apr 30, 2015 at 01:41:53PM +0200, Dima Tisnek wrote:
# Syntactic sugar
Beautiful is better than ugly, thus nice syntax is needed.
Current syntax is very mechanical.
Syntactic sugar is needed on top of current PEP.
I think the annotation syntax is beautiful. It reminds me of Pascal.
Paul Moore wrote:
Also, can I run
the produce/consume just by calling produce()? My impression is that
with asyncio I need an event loop - which traditional coroutines
don't need.
The Pythonic way to do things like that is to write
the producer as a generator, and the consumer as a
loop that
On 04/29, 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
Real world stuff is devouring my free time since immediately after PyCon
and will continue to do so for probably the next few months. I'm hoping to
find the energy to engage Donald and Nick about their proposals while I'm
time-constrained so that when I do have free time again I will be able to
On Thu, Apr 30, 2015 at 10:24 AM, Jim J. Jewett jimjjew...@gmail.com
wrote:
I suspect the real problem is that the PEP is really only concerned
with a very specific subtype of coroutine, and these don't quite fit.
That's correct. The PEP is concerned with the existing notion of coroutines
in
On 04/30, Guido van Rossum wrote:
On Thu, Apr 30, 2015 at 9:15 AM, Ethan Furman wrote:
[...]
Both you and Paul are correct on this, thank you. The proper resolution
of
await -coro()
is indeed to get the result of coro(), call it's __neg__ method, and then
await on that.
On 04/30, Yury Selivanov wrote:
On 2015-04-30 1:56 PM, Ethan Furman wrote:
I still want to see where my current grammar forces to use
parens. See [1], there are no useless parens anywhere.
-- await -coro()
SyntaxError
-- await (-coro()) # not a SyntaxError, therefore parens are
On 2015-04-30 1:56 PM, Ethan Furman wrote:
Why not? Unlike some other languages, Python does not have uniform
priorities for unary operators, so it's reasonable for some unary
operations to have a different priority than others, and certain things
will be SyntaxErrors because of that. E.g. you
On Wed, Apr 29, 2015 at 2:26 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 29 April 2015 at 18:43, Jim J. Jewett jimjjew...@gmail.com wrote:
So? PEP 492 never says what coroutines *are* in a way that explains
why it matters that they are different from generators.
...
Looking at the
Jim,
On 2015-04-30 2:41 PM, Jim J. Jewett wrote:
[...]
Does it really permit *making* them [asynchronous calls], or does
it just signal that you will be waiting for them to finish processing
anyhow, and it doesn't need to be a busy-wait?
I does.
Bad phrasing on my part. Is there anything
On Thu, 30 Apr 2015 12:32:02 -0700
Guido van Rossum gu...@python.org wrote:
No, this is the name we've been using since PEP 342 and it's still the same
concept.
The fact that all syntax uses the word async and not coro or
coroutine hints that it should really *not* be called a coroutine
(much
On 30 April 2015 at 20:32, Guido van Rossum gu...@python.org wrote:
Then I strongly request a more specific name than coroutine.
No, this is the name we've been using since PEP 342 and it's still the same
concept.
However, it is (as I noted in my other email) not very well
documented. There
It is spelled Raymond Luxury-Yacht, but it's pronounced Throatwobbler
Mangrove. :-)
I am actually fine with calling a function defined with async def ... an
async function, just as we call a function containing yield a generator
function.
However I prefer to still use coroutine to describe the
On Wed Apr 29 20:06:23 CEST 2015,Yury Selivanov replied:
As best I can guess, the difference seems to be that a normal
generator is using yield primarily to say:
I'm not done; I have more values when you want them,
but an asynchronous (PEP492) coroutine is primarily saying:
On 29 April 2015 at 20:19, Paul Moore p.f.mo...@gmail.com wrote:
However, just to make my point precise, here's a more or less direct
translation of the Wikipedia code into Python. It doesn't actually
work, because getting the right combinations of yield and send stuff
is confusing to me.
On Thu, Apr 30, 2015 at 11:41 AM, Jim J. Jewett jimjjew...@gmail.com
wrote:
On Wed Apr 29 20:06:23 CEST 2015,Yury Selivanov replied:
As best I can guess, the difference seems to be that a normal
generator is using yield primarily to say:
I'm not done; I have more values when you
Adam Bartoš writes:
Unfortunately, it doesn't work. With PYTHONIOENCODING=utf-8, the
sys.std* streams are created with utf-8 encoding (which doesn't
help on Windows since they still don't use ReadConsoleW and
WriteConsoleW to communicate with the terminal) and after changing
the
On Thu, Apr 30, 2015 at 6:56 PM, Devin Jeanpierre jeanpierr...@gmail.com
wrote:
On Thu, Apr 30, 2015 at 6:13 PM, Greg greg.ew...@canterbury.ac.nz wrote:
It's not about requiring or not requiring parens. It's about
making the simplest possible change to the grammar necessary
to achieve the
On 1/05/2015 6:04 a.m., Yury Selivanov wrote:
I still want to see where my current grammar forces to use
parens. See [1], there are no useless parens anywhere.
It's not about requiring or not requiring parens. It's about
making the simplest possible change to the grammar necessary
to achieve
On Apr 30, 2015 1:57 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Nathaniel Smith wrote:
Even if we put aside our trained intuitions about arithmetic, I think
it's correct to say that the way unary minus is parsed is: everything
to the right of it that has a tighter precedence gets
On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith n...@pobox.com wrote:
The actual effect of making await a different precedence is to resolve
the ambiguity in
await x ** 2
If await acted like -, then this would be
await (x ** 2)
But with the proposed grammar, it's instead
(await x)
On Apr 30, 2015 8:40 PM, Guido van Rossum gu...@python.org wrote:
On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith n...@pobox.com wrote:
The actual effect of making await a different precedence is to resolve
the ambiguity in
await x ** 2
If await acted like -, then this would be
await
On 1/05/2015 5:38 a.m., Guido van Rossum wrote:
you can write not -x but you can't write - not x.
That seems just as arbitrary and unintuitive, though.
There are some other unintuitive consequences as well, e.g.
you can write
not a + b
but it's not immediately obvious that this is parsed
On Thu, Apr 30, 2015 at 6:13 PM, Greg greg.ew...@canterbury.ac.nz wrote:
It's not about requiring or not requiring parens. It's about
making the simplest possible change to the grammar necessary
to achieve the desired goals. Keeping the grammar simple
makes it easy for humans to reason about.
On Thu, Apr 30, 2015 at 4:24 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Yury Selivanov wrote:
Well, using next() and iter() on coroutines in asyncio
code is something esoteric. I can't even imagine
why you would want to do that.
I'm talking about the fact that existing generator-
On 2015-04-30 7:24 PM, Greg Ewing wrote:
Yury Selivanov wrote:
Well, using next() and iter() on coroutines in asyncio
code is something esoteric. I can't even imagine
why you would want to do that.
I'm talking about the fact that existing generator-
based coroutines that aren't decorated
Yury Selivanov wrote:
Well, using next() and iter() on coroutines in asyncio
code is something esoteric. I can't even imagine
why you would want to do that.
I'm talking about the fact that existing generator-
based coroutines that aren't decorated with
@coroutine won't be able to call new
On 2015-04-30 5:16 AM, Greg Ewing wrote:
Yury Selivanov wrote:
3. CO_NATIVE_COROUTINE flag. This enables us to disable
__iter__ and __next__ on native coroutines while maintaining
full backwards compatibility.
I don't think you can honestly claim full backwards
compatibility as long as there
does this not work for you?
from __future__ import unicode_literals
No, with unicode_literals I just don't have to use the u'' prefix, but the
wrong interpretation persists.
On Thu, Apr 30, 2015 at 3:03 AM, Stephen J. Turnbull step...@xemacs.org
wrote:
IIRC, on the Linux console and in an
On 04/29, Yury Selivanov wrote:
Because you want operators to be resolved in the
order you see them, generally.
You want '(await -fut)' to:
1. Suspend on fut;
2. Get the result;
3. Negate it.
This is a non-obvious thing. I would myself interpret it
as:
1. Get fut.__neg__();
2.
56 matches
Mail list logo
