On 16 November 2017 at 18:58, Ethan Furman wrote:
> On 11/16/2017 04:22 AM, Ivan Levkivskyi wrote:
>
>> On 16 November 2017 at 07:56, Nick Coghlan wrote:
>>
>
> Jim also raised an important point that needs clarification at the spec
>>>
>> >> level: given multiple entries in "orig_bases" with __m
On 11/16/2017 04:22 AM, Ivan Levkivskyi wrote:
On 16 November 2017 at 07:56, Nick Coghlan wrote:
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*
On Thu, Nov 16, 2017 at 6:28 PM, brent bejot wrote:
> 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.
>
>
I don't think it will hurt if I
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
wrote:
> On 16 November 2017 at 07:56,
On 16 November 2017 at 07:56, Nick Coghlan wrote:
> On 16 November 2017 at 04:39, Ivan Levkivskyi
> 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 spe
On 16 November 2017 at 04:39, Ivan Levkivskyi 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_entr
On 11/14/2017 3:26 PM, Ivan Levkivskyi wrote:
After some discussion on python-ideas, see
https://mail.python.org/pipermail/python-ideas/2017-September/047220.html,
this PEP received positive comments. The updated version that takes into
account the comments that appeared in the discussion so fa
On Wed, Nov 15, 2017 at 5:37 PM, Nick Coghlan wrote:
> On 16 November 2017 at 00:20, Jim J. Jewett 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)
>>
>
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 wrote:
> On 16 November 2017 at 00:20, Jim J. Jewett wrote:
>
>> I *think* the following will happen:
>>
>> "NewList[int]" will be eva
On 16 November 2017 at 00:20, Jim J. Jewett 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
For anyone confused about similar things, I expect you to be interested in
my post on python-ideas from today:
https://mail.python.org/pipermail/python-ideas/2017-November/047896.html
––Koos
On Wed, Nov 15, 2017 at 4:20 PM, Jim J. Jewett wrote:
> (1) I found the following (particularly "base
(1) I found the following (particularly "bases classes") very confusing:
"""
If an object that is not a class object appears in the bases of a class
definition, then ``__mro_entries__`` is searched on it. If found,
it is called with the original tuple of bases as an argument. The result
of the c
On 15 November 2017 at 06:26, Ivan Levkivskyi wrote:
> After some discussion on python-ideas, see https://mail.python.org/
> pipermail/python-ideas/2017-September/047220.html, this PEP received
> positive comments. The updated version that takes into account the comments
> that appeared in the di
After some discussion on python-ideas, see
https://mail.python.org/pipermail/python-ideas/2017-September/047220.html,
this PEP received positive comments. The updated version that takes into
account the comments that appeared in the discussion so far is available at
https://www.python.org/dev/peps/
On 10/14/2017 11:30 AM, Ivan Levkivskyi wrote:
As a side note, I don't think elimination of metaclasses should be a "goal by
itself".
This is a powerful and flexible mechanism, but there are specific situations
where
metaclasses don't work well because of e.g. frequent conflicts or performance
On 14 October 2017 at 18:14, Ethan Furman wrote:
> On 10/14/2017 08:57 AM, Ivan Levkivskyi wrote:
>
>>
>> Could you please elaborate more what is wrong with PEP 560 and what do
>> you mean by "class definition protections"
>>
>
> Nothing is wrong with PEP 560. What I am referring to is:
>
[snip]
On 15 October 2017 at 02:14, Ethan Furman wrote:
> On 10/14/2017 08:57 AM, Ivan Levkivskyi wrote:
>
>> On 14 October 2017 at 17:49, Ethan Furman wrote:
>>
>
> The problem with PEP 560 is that it doesn't allow the class definition
>>>
>> >> protections that a metaclass does.
>
>>
>> Since the disc
On 10/14/2017 08:57 AM, Ivan Levkivskyi wrote:
On 14 October 2017 at 17:49, Ethan Furman wrote:
The problem with PEP 560 is that it doesn't allow the class definition
>> protections that a metaclass does.
Since the discussion turned to PEP 560, I can say that I don't want this
> to be a ge
18 matches
Mail list logo
