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 at gmail.com> wrote:
> On 16 November 2017 at 00:20, Jim J. Jewett <jimjjewett at 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 at gmail.com | Brisbane, Australia
>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171115/a52f7c00/attachment.html>