Christopher Barker and Stephen J. Turnbull wrote:
> As a statement clause separator, which becomes ambiguous:
>
> if thing: x
>
Yes. Very good. Well done, both of you.
Now consider this. PEP 643 allows for things like
obj[a=x:y]
and "may open up the open the possibility" of allowing
fn(a=x:y)
The so-to-say obvious way to allow
fn(a=x:y)
is to allow a bare
x:y
to function as an expression. This is because at present in the syntax
fn(a=SOMETHING)
the SOMETHING is an expression. Why would we want to change that? There's a
cost, particularly when we read and write code, in changing that syntactic
rule.
With me so far. Now consider
if x:y:z
What could it mean? (I'm assuming bare slices are allowed.) It could be
either of
if (x:y): z
if x: (y:z)
Now let's go back to PEP 643 allowing
obj[a=x:y]
which "may open up the open the possibility" of allowing
fn(a=x:y)
Here's how I see things. Allowing both of
obj[a=x:y]
fn(a=x:y)
opens up the possibility of
if x:y:z
which in my opinion is a can of worms. Please, let's not go there.
Not convinced? Both
if a:b:
x = y
and
if a:b:
x = y
are valid syntax after 'promoting' some colons into slices. But we have to
look ahead to the next line, to figure what to do.
For this reason I think it better to forbid the short-cut
obj[a=x:y]
and allow the explicit statement
obj[a=(x:y)]
by making
(x:y)
and similar constructs valid syntax for an slice expression, which can be
used anywhere.
While we're here
def fn(u:v=w): pass
is valid syntax for a function where
u has type v
u had default value w
I say allow
def fn(u:v=(x:y)): pass
def fn(u:v=(:)): pass
and forbid
def fn(u:v=x:y): pass
def fn(u:v=:): pass
I think PEP 637 would prefer the other way around. By the way, there's a
gap in PEP 637. This PEP talks about slice notation in function calls, but
not in function definitions. But default values are values that migrate
from a function definition to a function call.
I'm warming to the idea of a PEP concerned solely with the syntax for
1. item access
2. function definitions and calls
3. slices
Finally, thank you Christopher and Stephen, for your concise and deep
contribution.
--
Jonathan
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GE7UHIVKUPQUR352S2BCORUMPICUPYBQ/
Code of Conduct: http://python.org/psf/codeofconduct/
