(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\_selfMy 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 combinationCheers,Nick.
--Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia