On Tue, Nov 14, 2017 at 4:49 AM, Nick Coghlan wrote:
> On 14 November 2017 at 09:41, Guido van Rossum wrote:
> >
> > Thanks, I am happy now with the PEP, except for one detail: maybe
> > `__mro_entry__` should always return a tuple and then maybe renamed to
> > `__mro_entries__`. (See debate at
On 14 November 2017 at 09:41, Guido van Rossum wrote:
> On Fri, Nov 10, 2017 at 8:54 AM, Ivan Levkivskyi
> wrote:
>>
>> On 10 November 2017 at 17:43, Guido van Rossum wrote:
>>>
>>> There seem to be some action items from this thread that I haven't seen
>>> reflected in the PEP source code yet.
On Fri, Nov 10, 2017 at 8:54 AM, Ivan Levkivskyi
wrote:
> On 10 November 2017 at 17:43, Guido van Rossum wrote:
>
>> There seem to be some action items from this thread that I haven't seen
>> reflected in the PEP source code yet.
>> [...snip...]
>> Then the next step I propose is a PR with a ful
On Fri, Nov 10, 2017 at 10:26 PM, Ivan Levkivskyi
wrote:
> On 10 November 2017 at 21:19, Koos Zevenhoven wrote:
>
>> On Fri, Nov 10, 2017 at 8:33 PM, Ivan Levkivskyi
>> wrote:
>>
>>> On 10 November 2017 at 18:39, Koos Zevenhoven wrote:
>>>
On Wed, Sep 27, 2017 at 12:28 PM, Ivan Levkivskyi
On 10 November 2017 at 21:19, Koos Zevenhoven wrote:
> On Fri, Nov 10, 2017 at 8:33 PM, Ivan Levkivskyi
> wrote:
>
>> On 10 November 2017 at 18:39, Koos Zevenhoven wrote:
>>
>>> On Wed, Sep 27, 2017 at 12:28 PM, Ivan Levkivskyi
>>> wrote:
>>>
>>>
After creating the class,
>>
On Fri, Nov 10, 2017 at 8:33 PM, Ivan Levkivskyi
wrote:
> On 10 November 2017 at 18:39, Koos Zevenhoven wrote:
>
>> On Wed, Sep 27, 2017 at 12:28 PM, Ivan Levkivskyi
>> wrote:
>>
>>>
>>>
>>
>>> After creating the class,
>>> the original bases are saved in ``__orig_bases__`` (currently this
On 10 November 2017 at 18:39, Koos Zevenhoven wrote:
> On Wed, Sep 27, 2017 at 12:28 PM, Ivan Levkivskyi
> wrote:
>
>>
>>
>
>> After creating the class,
>> the original bases are saved in ``__orig_bases__`` (currently this is also
>> done by the metaclass).
>>
>>
> Those are *still* bases,
On Wed, Sep 27, 2017 at 12:28 PM, Ivan Levkivskyi
wrote:
> Previously I posted PEP 560 two weeks ago, while several other PEPs were
> also posted, so it didn't get much of attention. Here I post the PEP 560
> again, now including the full text for convenience of commenting.
>
>
[..]
>
> A
On 10 November 2017 at 17:43, Guido van Rossum wrote:
> Hey Ivan,
>
> There seem to be some action items from this thread that I haven't seen
> reflected in the PEP source code yet.
> [...snip...]
> Then the next step I propose is a PR with a full implementation. After
> that I'll likely approve
Hey Ivan,
There seem to be some action items from this thread that I haven't seen
reflected in the PEP source code yet.
- Change the title (I like "Core support for typing module and generic
types" but maybe it can be shortened to "Core support for generics in the
typing module" -- if you like tha
On 29 September 2017 at 08:57, Nick Coghlan wrote:
> On 29 September 2017 at 08:04, Ivan Levkivskyi
> wrote:
> >> How would you feel about calling it "__mro_entry__", as a mnemonic for
> >> "the substitute entry to use instead of this object when calculating a
> >> subclass MRO"?
> >
> > I don't
On 29 September 2017 at 10:14, Victor Stinner
wrote:
> > Title: Core support for generic types
>
> Would it be possible to mention "typing" somewhere in the title? If
> you don't know the context, it's hard to understand that the PEP is
> related to type annotation and type checks. At least just
> Title: Core support for generic types
Would it be possible to mention "typing" somewhere in the title? If
you don't know the context, it's hard to understand that the PEP is
related to type annotation and type checks. At least just from the
title.
Victor
On 29 September 2017 at 08:04, Ivan Levkivskyi wrote:
> On 28 September 2017 at 08:27, Nick Coghlan wrote:
>>
>> On 27 September 2017 at 19:28, Ivan Levkivskyi
>> wrote:
>> > If an object that is not a class object appears in the bases of a class
>> > definition, the ``__subclass_base__`` is sea
On 28 September 2017 at 08:27, Nick Coghlan wrote:
> On 27 September 2017 at 19:28, Ivan Levkivskyi
> wrote:
> > If an object that is not a class object appears in the bases of a class
> > definition, the ``__subclass_base__`` is searched on it. If found,
> > it is called with the original tuple
On 27 September 2017 at 19:28, Ivan Levkivskyi wrote:
> If an object that is not a class object appears in the bases of a class
> definition, the ``__subclass_base__`` is searched on it. If found,
> it is called with the original tuple of bases as an argument. If the result
> of the call is not ``
On 27 September 2017 at 18:08, Terry Reedy wrote:
> On 9/27/2017 5:28 AM, Ivan Levkivskyi wrote:
>
> It is proposed to add two special methods ``__class_getitem__`` and
>> ``__subclass_base__`` to the core CPython for better support of
>> generic types.
>>
>
> I would not be concerned about anyon
On 9/27/2017 5:28 AM, Ivan Levkivskyi wrote:
Abstract
Initially PEP 484 was designed in such way that it would not introduce
*any* changes to the core CPython interpreter. Now type hints and
the ``typing`` module are extensively used by the community, e.g. PEP 526
and PEP 557 extend th
Previously I posted PEP 560 two weeks ago, while several other PEPs were
also posted, so it didn't get much of attention. Here I post the PEP 560
again, now including the full text for convenience of commenting.
--
Ivan
PEP: 56
I have written another short PEP that proposes some minor changes to core
CPython interpreter
for better support of generic types. I will be grateful for comments and
suggestions:
https://www.python.org/dev/peps/pep-0560/
--
Ivan
___
Python-ideas mailin
20 matches
Mail list logo
