Christopher Barker writes:

thing[i,j,k] is exactly equivalent to thing[(i,j,k)] because the tuple is "created by" the parentheses.

Is that correct? As I understand it, the tuple is created by the commas, and the parentheses are basically thrown away by the parser, as usual.

and thing[1:2, 3:4]

does create a tuple, and pass it on to the __*item__ dunder.

and

thing[slice(1,2), slice(1,2)] is exactly equivalent to thing[(slice(1,2), slice(1,2))]

But is it exactly equivalent to "thing[1:2, 1:2]"? I believe it is, and if so

So the only missing piece here is that that slice syntax can only be used directly inside the square brackets.

is exactly correct, and somewhat anomolous, since slices are perfectly good objects.

As the colon is used elsewhere in Python,

As a statement clause separator, which becomes ambiguous: if thing: x However, I would guess this you can resolve this with a grammar that says "if thing:" is unconditionally a conditional clause, and that in "if (thing : x)" has to parse "thing : x" to slice syntax first, then look for the terminating colon for the if clause. Similarly for all other compound statement clauses: an unparenthesized colon terminates the clause immediately. And in dict displays, where generalized slices could be used as components, rather than treating ':' merely as a separator. (I write "generalized" because I presume slices are currently specialized to ints). Is there anything else? I think one big bugaboo here is in the word "generalized", because you'd enable errors like myslice = 'key' : 'value' for item in alist[myslice]: foo(item) and I just don't know if that's plausible enough to worry about. Also, slice syntax admits partial slices, so you would probably need to parse "naked" slices like "'key':", and what in the world would "::'some arbitrary string'" mean, and how could you justify ruling it out arbitrarily? (Wouldn't consenting adults apply, so for example def myzip(slicearg, iterables): myiterables = [itertools.islice(it, slicearg.start, slicearg.stop) for it in iterables] return zip(myiterables, strict=slicearg.step) "should" be allowed?)

I do think it should be completely separate from PEP 637

+1

I suggest a PEP that extended the syntax to allow

...

...

(1:2) (1:2, 3:4, 5, 6) to be expressions

I don't like the requirement for parentheses of a single slice expression, and the second example is presumably not slice syntax, but tuple syntax. I.e., given the requirement exemplified by (1:2), the second example should be written ((1:2), (3:4), 5, 6) which is not as attractive. Except in function syntax, where they are a required operator, elsewhere in Python parentheses are used only for controlling order of evaluation as far as I know, with the partial exception of genexps. I write "partial" because in most places a genexp must be parenthesized, but it's acceptable as the only actual argument to a function without parentheses. And of course a single genexp may contain an arbitrarily large number of clauses, so it's quite different from an n-ary operator with very small n.

A quick googling reveals the rejected PEP 204 https://www.python.org/dev/peps/pep-0204/

which proposed a "range literal", which used slice syntax to create a range -- but that's something different (and, indeed, range objects are different than they were back then as well)

I don't think it's that different, both ranges and slices (as they exist now) are mostly used to control iteration. It's just that the iteration controlled by slices is implicit in the creation of a new sequence. I would guess any arguments purely about the syntax would apply here as well. My current opinion is that (1) generalized slices are just too messy, the constructor notation "slice(start, stop, step)" is not at all obnoxious, and (3) the colons in compound statements, dict displays, and sequence slices are not operators in any of the three cases, and can't be treated that way. Specifically, in all three cases they're syntactically separators, but in compound statements they don't separate sequences of objects at all, and in slices and dict display items the objects they separate are of quite different types and the implied sequences are even of different lengths (3 vs. 2). It's messy enough that I'm not going to spend any more skull sweat on this, we're fine as is for slices and slice syntax (IMO).

On Tue, Oct 27, 2020 at 11:24 PM Chris Angelico wrote:

On Wed, Oct 28, 2020 at 5:12 PM Stephen J. Turnbull wrote:

...

...

thing[i,j,k] is exactly equivalent to thing[(i,j,k)] because the tuple is "created by" the parentheses.

Is that correct? As I understand it, the tuple is created by the commas, and the parentheses are basically thrown away by the parser, as usual.

I think that sentence was perhaps meant to read "because the tuple is NOT created by the parentheses" - the rest of the post makes full sense that way.

yes, thanks -- that was a typo, and an unfortunate one, as it's kinda the key point :-( -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

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