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.