Metaclass with name overloading.

[Alex Martelli]

Carlos Ribeiro <carribeiro at gmail.com> wrote:
   ...
> On Mon, 27 Sep 2004 15:27:31 +0200, Alex Martelli <aleaxit at yahoo.com> wrote:
> > > 1) One such idea is to provide the metaclass with a __dict__ factory.
> > 
> > If you go that route, then it may indeed require changes too deep for
> > 2.5 or 2.anything.  The metaclass gets determined later, at the time
> > CALL_FUNCTION executes the metaclass ain't in play yet.
   ...
> time frame. But for now, I have only one question. You said that the
> metaclass is determined later. I'm not familiar with Python's
> internals, but I (naively?) assumed that the metaclass is known very
> early in the class declaration process. Is that wrong?

I'm confused as to why you would assume that and what you mean by
'declaration'.  I'll take it that you mean the _execution_ of the class
_statement_, in which case I really can't see how you could assume any
such thing.  You _do_ know that __metaclass__ can be set anywhere in the
class body, for example, right?  So how could Python know the metaclass
before it's done executing the class body?  Yet it's exactly in order to
execute the class body in the modified way you desire, that Python would
need to set a certain frame's f_locals differently from the usual dict.

In other words, it's not an issue of implementation details that could
be tweaked while leaving current semantics intact: if you insist that it
must be the _metaclass_ which determines what kind of mapping object is
used for the f_locals of the frame where the class's body executes, then
it cannot be possible any more to determine the metaclass with today's
semantics (which I think are pretty fine, btw).

Come to think of it, this might be a great role for class-decorators.
If I had a way to tweak the kind of f_locals for a _function_, the
general semantics of today's function decorators would be fine (the
tweak might be attached after the function object is built, since it's
only needed when that function gets _called_).  But for a class, by the
time the class body starts executing, it's too late, because it must be
executing with some kind of f_locals in its frame.  So, class decorators
would have to be given a chance _before_ the class body runs.

> obs 1: If it's possible to determine the metaclass *early*, then it's
> no problem to call any extra function to provide the f_locals dict, or
> to provide an augmented dict.

But Python can never be sure what the metaclass will be until the class
body is done executing, far too late.  Basically, you'd need to forbid
the current possibility of setting __metaclass_ in the class body, plus,
you'd have to get deep into analyzing the bases before executing the
class body -- and if you look at what types.ClassType does to delegate
the metaclass choice to other bases if it possibly can, you'll probably
agree that this nicety has to be abrogated too.

All in order to have the f_locals' kind be set by the *metaclass* rather
than by other means -- honestly, it seems the price is too high, unless
there are some big advantages connected by the choice of metaclass vs
other means that I fail to see.  What's so terrible about my q&d idea of
having a sys._something function do the job, for example?  Then once we
have the ability to do the setting we can think of nice syntax to dress
it up.  But the mods to ceval.c needed to accept any kind of setting for
f_locals' type seem a pretty big job already, without needing to put up
the hurdle that the metaclass must be determined early, too...


Alex