New submission from Alexander Belopolsky <[EMAIL PROTECTED]>:
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.
----------
components: Interpreter Core
files: const-slice-folding.diff
keywords: patch
messages: 63447
nosy: belopolsky, exarkun, gvanrossum, lpd, rhettinger
severity: normal
status: open
title: Fold slice constants
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file9650/const-slice-folding.diff
__________________________________
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2268>
__________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
