A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

Haha, in fact, the function already exists: https://docs.python.org/dev/library/operator.html#operator.contains

Yes, aware of it. in_ is a reverse-argument order __contains__. not_in does not exist.

See, https://discuss.python.org/t/proposed-additions-to-operator/49846/16 for why adding these is potentially is a good idea.

@vstinner One last thing I can do to support this is to provide github use-case search result count:

336 - /operator\.contains\(b, a\)/
480 - /lambda a, b\: a in b/

And I have laid out my reasoning from personal experience in https://discuss.python.org/t/proposed-additions-to-operator/49846/16 providing a contrast with reversal of other functions.

I have made the requested changes; please review again

Thanks for making the requested changes!

@vstinner: please review the changes made to this pull request.

I have made the requested changes; please review again

That's not how that works, you haven't changed anything. You can ask to consider the information though.

• >285 files with /lambda \w+, \w+: operator\.contains\(\w+, \w+\)/
• >96 files with /return operator.contains\(\w+, \w+\)/

Ideally you would use this: /lambda (\w+), (\w+): \1 in \2/, but that's not supported on GitHub.

I agree with Victor and the others who have commented on the Discourse thread that it's not worth it to add a function that is identical to operator.contains() except for the reversed order of the arguments. It's not a goal for the operator module to be exhaustive over all possible operator-like convenience functions, and nor should it be.

I can see more of an argument for the not_in addition.

Hmm, wouldn't it be better to add not_contains() or contains_not() then? Otherwise you expect in_() to exist as well.

Personally, I would expect in if you give me contains so that's why I'm actually supportive of the in_ and not_in. Another reason is that I have is_ and not_is so... having the same for the in keyword felt natural to me.

I suggest you close the issue and PR and create new ones for not_contains() or contains_not().

It's not a goal for the operator module to be exhaustive over all possible operator-like convenience functions, and nor should it be.

I agree, my motivation is based on a need and careful consideration.

People are implementing in_ in their own libraries. ~400 implementations with the exact search. How many more with different argument names or similar variations - unknown.

And I have explained why it makes sense to me and what sort of functionality it supports.

The fact these somewhat naturally fit in between contains and is&not_is is a supporting argument, not primary motivation.

I have re-evaluated and incorporated feedback as best as I could.

So I wavered a bit on this one, but came back to my initial position.

What made up my mind was the fact that in and not in provide default argument order in ast:

Compare(
    left=Name(id='a', ctx=Load()),
        ops=[In()],
        comparators=[
        Name(id='b', ctx=Load())]))])

So they are generally useful utilities and also important functions for frameworks that build on ast.

not_contains is not as essential, because it follows argument order that is present in __contains__. Which is bound to return a bool/truth value, and is automatically inverted when invoked with not in. So there is no usefulness argument for it as __contains__ satisfy both in and not in.

While ast has In() and NotIn(), which are 2 independent operators.

I have made the requested changes; please review again

Thanks for making the requested changes!

@vstinner: please review the changes made to this pull request.

I have made the requested changes; please review again

Again: don't say that if you haven't changed anything. You're supposed to "have made the requested changes".

If vstinner agrees with you after posting the new information, he'll drop his stale review. Otherwise you need to do what he told you to do.

@vstinner: please review the changes made to this pull request.

@AlexWaygood and I are against adding operator.in_(). Updating the same PR is not going to change my mind.

Updating the same PR is not going to change my mind.

I just thought providing new perspectives / arguments and addressing criticism can have an impact.

You kinda left me hanging there, I addressed criticism so I was expecting some response to why my reasoning doesn't cut it.

And I didn't mean to ping you this way second time, I was just testing how things work as there was still "change requested" and I thought maybe it reappeared because I converted it to draft and then back. Anyway.

Ok, closing this. Thank you for your time considering this.

Again: don't say that if you haven't changed anything. You're supposed to "have made the requested changes".

If vstinner agrees with you after posting the new information, he'll drop his stale review. Otherwise you need to do what he told you to do.

He didn't tell me to do anything.

Generally, I am very confused by your interference. I don't need you explaining me the obvious.

He didn't tell me to do anything.

He told you implicitly:

Haha, in fact, the function already exists: https://docs.python.org/dev/library/operator.html#operator.contains

If the function already exists (with different argument order), that means that it's not needed. (There should be one...)

I don't need you explaining me the obvious.

I am confused as to why you stated you made changes when you didn't, that's all. I'm totally fine with you arguing about it to try to change our mind.

I'm open to consider adding "not contains", but I'm not sure about the best name for that.

But I don't think that we should add in_(a,b) to just exchange argument order compare to contains(a,b).

I have no interest in not_contains, nor do I see its value. I will leave this to someone else then.

I have no interest in not_contains, nor do I see its value. I will leave this to someone else then.

Ok. Thanks for your contribution anyway. I was close to merge your PR when I saw that operator.in_() already exists, sorry about that :-) The PR itself LGTM, it just that we decided that in_() and contains() are redundant.

No worries at all, maybe it is for the best.

These 2 functions wouldn't solve the root of what is causing problems to me anyways.

Maybe I will have some better ideas down the line.