was: Re: looking for MOP documentation

[Michael Hudson]

Peter Hansen <peter at engcorp.com> writes:

> Paul Foley wrote:
> > 
> > On Tue, 16 Sep 2003 07:33:42 -0400, Peter Hansen wrote:
> > 
> > > Ng Pheng Siong wrote:
> > >>
> > >> According to Peter Hansen  <peter at engcorp.com>:
> > >> > kasper graversen wrote:
> > >> > > On Fri, 12 Sep 2003 14:36:44 -0400, Peter Hansen <peter at engcorp.com> wrote:
> > >> > > >> Erm, what's "MOP" mean?
> > >> > > what has all this talk to do with documentation of the MOP???
> > >> > Er, if you'll look back, you'll see that Anthony asked what MOP
> > >> > meant
> > >>
> > >> Meta Object Protocol.
> > 
> > > Thanks, but one might say that this is what it spells, not what it _means_.
> > 
> > Read the introduction to _The Art of the Metaobject Protocol_, at
> > http://www2.parc.com/csl/groups/sda/publications/papers/Kiczales-AMOP/
> 
> Thanks Paul.
> 
> If that description is taken as authoritative about "the MOP", then it 
> seems to me after a first reading that Python *has no MOP*, and probably
> will not, given Guido's approach to language design.  
> 
> Am I correct?

I'm not sure.  In Python, you can come fairly close to being able to do 

class MyType(object):
    ...

and have instances of instances of MyType look pretty much like
instances of instances of type (which is to say, regular Python
objects), which I think of as being one of the properties of having a
full blown MOP.  But I don't think you can get all the way there
(e.g. getting isinstance to work properly with ones custom objects &
types seems unlikely).

>From one viewpoint, this is partially because various bits of the
Python core just reach in for, e.g., the tp_bases field of a type
object.  To have a "true MOP", it feels as if these bits would need to
be changed to respects any descriptors that may have been set on,
e.g. again, __bases__.  This would probably have performance (and
circularity) implications for the interpreter.

(I spent a while last year trying to find a way of creating a
metaclass that would allow mutation of __bases__, which is where these
thoughts come from).

> Or does the term really have a broader meaning than what
> I get out of that page, and Python in fact has aspects that could be called
> its meta-object protocol?
> 
> Key phrase: "Metaobject protocols are interfaces to the language
> that give users the ability to incrementally modify the language's
> behavior and implementation...".  Near as I can tell, part of the
> whole character of Python is that a user *cannot* do either of those
> things.

I would say Python's metaclass facility is at least part of a MOP.
Python certainly does not have as thorough a MOP as that describe in
the Art of the Metaobject Protocol, to be sure.  I'm not sure how much
interest (or value...) there would be in extending what we have now.
Could make an interesting dissertation project :-)

Cheers,
mwh

-- 
  Finding a needle in a haystack is a lot easier if you burn down
  the haystack and scan the ashes with a metal detector.
      -- the Silicon Valley Tarot (another one nicked from David Rush)