(original) (raw)

Nick is exactly right here. Jim, if you want to propose alternative wording, then we could consider it.

--
Ivan


On 15 November 2017 at 16:37, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 16 November 2017 at 00:20, Jim J. Jewett <jimjjewett@gmail.com> wrote:
I \*think\* the following will happen:

"NewList\[int\]" will be evaluated, and \_\_class\_getitem\_\_ called, so
that the bases tuple will be (A, GenericAlias(NewList, int), B)

\# (A) I \*think\* \_\_mro\_entries\_\_ gets called with the full tuple,
\# instead of just the object it is found on.
\# (B) I \*think\* it is called on the results of evaluating
\# the terms within the tuple, instead of the original
\# string representation.
\_tmp = \_\_mro\_entries\_\_(A, GenericAlias(NewList, int), B)

\# (C) I \*think\* \_\_mro\_entries\_\_ returns a replacement for
\# just the single object, even though it was called on
\# the whole tuple, without knowing which object it
\# represents.
bases = (A, \_tmp, B)

My understanding of the method signature:

def \_\_mro\_entries\_\_(self, orig\_bases):
...
return replacement\_for\_self

My assumption as to the purpose of the extra complexity was:

- given orig\_bases, a method could avoid injecting bases already listed if it wanted to
- allowing multiple items to be returned provides a way to programmatically combine mixins without having to define a new subclass for each combination

Cheers,
Nick.

--
Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia