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

[Michael Hudson]

Jim Jewett <jimjjewett at gmail.com> writes:

> 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?

It broke the test suite...

> If there were *any* unhashable objects in the container, then the
> compiler would have bailed on the initial set-conversion.

Also, the RHS wouldn't have been a tuple of constants, as far as the
compiler saw it.

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

This would seem to require changing the frozenset implementation.  I
don't know if the option of unhashable implying returning false from
frozenset.__contains__() was considered at the time it was implemented
but it doesn't feel right to me.

> 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.

This was a concern of mine, yes.  Although any custom object
(particularly an unhashable one!) that compares equal to something so
simple as an integer, string or tuple seems bad design, I'm not sure
that's the point.

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

If you want to compile the expression

x in (1,2,3)

to contain the moral equivalent of a try:except: block, I'd question
your sanity.

Cheers,
mwh

-- 
  > It might get my attention if you'd spin around in your chair,
  > spoke in tongues, and puked jets of green goblin goo.
  I can arrange for this.  ;-)            -- Barry Warsaw & Fred Drake