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

[Phillip J. Eby]

At 08:04 PM 12/22/2007 -0800, Charles Merriam wrote:
> >
> > 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?

There's a mailing list archive you can search for discussion of PEP 
3115.  Beyond that, the PEP itself includes some of those use cases - 
see paragraph six of the "Rationale", for example.

It would be best if you checked the PEP rationale before asking for 
alternate use cases, or at least indicate why you think the use cases 
listed in the PEP itself are invalid, or ask a question specifically 
about them.  However your rough definition of your perception of the 
use cases indicates you've largely missed the point of what a 
metaclass is, does, and is for, so I've attempted a further 
explanation later in this email.


> > 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.

Er, my point was that your proposal is vague and uses confusing 
terminology.  "Compiling" is the translation of the class statement 
to bytecode -- not the execution of the class suite.  If you mean 
execution of the class suite, say so.


> > >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.

It was handled by the PEP before you posted.  Meanwhile, your 
statement that it's simpler isn't currently backed up by any 
specification of your algorithm.


> > >+ 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.

You gave an example using "@@super_swizzle", but which never defined 
what 'super_swizzle' consists of.  How are we to guess what its 
meaning is?  (Off hand, I would guess that the function you called 
'process' was actually supposed to be named 'super_swizzle', but 
that's far from a slam dunk, given the general vagueness of the proposal.)


>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.

You handwaved inheritance -- you handwaved how this metaclass info is 
created, you handwaved "compiling"...  there is very little that 
isn't handwaving in your proposal.  It may seem otherwise to you, if 
you do in fact have some mental model that includes all the details 
your written proposal left out, but if that is the case you have a 
*lot* more writing to do to make it not appear as handwaving to 
anyone who might try to actually *implement* the proposal.


> 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__().

Yes, I got that part, and I can infer several other things from your 
sketch.  My complaints are with the things you didn't list, or which 
you did list but which have significant drawbacks (e.g. @@syntax, 
lack of actual metaclass capabilities).


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

Actually, it's just a collection of tools having to do with 
decoration, as the name implies, although originally it was just 
class decorators and function decorator support for Python 2.3.


>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.

And PEP 3115 doesn't let you do this?


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

My point is that your proposal appears to be ignoring what 
metaclasses are for in the first place: to define the runtime 
behavior of the *class objects* (as opposed to the instances).  It 
didn't mention anything about how one would have an actual metaclass, 
as opposed to inheritable decoration and customized class 
creation.  How would you customize the actual *type* of the classes?

Your message to Christian Tanzer indicates that you are still not 
getting this concept -- it's the behavior of the *class*, not the 
behavior of the class' instances.  For example, a metaclass can 
create a property that the class accesses, e.g.:

    class mymeta(type):
       p = property(lambda self: 42)

    class cls: __metaclass__=mymeta

    assert cls.p==42                 # class has it
    assert not hasattr(cls(), 'p')   # instances don't

Another example might be a metaclass that keeps a dictionary of all 
instances of a particular class, and defines __getitem__ so that you 
can do SomeClass[someKey] to look up a the specified instance of that class.

These are the sorts of use cases that your proposal appears 
completely oblivious to (entirely independent of PEP 3115, which 
merely refines the existing metaclass model a bit).


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

Yes, it is indeed a chore to repeat the same things over and over 
when people don't:

* read the relevant PEP,
* do a Google search of the archives for relevant discussions,
* understand even the most basic ideas about the constructs they're 
proposing to modify, or
* use words that reflect what they mean (e.g. not saying "compiling" 
when they mean "executing").

Until eventually, somebody snaps and gets all "argument clinic" when 
the same thing gets asked enough times, even though the answers are 
already in the PEP.  :)

That having been said... happy holidays, and sorry for the rough 
welcome.  I totally understand now why Guido gets gruff sometimes 
when somebody brings up the same darn FAQ or previously-rejected 
proposal for the Nth time.