[issue11107] Cache constant "slice" instances

Josh Rosenberg report at bugs.python.org
Mon May 6 14:56:58 EDT 2019


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

I'm trying to sprint on this this week. I already had a PoC put together, but it has some significant issues caused by one major quirk with slices:

1. They're immutable, but
2. They're not hashable

In various places, it is (reasonably) assumed that constants can be hashed (so as to coalesce identical constants), and since slice objects can't be, this causes problems.

In my proof of concept, I cheated, and added a field to the slice object, hashable, that was only set to true when the slice was a result of:

1. ast_opt.c's constant coalescence
2. marshal.c's r_object reading in a slice from the bytecode

Obviously this isn't practical for an actual patch, and I'm trying to figure out if there is a way around it.

Right now, it seems like ast_opt.c's approach may not be necessary (even if I don't set hashable, it still works, and seems to coalesce, which seems odd; pretty sure when I first started the slices tried to get stored as dict keys at some point).

I'm still having issues figuring out to handle marshaling; my code currently works, but where the first load of a module (from .py) performs constant coalescence, my attempts to make slices use w_ref/R_REF appropriately have been unsuccessful. I'd greatly appreciate any help/tips from anyone who knows enough about:

1. The constant coalescence code for ast/compile steps (for first load)
2. The rules for w_ref/R_REF in the marshal code (for writing out and loading from compiled bytecode files)
3. Working around the (possible) need for hashable objects in the constant coalescent/marshal-ing code

If you're at the sprints, I'm sitting in the CPython room directly in front of the entrance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11107>
_______________________________________


More information about the Python-bugs-list mailing list