On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby <p...@telecommunity.com> wrote: > On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> >> It's actually the pre-decoration class, since the cell is initialised >> before the class is passed to the first decorator. I agree it's a little >> weird, but I did try to describe it accurately in the new docs. > > I see that now; it might be helpful to explicitly call that out. > > This is adding to my list of Python 3 metaclass gripes, though. In Python > 2, I have in-the-body-of-a-class decorators implemented using metaclasses, > that will no longer work because of PEP 3115...
I'm not quite following this one - do you mean they won't support __prepare__, won't play nicely with other metaclasses that implement __prepare__, or something else? > and if I switch to using > class decorators instead, then they won't work because of PEP 3135. :-( Yeah, 3135 has had some "interesting" consequences :P (e.g. class body level __class__ definitions are still broken at the moment if you also reference super: http://bugs.python.org/issue12370) > Meanwhile, mixing metaclasses is more difficult than ever, due to > __prepare__, and none of these flaws can be worked around officially, > because __build_class__ is an "implementation detail". I *really* want to > like Python 3, but am still hoping against hope for the restoration of hooks > that __metaclass__ allowed, or some alternative mechanism that would serve > the same use cases. > > Specifically, my main use case is method-level decorators and attribute > descriptors that need to interact with a user-defined class, *without* > requiring that user-defined class to either 1) redundantly decorate the > class or 2) inherit from some specific base or inject a specific metaclass. > I only use __metaclass__ in 2.x for this because it's the only way for code > executed in a class body to gain access to the class at creation time. > > The reason for wanting this to be transparent is that 1) if you forget the > redundant class-decorator, mixin, or metaclass, stuff will silently not > work, Why would it silently not work? What's preventing you from having decorators that create wrapped functions that fail noisily when called, then providing a class decorator that unwraps those functions, fixes them up with the class references they need and stores the unwrapped and updated versions back on the class. You call it redundant, I call it explicit. > and 2) mixing bases or metaclasses has much higher coupling to the > library providing the decorators or descriptors, and greatly increases the > likelihood of mixing metaclasses. So don't do that, then. Be explicit. > And at the moment, the only workaround I can come up with that *doesn't* > involve replacing __build_class__ is abusing the system trace hook; ISTM > that replacing __build_class__ is the better of those two options. Stop trying to be implicit. Implicit magic sucks, don't add more (PEP 3135 is bad enough). > At this point, with the additions of types.new_class(), ISTM that every > Python implementation will have to *have* a __build_class__ function or its > equivalent; all that remains is the question of whether they allow > *replacing* it. types.new_class() is actually a pure Python reimplementation of the PEP 3115 algorithm. Why would it imply the need for a __build_class__ function? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
