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).
_______________________________________________
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/S7TPJYT2ODXG6FJAOB77HIJU6IXSHJT2/
Code of Conduct: http://python.org/psf/codeofconduct/
