On Tue, Jul 27, 2010 at 11:49 AM, Michael Foord firstname.lastname@example.org wrote:
On 27 July 2010 17:42, Alexander Belopolsky < email@example.com> wrote:
On Tue, Jul 27, 2010 at 11:59 AM, Guido van Rossum firstname.lastname@example.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.