Message280093
| Author |
wim.glenn |
| Recipients |
docs@python, r.david.murray, rhettinger, wim.glenn |
| Date |
2016年11月04日.22:08:35 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1478297315.93.0.153424004861.issue28617@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Perhaps it's better to call a spade a spade here - if they're implemented as comparisons, then why not document them as comparisons?
A colleague has mentioned one point that sets `in` and `not in` apart from the other comparisons in the table: comparisons are generally made between objects of the same type (with the exception of numbers). But membership "comparisons" are made between different types (with the exception of substring checks).
Here is an alternate patch which leaves the table alone, but corrects the inaccuracy in the note. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2016年11月04日 22:08:35 | wim.glenn | set | recipients:
+ wim.glenn, rhettinger, r.david.murray, docs@python |
| 2016年11月04日 22:08:35 | wim.glenn | set | messageid: <1478297315.93.0.153424004861.issue28617@psf.upfronthosting.co.za> |
| 2016年11月04日 22:08:35 | wim.glenn | link | issue28617 messages |
| 2016年11月04日 22:08:35 | wim.glenn | create |
|