Trivial changes: improved documentations for __contains__#21619
Conversation
|
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA). Recognized GitHub usernameWe couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames: This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. You can check yourself to see if the CLA has been received. Thanks again for the contribution, we look forward to reviewing it! |
|
How is the current wording misleading? I don't follow what you're saying about returning a boolean. Also, I think we're losing something important if the docstrings for dunder methods stops telling users about the associated operators, |
|
I think the misleading part is As for the other modification, which is in the set-object, it's just to make the docstrings for all the basic datatypes similar. Another way to do this, is making the docstrings = Also, |
|
I'm going to unassign from this one. I don't really buy into the notion that people are going to misread the docstring and believe that |
The previous strings for
list.__contains__.__doc__andtuple.__contains__.__doc__were"Return key in self.". This is misleading, because__contains__returns a boolean.I modified these strings and the string in
set.__contains__.__doc__to a semilar format of that indict.__contains__.__doc__.