Hi Martin,
I think that we are on the same page. The differences in the approaches
here makes me think that I should attempt a PEP487-based migration of
traitlets and see if there is a major roadblock.
After all, that would probably be a good test for the PEP if the aim is to
enable usecases like
On 07/29/2016 08:01 AM, Martin Teichmann wrote:
... Also, while researching other
people's code when I wrote PEP 487, I couldn't find any such code
elsewhere, yet I found a lot of code where people took the wildest
measure to prevent a metaclass in doing its job on the first class it
is used for
Hi Sylvain,
thanks for the example, it's a great example to illustrate PEP 487 and
its design decisions.
> What it does is setting some class attributes that are required for certain
> types of descriptors to be able to initialize themselves.
>
> class MetaHasTraits(MetaHasDescriptors):
>
> "
In the traitlets library I mentioned earlier, we do have a need for this.
The corresponding function is called `setup_class`.
What it does is setting some class attributes that are required for certain
types of descriptors to be able to initialize themselves.
class MetaHasTraits(MetaHasDescriptor
Hello,
there has been quite some discussion on why PEP 487's
__init_subclass__ initializes subclasses, and not the class itself. I
think the most important details have been already thoroughly
discussed here.
One thing I was missing in the discussion is practical examples. I
have been using PEP
On 29 July 2016 at 00:06, Joao S. O. Bueno wrote:
> Maybe then adding a `run_init_subclass` class decorator on the stdlib
> to go along with the pep?
> It should be a two liner that would avoid boiler plate done wrong -
> but more important than thatm is that it being documented alog with
> the _
On 28 July 2016 at 10:53, Nick Coghlan wrote:
> On 28 July 2016 at 23:12, Joao S. O. Bueno wrote:
>> Although I know it is not straightforward to implement (as the
>> "metaclass" parameter is not passed to the metaclass __new__ or
>> __init__), wouldn't it make sense to make it be passed to
>> _
On 28 July 2016 at 23:12, Joao S. O. Bueno wrote:
> Although I know it is not straightforward to implement (as the
> "metaclass" parameter is not passed to the metaclass __new__ or
> __init__), wouldn't it make sense to make it be passed to
> __init_subclass__ just like all other keywords? (the
On 28 July 2016 at 04:26, Nick Coghlan wrote:
> On 28 July 2016 at 13:55, Joao S. O. Bueno wrote:
>> Actually, as documented on the PEP (and I just confirmed at a Python
>> 3.5 prompt),
>> you actually can't use custom keywords for class defintions. This PEP
>> fixes that, but at the same time ma
On 28 July 2016 at 13:55, Joao S. O. Bueno wrote:
> Actually, as documented on the PEP (and I just confirmed at a Python
> 3.5 prompt),
> you actually can't use custom keywords for class defintions. This PEP
> fixes that, but at the same time makes any other class reserved
> keyword impossible in
On 27 July 2016 at 22:30, Nick Coghlan wrote:
> On 28 July 2016 at 03:56, Joao S. O. Bueno wrote:
>> Otherwise, I'd suggest at least some PEP rewording to make explicit
>> the fact it is not run on the class it is defined at all. (I can help
>> with that, but I'd rather see it implemented as abo
On 28 July 2016 at 03:56, Joao S. O. Bueno wrote:
> Otherwise, I'd suggest at least some PEP rewording to make explicit
> the fact it is not run on the class it is defined at all. (I can help
> with that, but I'd rather see it implemented as above).
This is covered in the PEP:
https://www.python
Hi - sorry for steppign in late - I've just reread the PEP and tried
out the reference implementation, and I have two sugestions/issues
with it as is:
1)
Why does `__init_subclass__` is not run in the class it is defined itself??
That makes no sense to me as in very unpythonic.
I applied the pat
On 25 July 2016 at 03:00, Guido van Rossum wrote:
> Yes.
OK, we can cover that in the documentation - if folks want to emulate
what happens during class construction after the fact, they'll need to
do:
cls.name = attr
attr.__set_name__(cls, "name")
Semantically, I agree that approach ma
Yes.
--Guido (mobile)
On Jul 24, 2016 9:34 AM, "Ethan Furman" wrote:
> On 07/24/2016 08:20 AM, Guido van Rossum wrote:
>
> I am very much against this. The two are not at all like each other. Also,
>> what's the use case?
>>
>
> To be clear: you are against the automatic calling of __set_name_
On 07/24/2016 08:20 AM, Guido van Rossum wrote:
I am very much against this. The two are not at all like each other. Also,
what's the use case?
To be clear: you are against the automatic calling of __set_name__ and/or
__set_owner__ when using
setattr outside of class creation? Said another
I am very much against this. The two are not at all like each other. Also,
what's the use case?
On Sunday, July 24, 2016, Martin Teichmann wrote:
> Hi list, Hi Nick,
>
> Sorry for my delayed response, it is summer here...
>
> > However, phrasing it that way suggest that it's possible we *did* mi
Hi list, Hi Nick,
Sorry for my delayed response, it is summer here...
> However, phrasing it that way suggest that it's possible we *did* miss
> something in the PEP: we haven't specified whether or not __set_name__
> should be called when someone does someone does "cls.attr = descr".
> Given the
In any case I find this PEP great. If we can implement a library like
traitlets only using these new hooks without a custom metaclass, it will be
a big improvement.
My only concern was that calling the hook __set_name__ was misleading while
it could not set the name at all and do pretty much anyth
Whoa. That's not how I read it.
--Guido (mobile)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 21 July 2016 at 03:40, Sylvain Corlay wrote:
> My point is that in any real-world implementation of traits, __set_name__
> will do a lot more than setting the name, which makes the name misleading.
I suspect the point of disagreement on that front may be in how we
view the names of the existin
Hi Nick,
Thank you for your reply. I understand your argument about using protocol
method names that are
very specific to a particular intended use case.
Interestingly, the one example that is provided in the PEP is that of a
"trait" which is pretty much the same as traitlets. (traitlets started
Hi Sylvain,
Thanks for getting in touch! The traitlets library sounds interesting,
and provides good additional evidence that this is a capability that
folks are interested in having available.
On 20 July 2016 at 15:26, Sylvain Corlay wrote:
> My understanding is that the proposed __set_name__ i
Hello,
This is my first post on python-dev and I hope that I am not breaking any
rule.
I wanted to react on the discussion regarding PEP487.
This year, we have been working on a refactoring of the `traitlets`
library, an implementation of the descriptor pattern that is used in
Project Jupyter /
Thanks for clarifying.
On Tue, Jul 19, 2016 at 10:34 AM Nick Coghlan wrote:
> On 19 July 2016 at 16:41, Neil Girdhar wrote:
> > Yes, I see what you're saying. However, I don't understand why
> > __init_subclass__ (defined on some class C) cannot be used to implement
> the
> > checks required
On 19 July 2016 at 16:41, Neil Girdhar wrote:
> Yes, I see what you're saying. However, I don't understand why
> __init_subclass__ (defined on some class C) cannot be used to implement the
> checks required by @abstractmethod instead of doing it in ABCMeta. This
> would prevent metaclass confli
Yes, I see what you're saying. However, I don't understand why
__init_subclass__ (defined on some class C) cannot be used to implement the
checks required by @abstractmethod instead of doing it in ABCMeta. This
would prevent metaclass conflicts since you could use @abstractmethod with
any metacl
On 19 July 2016 at 09:26, Neil Girdhar wrote:
> Yes, I'm very excited about this!
>
> Will this mean no more metaclass conflicts if using @abstractmethod?
ABCMeta and EnumMeta both create persistent behavioural differences
rather than only influencing subtype definition, so they'll need to
remain
Yes, I'm very excited about this!
Will this mean no more metaclass conflicts if using @abstractmethod?
On Sun, Jul 17, 2016 at 12:59 PM Guido van Rossum wrote:
> This PEP is now accepted for inclusion in Python 3.6. Martin,
> congratulations! Someone (not me) needs to review and commit your
> c
Great job, Martin! Thanks for seeing this through. :)
-eric
On Sun, Jul 17, 2016 at 10:57 AM, Guido van Rossum wrote:
> This PEP is now accepted for inclusion in Python 3.6. Martin,
> congratulations! Someone (not me) needs to review and commit your
> changes, before September 12, when the 3.6
> This PEP is now accepted for inclusion in Python 3.6. Martin,
> congratulations!
Thank you very much! What a great news!
Greetings
Martin
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
On 07/17/2016 09:57 AM, Guido van Rossum wrote:
This PEP is now accepted for inclusion in Python 3.6. Martin,
congratulations!
Congratulations, Martin!
I'm looking forward to this feature. :)
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@pytho
This PEP is now accepted for inclusion in Python 3.6. Martin,
congratulations! Someone (not me) needs to review and commit your
changes, before September 12, when the 3.6 feature freeze goes into
effect (see https://www.python.org/dev/peps/pep-0494/#schedule).
On Sun, Jul 17, 2016 at 4:32 AM, Mart
Hi Guido, Hi Nick, Hi list,
so I just updated PEP 487, you can find it here:
https://github.com/python/peps/pull/57 if it hasn't already been
merged. There are no substantial updates there, I only updated the
wording as suggested, and added some words about backwards
compatibility as hinted by Nic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/14/2016 02:10 PM, Brett Cannon wrote:
> On Thu, 14 Jul 2016 at 11:05 Tres Seaver
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 07/14/2016 11:47 AM, Guido van Rossum wrote:
>>
>>> If you intend a PR as a base for discuss
On Thu, 14 Jul 2016 at 11:05 Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/14/2016 11:47 AM, Guido van Rossum wrote:
>
> > If you intend a PR as a base for discussion you can add a comment
> > saying e.g. "Don't merge yet". If you call out @gvanrossum, GitHub
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/14/2016 11:47 AM, Guido van Rossum wrote:
> If you intend a PR as a base for discussion you can add a comment
> saying e.g. "Don't merge yet". If you call out @gvanrossum, GitHub
> will make sure I get a message about it.
FWIW, I often use a Gi
I just reviewed the changes you made, I like __set_name__(). I'll just
wait for your next update, incorporating Nick's suggestions. Regarding
who merges PRs to the PEPs repo, since you are the author the people
who merge don't pass any judgment on the changes (unless it doesn't
build cleanly or may
Hi Nick, hi list,
> It would be worth spelling out the end result of the new behaviour in
> the PEP to make sure it's what we want. Trying to reason about how
> that code works is difficult, but looking at some class definition
> scenarios and seeing how they behave with the old semantics and the
Hi Guido, Hi list,
Thanks for the nice review! I applied followed up your ideas and put
it into a github pull request: https://github.com/python/peps/pull/53
Soon we'll be working there, until then, some responses to your comments:
> I wonder if this should be renamed to __set_name__ or somethin
On 14 July 2016 at 08:46, Guido van Rossum wrote:
> On Wed, Jul 13, 2016 at 7:15 AM, Martin Teichmann
> wrote:
>> Another small change should be noted here: in the current implementation of
>> CPython, ``type.__init__`` explicitly forbids the use of keyword arguments,
>> while ``type.__new__`` a
FWIW I copied the version you posted into the peps repo already, since
it provides a significant update to the last version there.
On Wed, Jul 13, 2016 at 2:02 PM, Guido van Rossum wrote:
> I'm reviewing this now.
>
> Martin, can you please submit the new version of your PEP as a Pull
> Request t
On Wed, Jul 13, 2016 at 7:15 AM, Martin Teichmann
wrote:
> Hi list,
>
> another round for PEP 487, is there any chance it still makes it into
> Python 3.6?
Sure, feature freeze isn't until September
(https://www.python.org/dev/peps/pep-0494/).
> The PEP should be effectively done, I updated the
I'm reviewing this now.
Martin, can you please submit the new version of your PEP as a Pull
Request to the new peps repo on GitHub? https://github.com/python/peps
--Guido
On Wed, Jul 13, 2016 at 7:45 AM, Nick Coghlan wrote:
> On 14 July 2016 at 00:15, Martin Teichmann wrote:
>> Hi list,
>>
>>
On 14 July 2016 at 00:15, Martin Teichmann wrote:
> Hi list,
>
> another round for PEP 487, is there any chance it still makes it into
> Python 3.6?
>
> The PEP should be effectively done, I updated the examples in it,
> given that I implemented the PEP I could actually test the examples,
> so now
Hi list,
another round for PEP 487, is there any chance it still makes it into
Python 3.6?
The PEP should be effectively done, I updated the examples in it,
given that I implemented the PEP I could actually test the examples,
so now they work.
The implementation is at http://bugs.python.org/issu
> This is an area of exceeding subtlety (and also not very well
> documented/specified, probably). I'd worry that changing anything here
> might break some code. When a metaclass overrides neither __init__ nor
> __new__, keyword args will not work because type.__init__ forbids
> them. However when
On Sat, Jul 2, 2016 at 10:50 AM, Martin Teichmann
wrote:
> Hi list,
>
> so this is the next round for PEP 487. During the last round, most of
> the comments were in the direction that a two step approach for
> integrating into Python, first in pure Python, later in C, was not a
> great idea and ev
Hi Nick,
thanks for the nice review!
> I think making __init_subclass__ implicitly a class method is still
> the right thing to do if this proposal gets accepted, we'll just want
> to see if we can do something to tidy up that aspect of the
> documentation at the same time.
I could write some do
On 2 July 2016 at 10:50, Martin Teichmann wrote:
> Hi list,
>
> so this is the next round for PEP 487. During the last round, most of
> the comments were in the direction that a two step approach for
> integrating into Python, first in pure Python, later in C, was not a
> great idea and everything
Hi list,
so this is the next round for PEP 487. During the last round, most of
the comments were in the direction that a two step approach for
integrating into Python, first in pure Python, later in C, was not a
great idea and everything should be in C directly. So I implemented it
in C, put it on
51 matches
Mail list logo
