[Python-ideas] Non-boolean return from __contains__

[Ian Bicking]

On Tue, Jul 27, 2010 at 11:49 AM, Michael Foord <fuzzyman at gmail.com> wrote:

> On 27 July 2010 17:42, Alexander Belopolsky <
> alexander.belopolsky at gmail.com> wrote:
>
>> On Tue, Jul 27, 2010 at 11:59 AM, Guido van Rossum <guido at python.org>
>> wrote:
>> ..
>> >> So it doesn't help that 'in' may return something else than a bool
>> >> because the method is called on the wrong object for your purposes.
>> >
>> > Well that pretty much kills the proposal. I can't believe nobody
>> > (including myself) figured this out earlier in the thread. :-(
>>
>> It may kill a use case or two, but not the proposal.   In the
>> libraries like numpy where all python containers get replaced, this is
>> not an issue.   Also this problem invites __rcontains__ solution,
>
>
>
> Wasn't the lack of an __rcontains__ a problem for the web-sig guys trying
> to work out the bytes / strings issue?
>

I think PJE wanted to implement a string type that was bytes+encoding (as
opposed to using Python's native strings).  You can overload __add__ etc so
everything works, but you couldn't make this work:

  encodedbytes(b'1234', 'utf8') in '12345'

because '12345'.__contains__ would reject the encodedbytes type outright.

__rcontains__ would work because here '12345' would know that it didn't
understand encodedbytes.  It wouldn't work for lists though, as
[].__contains__ can handle *any* type, as it just tests for equality across
all of its members.  So it's not like __radd__ because the original object
can't know that it should defer to the other argument.

-- 
Ian Bicking  |  http://blog.ianbicking.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100727/1d9212f4/attachment.html>