[Python-3000] PEP 3115: Actual use cases for odd metaclasses? Alternate syntax.

[Charles Merriam]

>
> Yes, several.  You haven't been reading the previous discussion
> threads, in which I've repeatedly posted other use cases for PEP
> 3115, every time someone else who hasn't read the previous posting of
> those use cases, and tries to "simplify" the PEP.  Other people have
> posted a few as well.

Great!  Point to them or explain them.  I read back two months before
posting, but you
must referencing discussions six months old?  fourteen months old?

>
> You're also utterly ignoring metaclass runtime use cases in your
> proposal, in a way that suggests you don't really know what a
> metaclass *is*, even pre-PEP 3115.

?


>
>
> >Unfortunately, this can't unroll gracefully, as it needs some execution
> >after partially compiling the class, but before it has been
> >fully finished.  The compilation pseudo-code:
> >
> >     If there is an @@metaclass:
> >         remember the metaclass function ("superswizzle")
> >         attributes will go in a list, not a dict during class compilation
> >         compile up the class
> >         create a new Metaclass object with cls, bases, attrs_list
> >         call @@metaclass function
> >         take the (changed) Metaclass object, and call 'type' to make it.
> >         make sure the class remembers which metaclass function to make
> >on creation.
> >      else:
> >         do the usual.
>
> This description makes me think you don't understand how class
> creation works, either.  In particular, you keep using the phrase
> "compiling the class", but I don't think you know what that phrase means.
>

Fill me in.  I view it as classes executing in their own namespace, then calling
type._init__ to transform the defined function signatures to take 'self'
arguments and add the class name to its enclosing namespace.  If you have
a point, make it.  Don't just name call.

>
> >The psudo-code for calling the superclass's @@metaclass is left as
> >an exercise.
>
> What about multiple inheritance?  That doesn't seem like such a
> trivial exercise, and AFAICT, your proposal is more complex to
> implement than that of Python 2.x metaclasses.
>
Actually, it should be considerably simpler as the problem can devolve
into an order list of function calls.  Specifically, I didn't want to write
a bunch more in a first post until the first 'use cases' question was
handled.

>
> >So this has the advantages:
> >+ Metaclass becomes far less boilerplate, error-prone, black magic.
> >+ Metaclass stops being a subclassing hack, which simplifies things.
>
> And eliminates the ability to have a *meta* *class* in the
> process.  No thanks.  (Plus, you have moved the complexity from a
> well-understood and well-grounded-in-theory model to a handwaving
> "left as an exercise" non-proposal.)

What?  English please.

>
>
> >+ __metaclass__ goes away.  It was a crufty syntax.
>
> And yet it was still better than your @@ proposal, and the keyword
> syntax of PEP 3115 is better still.
>
>
> >+ lots of future hacking on novel ways to use metaclasses
> >     now that they are easier.
>
> Er, huh?  How in blue blazes is what you just described *easier* in
> any way, shape or form?  I can't tell through all the hand-waving in
> the semantics, since you didn't provide any real explanation of what
> your "metaclass info" object does, nor did you provide a definition
> of 'super_swizzle'.
>

OK, I didn't explain any 'super_swizzle' outside of the use case cited.
Assume I need to take an ordered list of class attributes that are not
functions for use in either on old IDL interface, OR mapper, or whatever.
I want these items in the declared order, and want to mention them once.
There wasn't handwaving, just using sample code of spec. language.

>From the comments, you should see that the metaclass info is an object
created and passed which provides the same basic baseclass and attrs
list that go to type.__init__().



> Meanwhile, all of the functionality you implied would exist on the
> "mc" object, could easily be implemented as utility functions taking
> a class object in today's Python, and trivially invoked from a
> metaclass __init__, cleanly supporting multiple inheritance in the
> process (by standard super() calls).

Actually, I was looking at using a single type subclass to provide this,
and would do so if there we no way to change in syntax.   A hack in 2.6,
or simply decorating __init__ per Mertz.  If syntax is allowed
to change, I would prefer beautiful rather than ugly.
>
> Heck, if you don't like defining new metaclasses, the DecoratorTools
> package includes a class that allows its subclasses to define a
> '__class_init__' method that is called in lieu of a metaclass
> __init__, allowing every class to almost be its own metaclass (in the
> limited sense of getting to define certain nominally-metaclassy
> methods like new, init, and call).

Haven't delved into this.  DecoratorTools looks like to a tool you or your
group wrote to hack around lack of decorators.

>
> I use this class in a lot of libraries because it eliminates the need
> to define custom metaclasses in all but the most demanding metaclass
> use cases, and thus avoids most of the problems involved in mixing
> metaclasses via multiple inheritance.  It lets you define a base
> class that does your "super_swizzle" magic, and then simply inherit
> from it to use it.
>
Annoyingly, the swizzle is a choice that needs an array instead of a dict.
Also, the division is not class or mix-in based; I want to alter behavior of the
class at a particualr point creation.

> In any case, my point is that AFAICT here, there isn't anything
> you've proposed here that can't already be done within the status
> quo, without implementing a new way of "compiling the class" (which
> doesn't mean what you seem to think it means).
>
>
> >+ Moving the metaclass specialness to a single function simplifies
> >     diamond inheritence from classes with multiple metaclasses.
>
> Uh, no, it doesn't.
>
>
> >I would love to see use cases for which this solution
> >does not work.
>
> How about all of the use cases that actually need a *metaclass*,
> rather than merely inherited class decoration?
>
>
>

So, provide the use cases you mention, read more carefully.

I can see why contributing to Python is more chore than joy.

Charles