Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
This needs to stay rejected. I'm unwilling to introduce special cases in the
language just to support a peephole optimization.
--
assignee: gvanrossum - rhettinger
___
Python
Guido van Rossum gu...@python.org added the comment:
Did Alexander ever present his case to python-dev?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1733184
___
L. Peter Deutsch [EMAIL PROTECTED] added the comment:
Having now read messages 63380 and 63384, I agree with them: I would
have withdrawn my proposal if it hadn't gotten rejected first. I do have
a use case, but the workaround is pretty easy.
_
Tracker [EMAIL
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
I hate to flip-flop like this, but please consider my new
arguments at issue2268. In short, slices being unhashable
prevents storing them in the code object's const dictionary
and thus prevents optimizing code involving const slices.
Jean-Paul Calderone added the comment:
I don't see the ability to use a slice as a dict key as particularly
more surprising than the ability to use ints as dict keys. Someone who
doesn't understand how dicts work can use either of these features to
write broken programs.
I have thought about
Alexander Belopolsky added the comment:
Note that L[:] and L[:] = [] are well-known idioms for making a copy of
a list and emptying the list respectively. (For dictionaries we have
D.copy() and D.clear().) Someone looking at x[:] or x[:] = [] should
immediately recognize a list copy or clear
Changes by Raymond Hettinger:
--
resolution: - rejected
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1733184
_
___
Python-bugs-list
Alexander Belopolsky added the comment:
Patch # 408326 was designed to make assignment to d[:] an error where d
is a dictionary. See discussion starting at
http://mail.python.org/pipermail/python-list/2001-March/072078.html .
I think the only reason slice objects need to be comparable is
Raymond Hettinger added the comment:
Guido, any thoughts? I'm +0 on making slices hashable -- no real harm
from doing it -- not much benefit either.
--
assignee: - gvanrossum
nosy: +gvanrossum
_
Tracker [EMAIL PROTECTED]
Alexander Belopolsky added the comment:
In case I did not make my position clear in my previous post, I am -1 on
this RFE. x[:] should mean slicing, not getitem.
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1733184
Jean-Paul Calderone added the comment:
Slice objects are really meant to be internal structures and not
passed around in the user's code.
I don't know what they're meant to be, but they're certainly not
internal. If you implement __getitem__, __setitem__, or __delitem__,
then chances are
Guido van Rossum added the comment:
Alexander nailed my motivation.
Have the proponents for this change really thought through that making
slices hashable means that henceforth this code will work?
d = {}
d[:] = [1, 2, 3] # surprise here
print d # prints {slice(None, None,
12 matches
Mail list logo
