On Tue, Jul 27, 2010 at 11:49 AM, Michael Foord <fuzzyman@gmail.com> wrote:
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.

--
Ian Bicking  |  http://blog.ianbicking.org