This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients christian.heimes, mark.dickinson, mikecurtis, rhettinger
Date 2008-11-11.12:03:38
SpamBayes Score 2.172003e-05
Marked as misclassified No
Message-id <1226405020.17.0.154043645712.issue4296@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2008-11-11 12:03:40rhettingersetrecipients: + rhettinger, mark.dickinson, christian.heimes, mikecurtis
2008-11-11 12:03:40rhettingersetmessageid: <1226405020.17.0.154043645712.issue4296@psf.upfronthosting.co.za>
2008-11-11 12:03:39rhettingerlinkissue4296 messages
2008-11-11 12:03:38rhettingercreate