Hi Greg, Hi List,
Greg wrote:
> class MyClass(B, Mixin):
> >"whatever"
> >
> > this leads to an MRO of MyClass -> B -> Mixin -> A -> object.
>
> If you do the tp_new stuff correctly at the C level, you can still
> create such a class. The only limitation is that if Mixin has a __
Hi Phil, Hi List,
unfortunately you do not give enough code to reproduce what you are doing,
but just guessing roughly:
you say that you have a hierarchy like B -> A -> object, with B and A
implemented in C, and then want to use B with a mixin. Programmers with a
non-python background then often
Hi list,
when reading PEP 572 I actually liked it a lot - I think it's actually
a cool idea. I think it's actually that cool an idea that it should be
made the default way of doing an assignment, over time phasing out the
good ole =.
This would have several benefits:
- people wouldn't have to wo
>> I do worry that things like your autoslots decorator example might be
>> problematic because they create a new class, throwing away a lot of work
>> that was already done. But perhaps the right way to address this would be
>> to move the decision about the instance layout to a later phase? (Not
> Things that will not work if Enum does not have a metaclass:
>
> list(EnumClass) -> list of enum members
> dir(EnumClass) -> custom list of "interesting" items
> len(EnumClass) -> number of members
> member in EnumClass -> True or False
>
> - protection from adding, deleting, and changing membe
> Metaclasses currently tend to serve two distinct purposes:
>
> 1. Actually altering the runtime behaviour of a class and its children in
> non-standard ways (e.g. enums, ABCs, ORMs)
> 2. Boilerplate reduction in class definitions, reducing the amount of code
> you need to write as the author of t
Hi list,
first, a big thanks to the authors of PEP 557! Great idea!
For me, the dataclasses were a typical example for inheritance, to be
more precise, for metaclasses. I was astonished to see them
implemented using decorators, and I was not the only one, citing
Guido:
> I think it would be usef
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):
>
> "
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
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
> 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
Hi,
so I did quite some research on this topic. And what I found out is
that __qualname__ needs to exist in the namespace. Not necessarily
because it should be used, but because it may be modified.
The story goes as follows: the compiler sets the __qualname__ at the
beginning of the class body. W
ub will make sure I get a
> message about it.
>
> I think the substantial discussion about the PEP should remain here in
> python-dev; comments about typos, grammar and other minor editorial
> issues can go on GitHub. Hope this part of the process makes sense!
>
> On Thu, Jul 14,
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
Hi,
> "PEP 487 -- Simpler customisation of class creation"
> https://www.python.org/dev/peps/pep-0487/
> => draft
I would like to get that into Python 3.6. It's already implemented,
including documentation and tests (http://bugs.python.org/issue27366).
Greetings
Martin
_
/issue27366, including
documentation and tests. Unfortunately nobody has reviewed the patch
yet.
The new version of the PEP is attached.
Greetings
Martin
PEP: 487
Title: Simpler customisation of class creation
Version: $Revision$
Last-Modified: $Date$
Author: Martin Teichmann ,
Status: Draft
Type
Hi list,
> I noticed __qualname__ is exposed by locals() while defining a class. This
> is handy but I'm not sure about its status: is it standard or just an
> artifact of the current implementation? (btw, the pycodestyle linter -former
> pep8- rejects its usage). I was unable to find any referenc
> 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
Hi Guido,
sorry I missed your post...
>> One of the big issues that makes library authors reluctant to use
>> metaclasses
>> (even when they would be appropriate) is the risk of metaclass conflicts.
>
> Really? I've written and reviewed a lot of metaclasses and this has never
> worried me. The pr
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
be possible to do it
differently.
Hoping for good comments
Greetings
Martin
The PEP follows:
PEP: 487
Title: Simpler customisation of class creation
Version: $Revision$
Last-Modified: $Date$
Author: Martin Teichmann ,
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 27-Feb
Hi Nick, hi List,
thanks for the good comments! I'll update the PEP and the
implementation soon, as discussed at the end, I'll
do it in C this time. For now just some quick responses:
> This part isn't entirely clear to me, so you may want to give some
> Python pseudo-code that:
I will actually
k out of the box.
So now I am hoping for comments!
Greetings
Martin
New version of the PEP follows:
PEP: 487
Title: Simpler customisation of class creation
Version: $Revision$
Last-Modified: $Date$
Author: Martin Teichmann ,
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 27
Hi Eric, hi List,
> I'd be glad to give feedback on this, probably later today or
> tomorrow. In particular, I'd like to help resolve the intersection
> with PEP 520. :)
Thanks in advance! Let me already elaborate on the differences, so
that others can follow:
You chose the name "__definition_o
I am looking forward to a lot of comments on this!
Greetings
Martin
The proposed PEP for discussion:
PEP: 487
Title: Simpler customisation of class creation
Version: $Revision$
Last-Modified: $Date$
Author: Martin Teichmann ,
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2
Hi everyone,
I was really happy to see PEP 492 - that is really a big step forward.
It makes many programming constructs possible in combination with
asyncio, which have been cumbersome or impossible until now.
One thing that still is impossible is to have __setitem__ be used
asynchronously. As a
Hi Yury, Hi List,
I do certainly like the idea of PEP 492, just some small comments:
why do we need two keywords? To me it is not necessarily intuitive
when to use async and when to use await (why is it async for and not
await for?), so wouldn't it be much simpler, and more symmetric, to
just hav
> When I first wrote PEP 422 I was of the view that "Python 2 allows
> class definition postprocessing injection, we should allow it in
> Python 3 as well". I've since changed my view to "Having to declare
> post-processing of a class definition up front as a decorator, base
> class or metaclass is
Hi everyone,
> > If the PEP 487 metaclass library,
> > however, were to just port some bits of my code to Python 3 this could
> > be a done deal already and available in *all* versions of Python 3,
> > not just the next one.
>
> Just for the heck of it, here's an actual implementation and demo of
Hi everyone,
for those new to the discussion, I am the author of PEP 487,
which has been discussed here:
https://mail.python.org/pipermail/python-ideas/2015-February/032249.html
> The concern is twofold: it breaks proper information hiding/DRY, *and*
> it fails silently. It should not be necessa
>> I don't think the compiler can determine the order in
>> all cases. Consider:
>>
>> class Spam:
>>
>> if moon_is_full:
>> alpha = 1
>> beta = 2
>> else:
>> beta = 2
>> alpha = 1
>
> This is also expected to work in class namespaces:
>
> locals()["alpha"] = 1
> For folks that haven't looked at the tracker issue: I personally like
> the change, but it does involve storing the cell object in a
> dunder-variable in the class namespace while it's being defined (until
> type.__new__ executes and both populates it and removes it from the
> class namespace).
Hi list,
while a class is being initialized in a metaclass, it is not always possible to
call classmethods of the class, as they might use super(), which in turn uses
__class__, which is not initialized yet.
I know that this is a known issue, but well, sometimes it even makes sense
to fix already
34 matches
Mail list logo
