>
> 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
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
