homepage

I am attaching a proof-of-concept patch which would optimize bytecode
generated from constant slices as follows:
Before patch:
>>> dis(lambda:x[1:2:3])
 1 0 LOAD_GLOBAL 0 (x)
 3 LOAD_CONST 0 (1)
 6 LOAD_CONST 1 (2)
 9 LOAD_CONST 2 (3)
 12 BUILD_SLICE 3
 15 BINARY_SUBSCR 
 16 RETURN_VALUE 
After the patch:
>>> dis(lambda:x[1:2:3])
 1 0 LOAD_GLOBAL 0 (x) 
 3 LOAD_CONST 3 (slice(1, 2, 3)) 
 6 BINARY_SUBSCR 
 7 RETURN_VALUE 
While the peephole optimizer changes are straightforward, the
optimization does not work unless slice objects gain hash and marshal
support.
While I don't see any problem with adding slice marshaling, the idea of
making slices hashable has recently been rejected (see issue1733184) and
I was supporting the rejection myself.
With this patch, however, I would like to reopen the discussion of
hash(slice(..)) issue.
Allowing constant folding for slices may tip the balance towards
allowing hash(slice(..)) assuming that {}[:] can still be prohibited.
One possible approach to this problem would be to emit a new bytecode
instead of BINARY_SUBSCR from slice syntax and have it reject mapping
objects. This should be easy for objects implemented in C, but for user
defined classes with custom __(get|set)item__ it may not be easy to
distinguish between a mapping and a sequence. However, I don't much of
a problem for always allowing x[:] for such types (user code can reject
slices if necessary).
If extra bytecode approach is taken, it is likely that d[slice(a,b)]
will end up being supported even if d[a:b] is not. Some may think it
would be a good feature, though.
A possible advantage of that approach would be a better error message
from an attempt to slice a dictionary. The current "unhashable type"
diagnostic is somewhat cryptic. "Cannot slice a dictionary" would be
much friendlier.
It is possible to work around unhashability of slices and still
implement folding, but the ideas that come to mind such as placing a
hashable subclass of slice into constants seem too artificial.
I am copying the "nosy" list from issue1733184 to start the discussion.