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 gu...@python.org
mailto:gu...@python.org wrote:
On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith
Nathaniel Smith wrote:
If await acted like -, then this would be
await (x ** 2)
But with the proposed grammar, it's instead
(await x) ** 2
Ah, I had missed that!
This is a *good* argument for Yuri's grammar.
I withdraw my objection now.
--
Greg
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
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
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
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
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 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 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.
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
___
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
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:
—
Sent from Mailbox
On Wednesday Apr 29, 2015 at 7:14 PM, Yury Selivanov yselivanov...@gmail.com,
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.
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
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
On Apr 29, 2015 11:49 AM, Yury Selivanov yselivanov...@gmail.com 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
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
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 yselivanov...@gmail.com wrote:
Hi Ethan,
On 2015-04-29 2:32 PM, Ethan
On 29 April 2015 at 19:32, Ethan Furman et...@stoneleaf.us 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
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 parens
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 bit?
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
On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov yselivanov...@gmail.com
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
On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov yselivanov...@gmail.com 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
Guido,
On 2015-04-29 7:52 PM, Guido van Rossum wrote:
On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov yselivanov...@gmail.com
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
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
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
On Wed, Apr 29, 2015 at 3:46 PM, Greg Ewing greg.ew...@canterbury.ac.nz
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
On Wed, Apr 29, 2015 at 5:05 PM, Yury Selivanov yselivanov...@gmail.com wrote:
Nathaniel,
On 2015-04-29 7:58 PM, Nathaniel Smith wrote:
On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Nathaniel,
On 2015-04-29 7:35 PM, Nathaniel Smith wrote:
What I do feel
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't
On Wed, Apr 29, 2015 at 3:46 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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
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
Nathaniel,
On 2015-04-29 7:58 PM, Nathaniel Smith wrote:
On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov yselivanov...@gmail.com 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*
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 #
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 'factor' terminal
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.)
I don't care for await await x.
On Apr 28, 2015 6:53 PM, Yury Selivanov yselivanov...@gmail.com 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'
I prefer option #3.
On Mon, Apr 27, 2015 at 4:44 PM, Yury Selivanov yselivanov...@gmail.com wrote:
Hi Greg,
I don't want this: await a() * b() to be parsed, it's not meaningful.
Likely you'll see await await a() only once in your life, so I'm fine to
use parens for it (moreover, I think it
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)
I think I something like
power: atom_expr ['**'
Yury Selivanov wrote:
I don't want this: await a() * b() to be parsed, it's not meaningful.
Why not? If a() is a coroutine that returns a number,
why shouldn't I be able to multiply it by something?
I don't think your currently proposed grammar prevents
that anyway. We can have
expr --
Greg,
On 2015-04-29 1:40 AM, Greg Ewing wrote:
Yury Selivanov wrote:
I don't want this: await a() * b() to be parsed, it's not meaningful.
Why not? If a() is a coroutine that returns a number,
why shouldn't I be able to multiply it by something?
Sorry, I thought you meant parsing await
Yury Selivanov wrote:
I've done some experiments with grammar, and it looks like
we indeed can parse await quite differently from yield. Three
different options:
You don't seem to have tried what I suggested, which is
to make 'await' a unary operator with the same precedence
as '-', i.e.
Hi Greg,
I don't want this: await a() * b() to be parsed, it's not meaningful.
Likely you'll see await await a() only once in your life, so I'm fine
to use parens for it (moreover, I think it reads better with parens)
Yury
On 2015-04-27 8:52 AM, Greg Ewing wrote:
Yury Selivanov wrote:
Hi Guido,
On 2015-04-24 1:03 PM, Guido van Rossum wrote:
*3. syntactic priority of `await`*
Yury, could you tweak the syntax for `await` so that we can write the most
common usages without parentheses? In particular I'd like to be able to
write
```
return await foo()
with await foo() as bar:
On 26 April 2015 at 06:18, Yury Selivanov yselivanov...@gmail.com wrote:
Option #3. Create a new terminal for await expression between
'atom' and 'power'.
Required grammar changes:
https://gist.github.com/1st1/cb0bd257b04adb87e167#file-option-3-patch
Repo to play with (parser module is
+1 for option 3.
On Sat, Apr 25, 2015 at 1:18 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Hi Guido,
On 2015-04-24 1:03 PM, Guido van Rossum wrote:
*3. syntactic priority of `await`*
Yury, could you tweak the syntax for `await` so that we can write the most
common usages without
Guido van Rossum wrote:
Sorry, when I wrote future (lower-case 'f') I really meant what Yury
calls *awaitable*. That's either a coroutine or something with an
__await__ emthod.
But how is an awaitable supposed to raise StopIteration
if it's implemented by a generator or async def[*] function?
On 25 April 2015 at 07:37, Łukasz Langa luk...@langa.pl wrote:
On Apr 24, 2015, at 10:03 AM, Guido van Rossum gu...@python.org wrote:
3. syntactic priority of `await`
Yury, could you tweak the syntax for `await` so that we can write the most
common usages without parentheses?
+1
Yury
On 25 April 2015 at 16:23, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
Sorry, when I wrote future (lower-case 'f') I really meant what Yury
calls *awaitable*. That's either a coroutine or something with an __await__
emthod.
But how is an awaitable supposed to
2015-04-25 8:23 GMT+02:00 Greg Ewing greg.ew...@canterbury.ac.nz:
But how is an awaitable supposed to raise StopIteration
if it's implemented by a generator or async def[*] function?
Those things use StopIteration to wrap return values.
I like the idea of allowing StopIteration to be raised
Victor Stinner wrote:
It's now time to focus our
good energy on discussing remaining questions on the PEP 492 to make
it the best PEP ever!
That's what I'm trying to do. I just think it would
be even better if it could be made to address that
issue somehow. I haven't thought of a way to do
Hi Greg,
2015-04-25 7:02 GMT+02:00 Greg Ewing greg.ew...@canterbury.ac.nz:
I accept the compromise of creating a coroutine object without wait
for it (obvious and common bug when learning asyncio). Hopefully, we
keep the coroutine wrapper feature (ok, maybe I suggested this idea to
Yury
On Fri, Apr 24, 2015 at 11:03 AM, Ethan Furman et...@stoneleaf.us wrote:
On 04/24, Yury Selivanov wrote:
On 2015-04-24 1:03 PM, Guido van Rossum wrote:
Ditto for `__aiter__` and `__anext__`. I guess this means that the async
equivalent to obtaining an iterator through `it = iter(xs)`
On Apr 24, 2015, at 10:03 AM, Guido van Rossum gu...@python.org wrote:
6. StopAsyncException
What if we required `ait.__anext__()` to return a future?
On top of my previous response, one more thing to consider is that this idea
brings a builtin Future back to the proposal, which has
Sorry, when I wrote future (lower-case 'f') I really meant what Yury
calls *awaitable*. That's either a coroutine or something with an __await__
emthod.
On Fri, Apr 24, 2015 at 3:17 PM, Łukasz Langa luk...@langa.pl wrote:
On Apr 24, 2015, at 10:03 AM, Guido van Rossum gu...@python.org wrote:
Guido van Rossum wrote:
Yury, could you tweak the syntax for `await` so that we can write the
most common usages without parentheses? In particular I'd like to be
able to write
```
return await foo()
with await foo() as bar: ...
foo(await bar(), await bletch())
```
Making 'await' a prefix
Victor Stinner wrote:
That's why I suggest to reconsider the idea of supporting an
*optional* from __future__ import async to get async and await as
keywords in the current file. This import would allow all crazy
syntax. The parser might suggest to use the import when it fails to
parse an async
I've tried to catch up with the previous threads. A summary of issues
brought up:
1. precise syntax of `async def` (or do we need it at all)
2. do we need `async for` and `async with` (and how to spell them)
3. syntactic priority of `await`
4. `cocall` vs. `await`
5. do we really need `__aiter__`
Guido,
On 2015-04-24 1:03 PM, Guido van Rossum wrote:
*3. syntactic priority of `await`*
Yury, could you tweak the syntax for `await` so that we can write the most
common usages without parentheses? In particular I'd like to be able to
write
```
return await foo()
with await foo() as bar: ...
On 04/24, Yury Selivanov wrote:
On 2015-04-24 1:03 PM, Guido van Rossum wrote:
Ditto for `__aiter__` and `__anext__`. I guess this means that the async
equivalent to obtaining an iterator through `it = iter(xs)` followed by
`for x over it` will have to look like `ait = await aiter(xs)`
On Apr 24, 2015, at 10:03 AM, Guido van Rossum gu...@python.org wrote:
1. precise syntax of `async def`
So I still prefer `async def`.
Me too. Also, we would use a similar vocabulary to existing users of the
feature. This is exactly how Hack does it:
Victor,
On 2015-04-24 5:32 PM, Victor Stinner wrote:
7. compatibility with asyncio and existing users of it
The current state of the PEP makes types.coroutine() mandatory. If a
generator-based coroutine is not modified with types.coroutine, await
cannot be used on it. To be more concrete:
Hi,
2015-04-24 19:03 GMT+02:00 Guido van Rossum gu...@python.org:
1. precise syntax of `async def`
Of all the places to put `async` I still like *before* the `def` the best.
So do I.
2. do we need `async for` and `async with`
Yes we do.
I agree.
3. syntactic priority of `await`
Lukasz,
On 2015-04-24 5:37 PM, Łukasz Langa wrote:
(Though maybe we should consider `await for` and `await with`? That would have
the advantage of making it easy to scan for all suspension points by searching
for /await/. But being a verb it doesn't read very well.)
I’m on the fence here.
73 matches
Mail list logo
