Raymond Hettinger <[EMAIL PROTECTED]> added the comment:
I'm not happy with the 3.0 change. IMO, the best behavior is the one
that allows code reviewers to correctly reason about the code by
assuming basic invariants. In 2.6, all of the following are always true:
assert a in [a]
assert a in (a,)
assert a in set([a])
assert [a].count(a) == 1
This is especially important because it lets us maintain a consistent
meaning for "in" its two contexts:
for a in container:
assert a in container # this should ALWAYS be true
This shows that "is" is essential in the interpretation of "in". If you
loop over elements in a container, then by definition those exact
elements are IN the container. If we break this, it will lead to hard
to find errors and language inconsistencies.
The "identity implies equality" rule isn't just an optimization, it is a
deep assumption that pervades the language implementation. Lots of
logic relies on it to maintain invariants. It looks like the 3.0
changes are fighting this state of affairs. IMO, those changes are
fighting an uphill battle and will introduce more oddities than they
eliminate.
----------
nosy: +rhettinger
versions: +Python 3.0 -Python 2.4, Python 2.5, Python 2.6, Python 2.7
_______________________________________
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4296>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
