Hello all, Noticed that "MRO" is not actually defined in the PEP and it seems like it should be. Probably in the Performance section where the abbreviation is first used outside of a function name. -Brent On Thu, Nov 16, 2017 at 7:22 AM, Ivan Levkivskyi <levkivskyi at gmail.com> wrote: > On 16 November 2017 at 07:56, Nick Coghlan <ncoghlan at gmail.com> wrote: > >> On 16 November 2017 at 04:39, Ivan Levkivskyi <levkivskyi at gmail.com> >> wrote: >> >>> Nick is exactly right here. Jim, if you want to propose alternative >>> wording, then we could consider it. >>> >> >> Jim also raised an important point that needs clarification at the spec >> level: given multiple entries in "orig_bases" with __mro_entries__ methods, >> do all such methods get passed the *same* orig_bases tuple? Or do they >> receive partially resolved ones, such that bases listed before them have >> already been resolved to their MRO entries by the time they run. >> >> >> > Yes, they all get the same initial bases tuple as an argument. Passing > updated ones will cost a bit more and I don't think it will be needed (in > the worst case a base can resolve another base by calling its > __mro_entries__ manually). > I will clarify this in the PEP. > > -- > Ivan > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > brent.bejot%40gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171116/52557893/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4