<div class="gmail_quote">On Mon, Jun 4, 2012 at 10:25 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Tue, Jun 5, 2012 at 10:10 AM, PJ Eby <<a href="mailto:pje@telecommunity.com" target="_blank">pje@telecommunity.com</a>> wrote:<br>
> On Mon, Jun 4, 2012 at 7:18 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
>><br>
>> On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby <<a href="mailto:pje@telecommunity.com" target="_blank">pje@telecommunity.com</a>> wrote:<br>
>> > On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
>> >><br>
>> >> It's actually the pre-decoration class, since the cell is initialised<br>
>> >> before the class is passed to the first decorator. I agree it's a<br>
>> >> little<br>
>> >> weird, but I did try to describe it accurately in the new docs.<br>
>> ><br>
>> > I see that now; it might be helpful to explicitly call that out.<br>
>> ><br>
>> > This is adding to my list of Python 3 metaclass gripes, though. In<br>
>> > Python<br>
>> > 2, I have in-the-body-of-a-class decorators implemented using<br>
>> > metaclasses,<br>
>> > that will no longer work because of PEP 3115...<br>
>><br>
>> I'm not quite following this one - do you mean they won't support<br>
>> __prepare__, won't play nicely with other metaclasses that implement<br>
>> __prepare__, or something else?<br>
><br>
><br>
> I mean that class-level __metaclass__ is no longer supported as of PEP 3115,<br>
> so I can't use that as a way to non-invasively obtain the enclosing class at<br>
> class creation time.<br>
><br>
> (Unfortunately, I didn't realize until relatively recently that it wasn't<br>
> supported any more; the PEP itself doesn't say the functionality will be<br>
> removed. Otherwise, I'd have lobbied sooner for a better migration path.)<br>
<br>
</div>As in the "def __metaclass__(name, bases, ns): return type(name,<br>
bases, ns)" functionality?<br></blockquote><div><br>The part where you can do that *dynamically in the class body* from a decorator or other code, yes. <br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You can still pass an ordinary callable as the metaclass parameter and<br>
it will behave the same as the old class level __metaclass__<br>
definition.<br></blockquote><div><br>Which runs afoul of the requirement that users of the in-body decorator or descriptor not have to 1) make the extra declaration and 2) deal with the problem of needing multiple metaclasses. (Every framework that wants to do this sort of thing will end up having to have its own metaclass, and you won't be able to use them together without first creating a mixed metaclass.)<br>
<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I personally wouldn't be averse to bringing back the old spelling for<br>
the case where __prepare__ isn't needed - you're right that it's a<br>
convenient way to do a custom callable that gets inherited by<br>
subclasses.<br></blockquote><div><br>That was a nice hack, but not one I'd lose any sleep over; the translation to PEP 3115 syntax is straightforward even if less elegant. It's the *dynamic* character that's missing in 3.x. In any case, I don't use the __metaclass__ hook to actually *change* the metaclass at all; it's simply the easiest way to get at the class as soon as its built in 2.x.<br>
<br>If there were a way to register a function to be called as soon as an enclosing class is created, I would use that instead.<br><br>
</div></div>