[issue31042] Inconsistency in documentation of operator.index

2021-11-30 Thread Joseph Fox-Rabinovitz
Joseph Fox-Rabinovitz added the comment: I closed the issue (it's already been rejected), primarily based on > a.__index__ = is an unauthorized use of a *reserved* word and the > effect of such usage is not and need not be documented. > The entry for __*__ does include "*Any* use of __*__

[issue31042] Inconsistency in documentation of operator.index

2021-11-30 Thread Irit Katriel
Irit Katriel added the comment: My reading of the discussion is that we are not going to make any changes to the docs. Please correct me if I missed anything. -- nosy: +iritkatriel resolution: -> rejected status: open -> pending ___ Python tracker

[issue31042] Inconsistency in documentation of operator.index

2017-07-28 Thread Terry J. Reedy
Terry J. Reedy added the comment: To me, 'roughly' is wrong. Either the equivalence is exact, or it is completely absent . There is no 'nearly' or 'roughly' about this situation. This is difference from iterator_class_x(args) being mathematically equivalent to generator_function_y(args) in

[issue31042] Inconsistency in documentation of operator.index

2017-07-27 Thread Joseph Fox-Rabinovitz
Joseph Fox-Rabinovitz added the comment: I brought up the issue because it was really a point of confusion for me. Could we make the change to "Roughly equivalent" and make that a link to https://docs.python.org/3/reference/datamodel.html#special-method-lookup? That would make it clear how the lo

[issue31042] Inconsistency in documentation of operator.index

2017-07-27 Thread R. David Murray
R. David Murray added the comment: I agree with Raymond. I'm not sure that adding roughly is going to decrease the possibility of confusion, but I won't object to it. In a way, it's too bad we didn't make the attribute lookup machinery look up all dunder methods on the class, so that a.__inde

[issue31042] Inconsistency in documentation of operator.index

2017-07-27 Thread Raymond Hettinger
Raymond Hettinger added the comment: This seems like a generic issue for magic methods and is already covered by "for custom classes, implicit invocations of special methods are only guaranteed to work correctly if defined on an object’s type, not in the object’s instance dictionary." While y

[issue31042] Inconsistency in documentation of operator.index

2017-07-25 Thread Joseph Fox-Rabinovitz
New submission from Joseph Fox-Rabinovitz: The docs for [`operator.index`][1] and `operator.__index__` state that > Return *a* converted to an integer. Equivalent to `a.__index__()`. The first sentence is correct, but the second is not. First of all, we have the data model [docs][2]: > For cu

[issue31042] Inconsistency in documentation of operator.index

2017-07-25 Thread Joseph Fox-Rabinovitz
Changes by Joseph Fox-Rabinovitz : -- type: behavior -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https: