Re: [Python-Dev] misbehaving __contains__

2008-01-23 Thread tomer filiba
On Jan 23, 2008 3:19 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Steven Bethard] > > >We've already lost this if anyone really wants to break it:: > > > >>>> class C(object): > >... def __iter__(self): > >... return iter(xrange(3)) > >... def __contains__(sel

Re: [Python-Dev] misbehaving __contains__

2008-01-22 Thread Raymond Hettinger
>> And, would we lose the nice relationship expressed by: >> >> for elem in container: >> assert elem in container [Steven Bethard] >We've already lost this if anyone really wants to break it:: > >>>> class C(object): >... def __iter__(self): >... return iter(x

Re: [Python-Dev] misbehaving __contains__

2008-01-22 Thread Steven Bethard
On Jan 22, 2008 5:40 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Daniel Stutzbach] > > There are many places in the C implementation where a slot > > returns an int rather than a PyObject. There other replies > > in this thread seem to support altering the signature of the > > slot to retu

Re: [Python-Dev] misbehaving __contains__

2008-01-22 Thread Raymond Hettinger
[Daniel Stutzbach] > There are many places in the C implementation where a slot > returns an int rather than a PyObject. There other replies > in this thread seem to support altering the signature of the > slot to return a PyObject. Is this setting a precedent that > _all_ slots should return

Re: [Python-Dev] misbehaving __contains__

2008-01-22 Thread Guido van Rossum
On Jan 22, 2008 3:46 PM, Daniel Stutzbach <[EMAIL PROTECTED]> wrote: > On Jan 22, 2008 1:26 PM, tomer filiba <[EMAIL PROTECTED]> wrote: > > >>> class Foo(object): > > ... def __contains__(self, key): > > ... return 17 > > ... def __eq__(self, other): > > ... return 1

Re: [Python-Dev] misbehaving __contains__

2008-01-22 Thread Daniel Stutzbach
On Jan 22, 2008 1:26 PM, tomer filiba <[EMAIL PROTECTED]> wrote: > >>> class Foo(object): > ... def __contains__(self, key): > ... return 17 > ... def __eq__(self, other): > ... return 19 > ... > >>> > >>> f=Foo() > >>> f == 8 > 19 > >>> 8 in f > True There are many

Re: [Python-Dev] misbehaving __contains__

2008-01-22 Thread Guido van Rossum
The issue is that the sq_contains slot is defined as returning an int, while the tp_richcompare slot is defined as returning a PyObject *. Your first opportunity for changing this will be Py3k. Please submit a patch! On Jan 22, 2008 11:26 AM, tomer filiba <[EMAIL PROTECTED]> wrote: > i'm using py

Re: [Python-Dev] misbehaving __contains__

2008-01-22 Thread Chuck Mason (Visual Concepts)
My guess is that results from the bottom of cmp_outcome (ceval.c), The default case handles the PyCmp_EQ case via PyObject_RichCompare, which might not return Py_True or Py_False. But 'in' is handled inside the switch and is subject to the final statements: v = res ? Py_True : Py_False;