bpo-16011: Clarify behavior of contains in user defined classes #152

aktech · 2017-02-18T09:53:28Z

>>> class Foo(object):
...     def __contains__(self, item):
            return 42
>>> foo = Foo()
>>> 3 in foo
True
>>> foo.__contains__(42)
42

the-knights-who-say-ni · 2017-02-18T09:53:29Z

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow these steps to rectify the issue:

Sign the PSF contributor agreement
Wait at least one US business day and then check "Your Details" on bugs.python.org to see if your account has been marked as having signed the CLA (the delay is due to a person having to manually check your signed CLA)
Reply here saying you have completed the above steps

Thanks again to your contribution and we look forward to looking at it!

aktech · 2017-02-21T13:58:56Z

@tiran @ncoghlan @Mariatta Can we Merge this now, as CLA is signed?

berkerpeksag · 2017-02-22T02:02:38Z

Doc/reference/expressions.rst

-For user-defined classes which define the :meth:`__contains__` method, ``x in
-y`` is true if and only if ``y.__contains__(x)`` is true.
+For user-defined classes which define the :meth:`__contains__` method, the
+``in`` operator coerces the result returned by :meth:`__contains__` to a boolean,


This sentence should be ended with a full stop. Or if you used comma intentionally, "Hence" shouldn't begin with an uppercase letter "H".

berkerpeksag · 2017-02-22T02:03:48Z

Doc/reference/expressions.rst

-y`` is true if and only if ``y.__contains__(x)`` is true.
+For user-defined classes which define the :meth:`__contains__` method, the
+``in`` operator coerces the result returned by :meth:`__contains__` to a boolean,
+Hence ``x in y`` is true if and only if ``y.__contains__(x)`` is true.


Perhaps changing the example to bool(y.__contains__(x)) would make the whole paragraph clearer?

+1. Otherwise I don't see the difference with the original one.

methane · 2017-02-22T04:30:31Z

I feel proposed sentence is unnecessary long. How about this?

For user-defined classes which define the :meth:`__contains__` method, ``x in y``
behaves like ``bool(y.__contains__(x))``.

aktech · 2017-02-22T13:56:11Z

I have put the full stop before Hence [..].
For bool(y.__contains__(x)) quoting R. David Murray (https://bugs.python.org/issue16011) here:

"coerce to boolean" is better than "apply bool", because the code may not in fact be using the bool function to do it.

aktech · 2017-02-26T15:20:52Z

Can we merge this now?

bitdancer · 2017-02-27T16:51:25Z

You know what, reading this change side by side with the original, I think I'd instead favor making it:

For user-defined classes which define the :meth:`__contains__` method, ``x in y`` returns ``True`` if ``y.__contains__(x)`` returns a true value, and ``False`` otherwise.

Throughout the section, we should then change 'true' to True anywhere the result of the in operator is being discussed.

aktech · 2017-03-03T08:28:47Z

@bitdancer does that looks good now?

bitdancer · 2017-03-03T15:13:02Z

Yes, but we should also change 'true' to True in the rest of that section where the result of 'in' is being referenced.

aktech · 2017-03-03T18:42:55Z

Yes, but we should also change 'true' to True in the rest of that section where the result of 'in' is being referenced.

Yes, Indeed. I have changed that now.

aktech · 2017-03-11T08:04:28Z

@bitdancer Is this good to go now?

bitdancer · 2017-03-15T00:59:35Z

Doc/reference/expressions.rst

 substring of *y*.  An equivalent test is ``y.find(x) != -1``.  Empty strings are
 always considered to be a substring of any other string, so ``"" in "abc"`` will
 return ``True``.

 For user-defined classes which define the :meth:`__contains__` method, ``x in
-y`` returns ``True`` if ``y.__contains__(x)`` returns a true value, and
+y`` returns ``True`` if ``y.__contains__(x)`` returns a ``True`` value, and


The second True here should be just true.

aktech · 2017-03-19T11:32:36Z

@bitdancer Can we merge this now?

bitdancer · 2017-03-19T15:38:37Z

Not until the Travis check passes. I don't know what's wrong with that or how to get it fixed, unfortunately.

aktech · 2017-03-27T06:01:22Z

Not until the Travis check passes. I don't know what's wrong with that or how to get it fixed, unfortunately.

@ncoghlan Can you help me with this? Need to restart the travis build for this PR.

ncoghlan · 2017-03-28T03:34:51Z

@aktech Since there isn't even a "Details" link, I can't trigger a rebuild from the Travis side of things, but you should be able to push an empty commit to the PR branch as described in http://stackoverflow.com/questions/17606874/trigger-a-travis-ci-rebuild-without-pushing-a-commit/31694534#31694534

Since we use the squash-and-merge workflow, that won't show up in the eventual commit history.

Mariatta · 2017-03-28T05:14:28Z

Maybe try rebasing with upstream/master and push again?

…H-875) (cherry picked from commit 0ae7c8b)

…H-883) (cherry picked from commit 0ae7c8b)

ncoghlan · 2017-05-28T05:07:37Z

Added the sprint label, as this PR was submitted at the PyCon Pune 2017 core development sprint.

miss-islington · 2017-09-13T17:18:25Z

Thanks @aktech for the PR, and @bitdancer for merging it 🌮🎉.. I'm working now to backport this PR to: 2.7.
🐍🍒⛏🤖

miss-islington · 2017-09-13T17:18:27Z

Sorry, @aktech and @bitdancer, I could not cleanly backport this to 2.7 due to a conflict.
Please backport using cherry_picker on command line.

Preparations: - use meaningful variable names - remove dead code - move the stackless addition to PyThreadState to the end of the struct - remove redundant declarations from stackless_structs.h

Add legitimate globals to ignored-globals.txt. All other Stackless globals should be moved to runtime or interpreter state.

It was only used during module initialization.

…time and interpreter state Add struct _stackless_runtime_state to _PyRuntimeState and PyStacklessInterpreterState to PyInterpreterState. For now both structs are empty. I'll move Stackless globals into them.

Add sub-struct transfer to _PyRuntime.st.

…essInterpreterState The variable holds a complex callable object, which must not be shared between different interpreters.

Preparations: - use meaningful variable names - remove dead code - move the stackless addition to PyThreadState to the end of the struct - remove redundant declarations from stackless_structs.h

Add legitimate globals to ignored-globals.txt. All other Stackless globals should be moved to runtime or interpreter state.

It was only used during module initialization.

…time and interpreter state Add struct _stackless_runtime_state to _PyRuntimeState and PyStacklessInterpreterState to PyInterpreterState. For now both structs are empty. I'll move Stackless globals into them.

Add sub-struct transfer to _PyRuntime.st.

…essInterpreterState The variable holds a complex callable object, which must not be shared between different interpreters.

Removed globals: - slp_initial_tstate - channel_hook - slp_error_handler - _slp_schedule_fasthook - _slp_schedule_hook - slp_cstack_chain - mem_bomb Additionally I optimized the ordering of the fields of PyStacklessState and PyStacklessInterpreterState to avoid padding.

Move slp_enable_softswitch to PyStacklessInterpreterState. Move slp_try_stackless, cstack_cache and cstack_cachecount to struct _stackless_runtime_state.

Introduced by commit 6e1250a / issue python#152.

The commit used a C11 feature. Unfortunately only clang emits a warning.

… label (#152)

the-knights-who-say-ni added the CLA not signed label Feb 18, 2017

tiran approved these changes Feb 18, 2017

View reviewed changes

serhiy-storchaka added the docs Documentation in the Doc dir label Feb 18, 2017

berkerpeksag added needs backport to 3.5 labels Feb 21, 2017

Mariatta removed the CLA not signed label Feb 21, 2017

the-knights-who-say-ni added the CLA signed label Feb 21, 2017

berkerpeksag requested changes Feb 22, 2017

View reviewed changes

berkerpeksag changed the title ~~bpo-16011 explicitly document the behaviour of in operator~~ bpo-16011: Clarify behavior of __contains__ in user defined classes Feb 22, 2017

zhangyangyu approved these changes Feb 22, 2017

View reviewed changes

berkerpeksag requested a review from bitdancer February 26, 2017 17:33

aktech force-pushed the in-contains-doc branch from 244f6f8 to 6b6a6a1 Compare March 3, 2017 18:40

bitdancer reviewed Mar 15, 2017

View reviewed changes

aktech force-pushed the in-contains-doc branch 2 times, most recently from 290b63f to 31fa785 Compare March 20, 2017 16:16

Mariatta added a commit that referenced this pull request Mar 28, 2017

bpo-16011: clarify that 'in' always returns a boolean value (GH-152) (G…

0957f26

…H-875) (cherry picked from commit 0ae7c8b)

Mariatta added a commit that referenced this pull request Mar 29, 2017

bpo-16011: clarify that 'in' always returns a boolean value (GH-152) (G…

fd704a0

…H-883) (cherry picked from commit 0ae7c8b)

ncoghlan added the sprint label May 28, 2017

Mariatta added needs backport to 2.7 and removed needs backport to 2.7 labels Sep 13, 2017

serhiy-storchaka assigned bitdancer May 14, 2018

akruis pushed a commit to akruis/cpython that referenced this pull request Oct 14, 2018

Stackless issue python#152: Define Stackless globals to be ignored

a20e25c

Add legitimate globals to ignored-globals.txt. All other Stackless globals should be moved to runtime or interpreter state.

akruis pushed a commit to akruis/cpython that referenced this pull request Oct 14, 2018

Stackless issue python#152: Eliminate the variable types_mod.

ad1a593

It was only used during module initialization.

akruis pushed a commit to akruis/cpython that referenced this pull request Oct 14, 2018

Stackless issue python#152: Move globals from slp_tranfer to _PyRuntime

712667f

Add sub-struct transfer to _PyRuntime.st.

akruis pushed a commit to akruis/cpython that referenced this pull request Oct 29, 2018

Stackless issue python#152: Define Stackless globals to be ignored

20351c2

Add legitimate globals to ignored-globals.txt. All other Stackless globals should be moved to runtime or interpreter state.

akruis pushed a commit to akruis/cpython that referenced this pull request Oct 29, 2018

Stackless issue python#152: Eliminate the variable types_mod.

adec2f2

It was only used during module initialization.

akruis pushed a commit to akruis/cpython that referenced this pull request Oct 29, 2018

Stackless issue python#152: Move globals from slp_tranfer to _PyRuntime

24542d9

Add sub-struct transfer to _PyRuntime.st.

akruis pushed a commit to akruis/cpython that referenced this pull request Nov 1, 2018

Fix a compile error in non-debug builds.

81dfc51

Introduced by commit 6e1250a / issue python#152.

akruis pushed a commit to akruis/cpython that referenced this pull request Nov 12, 2018

Stackless issue python#152: fix clang warnings caused by commit 0727a8e.

a05f330

The commit used a C11 feature. Unfortunately only clang emits a warning.

jaraco pushed a commit that referenced this pull request Dec 2, 2022

Don't automerge if there is "DO-NOT-MERGE" label and "CLA not signed"…

15c47c8

… label (#152)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

bpo-16011: Clarify behavior of contains in user defined classes #152

bpo-16011: Clarify behavior of contains in user defined classes #152

aktech commented Feb 18, 2017 •

edited

Loading

the-knights-who-say-ni commented Feb 18, 2017

aktech commented Feb 21, 2017

berkerpeksag Feb 22, 2017

berkerpeksag Feb 22, 2017

zhangyangyu Feb 22, 2017

methane commented Feb 22, 2017

aktech commented Feb 22, 2017

aktech commented Feb 26, 2017

bitdancer commented Feb 27, 2017 •

edited

Loading

aktech commented Mar 3, 2017

bitdancer commented Mar 3, 2017

aktech commented Mar 3, 2017

aktech commented Mar 11, 2017

bitdancer Mar 15, 2017

aktech commented Mar 19, 2017

bitdancer commented Mar 19, 2017

aktech commented Mar 27, 2017

ncoghlan commented Mar 28, 2017

Mariatta commented Mar 28, 2017

ncoghlan commented May 28, 2017

miss-islington commented Sep 13, 2017

miss-islington commented Sep 13, 2017

bpo-16011: Clarify behavior of __contains__ in user defined classes #152

bpo-16011: Clarify behavior of __contains__ in user defined classes #152

Conversation

aktech commented Feb 18, 2017 • edited Loading

the-knights-who-say-ni commented Feb 18, 2017

aktech commented Feb 21, 2017

berkerpeksag Feb 22, 2017

Choose a reason for hiding this comment

berkerpeksag Feb 22, 2017

Choose a reason for hiding this comment

zhangyangyu Feb 22, 2017

Choose a reason for hiding this comment

methane commented Feb 22, 2017

aktech commented Feb 22, 2017

aktech commented Feb 26, 2017

bitdancer commented Feb 27, 2017 • edited Loading

aktech commented Mar 3, 2017

bitdancer commented Mar 3, 2017

aktech commented Mar 3, 2017

aktech commented Mar 11, 2017

bitdancer Mar 15, 2017

Choose a reason for hiding this comment

aktech commented Mar 19, 2017

bitdancer commented Mar 19, 2017

aktech commented Mar 27, 2017

ncoghlan commented Mar 28, 2017

Mariatta commented Mar 28, 2017

ncoghlan commented May 28, 2017

miss-islington commented Sep 13, 2017

miss-islington commented Sep 13, 2017

bpo-16011: Clarify behavior of contains in user defined classes #152

bpo-16011: Clarify behavior of contains in user defined classes #152

aktech commented Feb 18, 2017 •

edited

Loading

bitdancer commented Feb 27, 2017 •

edited

Loading