looking for MOP documentation

[kasper graversen]

hello there.

I've been searching the web (including the www.python.org but in vain of
finding recent documentation for the python MOP. I see some information on
python 1.5---is this the best and still valid information today?

sincerely
\kasper

 

[Uwe Hoffmann]

hello there.

I've been searching the web (including the www.python.org but in vain
of finding recent documentation for the python MOP. I see some
information on python 1.5---is this the best and still valid information
today?

sincerely
\kasper

http://www.python.org/2.2.3/descrintro.html#metaclasses
http://www-106.ibm.com/developerworks/library/l-pymeta2

 

[Anthony Baxter]

hello there.

I've been searching the web (including the www.python.org but in vain of
finding recent documentation for the python MOP. I see some information on
python 1.5---is this the best and still valid information today?

Erm, what's "MOP" mean? The current python is 2.3, and should probably be
used everywhere possible (1.5 is seriously seriously old)

Anthony

 

[Peter Hansen]

Erm, what's "MOP" mean? The current python is 2.3, and should probably be
used everywhere possible (1.5 is seriously seriously old)

Please don't push a .0 release more aggressively than it really deserves.

(Among, likely, other problems) 2.3 has a memory leak that could cause
long-running network programs to have difficulties. It has been fixed
in CVS, so 2.3.1 will doubtless be better in this area, but some people
should definitely *not* be upgrading to 2.3 just yet.

Not to say 2.3 isn't better by far in many areas, but I'd be cautious
pushing it for "mission critical" stuff just yet.

(I don't have a reference handy, but we found the leak independently
by tracing it to a connect_ex() on a non-blocking socket, then found
a link in Google.)

-Peter

 

[Peter Hansen]

(Among, likely, other problems) 2.3 has a memory leak that could cause
long-running network programs to have difficulties.

(I don't have a reference handy, ...

Here's where we found the reference... first response to

http://www.google.ca/search?q=connect_ex+memory+leak

For the record, here was the near-minimal code which led
us to do the above search:

import socket
def conn():
s = socket.socket(socket.AF_INET, socket.SOCKSTREAM)
try:
s.setblocking(0)
for i in xrange(100):
s.connect_ex(('127.0.0.1', 21569))
finally:
s.close()
del s

if __name__ == '__main__':
print 'starting'
try:
while 1:
conn()
finally:
print 'done'


-Peter

 

[kasper graversen]

(Among, likely, other problems) 2.3 has a memory leak that could cause
long-running network programs to have difficulties. It has been fixed
in CVS, so 2.3.1 will doubtless be better in this area, but some people
should definitely *not* be upgrading to 2.3 just yet.

what has all this talk to do with documentation of the MOP???

 

[Ng Pheng Siong]

Er, if you'll look back, you'll see that Anthony asked what MOP
meant

Meta Object Protocol.

 

[Peter Hansen]

Meta Object Protocol.

Thanks, but one might say that this is what it spells, not what it _means_.

At this point, I'm sure google would help, if I felt a driving
need to go and learn what it really means.

-Peter

 

[Jacek Generowicz]

Erm, what's "MOP" mean?

Meta Object Protocol.

 

[Peter Hansen]

Thanks, but one might say that this is what it spells, not what it _means_.

At this point, I'm sure google would help, if I felt a driving
need to go and learn what it really means.

Annoyed that nobody seemed to be willing to actually define this (which
leads me to suspect that none of those involved in the thread actually
*know* what it means, other than to expand the acronym), I did a little
searching and found http://cliki.tunes.org/Meta-Object Protocol , which
at least attempts to define it. It still doesn't describe it well enough
for someone to really understand the purpose, the value, the reason for
bothering to do such a thing, but it's better than the definitions offered
so far in this thread...

-Peter

 

[Paul Foley]

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/

--
Let me control a planet's oxygen supply and I don't care who makes the
laws.

(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))

 

[Peter Hansen]

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

-Peter

 

[Michael Hudson]

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

 

[Alan Kennedy]

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.

Hmm, does this rephrasing hold any truth?

"Metaclasses are interfaces to the python language
that give users the ability to incrementally modify the language's
behavior and implementation...".

Isn't modifying standard behaviour the whole purpose of metaclasses?

regards,

 

[Peter Hansen]

Hmm, does this rephrasing hold any truth?

"Metaclasses are interfaces to the python language
that give users the ability to incrementally modify the language's
behavior and implementation...".

Isn't modifying standard behaviour the whole purpose of metaclasses?

But it doesn't really modify the *language's* behaviour in the way
implied by a simplistic reading of the above phrase. That is, the
"obvious" interpretation is that syntax and grammar are being affected,
not just the behaviour of one small slice of the language, specifically
how classes behave. In some languages the two things are not so
separate, but in Python they seem to be.

-Peter

 

[Michael Hudson]

But it doesn't really modify the *language's* behaviour in the way
implied by a simplistic reading of the above phrase. That is, the
"obvious" interpretation is that syntax and grammar are being affected,
not just the behaviour of one small slice of the language, specifically
how classes behave. In some languages the two things are not so
separate, but in Python they seem to be.

Huh? Common Lisp's MOP doesn't change the language on that level,
either. Presented with a form

(foo bar)

nothing the MOP can do can change the usual processing (check to see
if foo is a macro, if so expand, otherwise check if it's a function,
if so evaluate bar and call the function, otherwise signal error).

Of course, there's a sense in which Common Lisp just doesn't have much
syntax, but Python's hardly overloaded with it, either. *The objects*
or to be more precise the *types* of objects themselves are what
determine really happens, and that's precisely the sort of thing
metaclasses let you play with.

Cheers,
mwh

 

[Peter Hansen]

Huh? Common Lisp's MOP doesn't change the language on that level,
either.

No problem... I was deliberately taking a simplistic reading of the above,
in an attempt to elicit discussion that would clarify whether it was an
adequate description. Sounds like it's not.

Of course, there's a sense in which Common Lisp just doesn't have much
syntax, but Python's hardly overloaded with it, either. *The objects*
or to be more precise the *types* of objects themselves are what
determine really happens, and that's precisely the sort of thing
metaclasses let you play with.

I guess this might get down to the question of whether Python is more about
the syntax, grammar, keywords, and such, of the language or more about the
standard types of objects which are provided with it. In my mind, it's
very much the former and very little the latter, but maybe that's just me.
Dicts and lists and integers are interesting and all, but I'm not sure
it's their behaviour which makes Python Python.

-Peter

 

[Holger Krekel]

Hello Peter,

I guess this might get down to the question of whether Python is more about
the syntax, grammar, keywords, and such, of the language or more about the
standard types of objects which are provided with it. In my mind, it's
very much the former and very little the latter, but maybe that's just me.
Dicts and lists and integers are interesting and all, but I'm not sure
it's their behaviour which makes Python Python.

Although probably 2/3 of the implementation of Python deal with the type/object
implementations, from a using-the-language point of view the syntax probably
contributes more obviously to the observed "simplicity" of Python.

But the term "meta object protocol" seems to point much more into
the direction of types/objects as Michael suggests and here Python
has a lot to offer. Is there some free material on MOP somewhere?

FWIW, in the next pypy-sprint we'll probably try to deconstruct the python-syntax
and its resulting compilation and execution into several aspects. Maybe
we should term this effort meta language protocol

cheers,

holger

 

[Michael Hudson]

I guess this might get down to the question of whether Python is
more about the syntax, grammar, keywords, and such, of the language
or more about the standard types of objects which are provided with
it. In my mind, it's very much the former and very little the
latter, but maybe that's just me. Dicts and lists and integers are
interesting and all, but I'm not sure it's their behaviour which
makes Python Python.

Fair enough. I can see your point of view, I just don't (completely)
agree with it You could have something with similar syntax,
keywords, etc to Python but semantics like C, and it would still be
horrible (IMHO).

Cheers,
mwh

 

[Michael Hudson]

Although probably 2/3 of the implementation of Python deal with the
type/object implementations, from a using-the-language point of view
the syntax probably contributes more obviously to the observed
"simplicity" of Python.

OK, I disagree with you, too

But the term "meta object protocol" seems to point much more into
the direction of types/objects as Michael suggests and here Python
has a lot to offer. Is there some free material on MOP somewhere?

http://www.elwoodcorp.com/alu/mop/contents.html

looks like being a version of AMOP online, you know that book I
brought with me to one of the pypy sprints (actually, it may have
been the Gothenbourg sprint). I can bring it to the next sprint I
come to, if you like.

Cheers,
mwh