On 27 July 2010 17:42, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:

On Tue, Jul 27, 2010 at 11:59 AM, Guido van Rossum <guido@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.