[issue16011] "in" should be consistent with return value of __contains__

Mariatta Wijaya added the comment: Thanks everyone :) Patch has been merged and backported to 3.6, 3.5, and 2.7. -- resolution: -> fixed stage: backport needed -> resolved status: open -> closed ___ Python tracker

[issue16011] "in" should be consistent with return value of __contains__

Mariatta Wijaya added the comment: New changeset fd704a02ca8713b0dae644f7f182f3e3d1218dbf by Mariatta in branch '2.7': bpo-16011: clarify that 'in' always returns a boolean value (GH-152) (GH-883) https://github.com/python/cpython/commit/fd704a02ca8713b0dae644f7f182f3e3d1218dbf --

[issue16011] "in" should be consistent with return value of __contains__

Changes by Mariatta Wijaya : -- pull_requests: +785 ___ Python tracker ___ ___

[issue16011] "in" should be consistent with return value of __contains__

Mariatta Wijaya added the comment: New changeset c4021af50526f488c0c280e7c7eaa83ef80ae1df by Mariatta in branch '3.6': bpo-16011: clarify that 'in' always returns a boolean value (GH-874) https://github.com/python/cpython/commit/c4021af50526f488c0c280e7c7eaa83ef80ae1df --

[issue16011] "in" should be consistent with return value of __contains__

Mariatta Wijaya added the comment: New changeset 0957f262c5e47167efd520624557aebdc61bfda8 by Mariatta in branch '3.5': bpo-16011: clarify that 'in' always returns a boolean value (GH-152) (GH-875) https://github.com/python/cpython/commit/0957f262c5e47167efd520624557aebdc61bfda8 --

[issue16011] "in" should be consistent with return value of __contains__

R. David Murray added the comment: Thanks, -- stage: patch review -> backport needed ___ Python tracker ___

[issue16011] "in" should be consistent with return value of __contains__

Changes by Mariatta Wijaya : -- pull_requests: +772 ___ Python tracker ___ ___

[issue16011] "in" should be consistent with return value of __contains__

Changes by Mariatta Wijaya : -- pull_requests: +773 ___ Python tracker ___ ___

[issue16011] "in" should be consistent with return value of __contains__

R. David Murray added the comment: New changeset 0ae7c8bd614d3aa1fcaf2d71a10ff1148c80d9b5 by R. David Murray (Amit Kumar) in branch 'master': bpo-16011 clarify that 'in' always returns a boolean value https://github.com/python/cpython/commit/0ae7c8bd614d3aa1fcaf2d71a10ff1148c80d9b5

[issue16011] "in" should be consistent with return value of __contains__

Changes by Berker Peksag : -- nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.5, Python 3.6, Python 3.7 -Python 3.2, Python 3.3, Python 3.4 ___ Python tracker

[issue16011] "in" should be consistent with return value of __contains__

Changes by Amit Kumar : -- pull_requests: +116 ___ Python tracker ___ ___

[issue16011] "in" should be consistent with return value of __contains__

R. David Murray added the comment: You've got the right idea, but you are repeating yourself. Keep it as short as possible while still conveying the correct information. "coerce to boolean" is better than "apply bool", because the code may not in fact be using the bool function to do it.

[issue16011] "in" should be consistent with return value of __contains__

Eric Lafontaine added the comment: (first time trying to reply through email) thanks for the example and you are right : class Foo_emptylist(object): def __contains__(self,item): return [] class Foo_emptydict(object): def __contains__(self,item): return {} class

[issue16011] "in" should be consistent with return value of __contains__

R. David Murray added the comment: >>> bool(()) False >>> bool([]) False >>> bool('') False What you want to say is that 'in' coerces the result returned by __contains__ to a boolean value. -- ___ Python tracker

[issue16011] "in" should be consistent with return value of __contains__

Eric Lafontaine added the comment: oh, I've got what you meant! Proposed change : For user-defined classes which define the __contains__() method, the in operator will convert to False "x in y" if y.__contains__(x) return False, 0 or None. Otherwise, the in operator will return True for any

[issue16011] "in" should be consistent with return value of __contains__

Eric Lafontaine added the comment: Hi David, sorry for the delay on my part for providing how I was getting to that conclusion. I've also resurrected an old post as I want to start contributing more seriously :). As this is documentation only (not changing the code behavior), I didn't take a

[issue16011] "in" should be consistent with return value of __contains__

Eric Lafontaine added the comment: Hi all, Here are the test I've made to understand the behavior : class Foo_42(object): def __contains__(self,item): return 42 class Foo_neg(object): def __contains__(self,item): return -42 class Foo_None(object): def

[issue16011] "in" should be consistent with return value of __contains__

R. David Murray added the comment: Eric: that is not precise enough, I'm afraid :) See msg171093 for the correct documentation update. Specifically, in returns True if __contains__ returns a true value, and False otherwise (not the difference in case, it matters). There are more things

[issue16011] "in" should be consistent with return value of __contains__

Eric Lafontaine added the comment: Hi, For user-defined class, it's up to the class to do the right implementation in my opinion. It's true the description is wrong though. x in y means that x exist inside of y (so that the execution of y.__contain__(x) is executed successfully and (I

[issue16011] in should be consistent with return value of __contains__

Mark Dickinson added the comment: There was a related discussion on python-ideas a while back: http://mail.python.org/pipermail/python-ideas/2010-July/007733.html -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org

[issue16011] in should be consistent with return value of __contains__

Neal Parikh added the comment: Thanks for passing along the thread, it was interesting. Oddly, it seemed to die off with no real resolution. I realize it is now too late to change __contains__ to return a non-boolean value, but for reference, the reason I wanted to return something different

[issue16011] in should be consistent with return value of __contains__

STINNER Victor added the comment: Do you need this PEP? http://www.python.org/dev/peps/pep-0335/ -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16011 ___

[issue16011] in should be consistent with return value of __contains__

Neal Parikh added the comment: I don't, but thanks for passing that along. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16011 ___ ___

[issue16011] in should be consistent with return value of __contains__

New submission from Neal Parikh: The Python 2.7.3 documentation says the following about defining __contains__: Called to implement membership test operators. Should return true if item is in self, false otherwise. For mapping objects, this should consider the keys of the mapping rather than

[issue16011] in should be consistent with return value of __contains__

Christian Heimes added the comment: The internal API is limited to flags as the sq_contains slot and the API function can only return an int: PyAPI_FUNC(int) PySequence_In(PyObject *o, PyObject *value) In order to return the Python object we'd have to alter the API which we can't do as the

[issue16011] in should be consistent with return value of __contains__

Ezio Melotti added the comment: http://docs.python.org/py3k/reference/datamodel.html#object.__contains__ says that __contain__ Should return true if item is in self, false otherwise.. Here the lowercase true and false mean any true or false value, not just True and False and it's indeed