RetroSearch Browse

Thu Feb 10 19:51:43 CET 2005 · http://mail.python.org/pipermail/python-dev/2005-February/051502.html

On Wed, 09 Feb 2005 17:42:41 -0800, rhettinger at users.sourceforge.net
<rhettinger at users.sourceforge.net> wrote:
> Update of /cvsroot/python/python/dist/src/Python
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31172
> 
> Modified Files:
>         compile.c
> Log Message:
> Remove the set conversion which didn't work with:  [] in (0,)

Why is this a problem?  If there were *any* unhashable objects
in the container, then the compiler would have bailed on the 
initial set-conversion.

If there aren't any unhashable values, then the (unhashable) item
being checked is not in the set. ==> Return False.

Are you worried about unhashable objects (as item) which 
compare == to something that is hashable (in container)?
Custom rich compares can already confuse the "in" tests.

Or is the problem that guarding against/trapping this case is 
somehow so expensive that it overrides the expected savings?

-jJ

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2005-February/051502.html below:

[Python-checkins] python/dist/src/Python compile.c, 2.343, 2.344