Re: [Python-Dev] Naming and Binding of Objects (was: Relative Package Imports) (fwd)
---------- Forwarded message ---------- On Sat, 18 Sep 1999, Vladimir Marangozov wrote:
Saltzer J., "Naming and Binding of Objects", in Bayer R., "Operating Systems - An Advanced Course", pp. 99-208, LNCS 60, 1978.
It's not available online (it was written on a typewriter), so I'd be happy to send a hard copy of it to anyone who raises a hand in private mail (or cannot find LNCS 60).
I then asked him for a copy stating:
If you send it to me, I can OCR it and make it available online.
and he generously sent it to me. The problem is that I hadn't noticed the length of the manuscript. It's over a hundred pages, and the copy is nth generation, making OCR pretty much useless. So, if anyone wants a copy, I can make and send copies (which would make most sense for folks in the US -- sending things from France isn't cheap). So far, it's good reading. Funny to see "file name" in quotes in the text. --david
David Ascher wrote:
---------- Forwarded message ---------- On Sat, 18 Sep 1999, Vladimir Marangozov wrote:
Saltzer J., "Naming and Binding of Objects", in Bayer R., "Operating Systems - An Advanced Course", pp. 99-208, LNCS 60, 1978.
It's not available online (it was written on a typewriter), so I'd be happy to send a hard copy of it to anyone who raises a hand in private mail (or cannot find LNCS 60).
I then asked him for a copy stating:
If you send it to me, I can OCR it and make it available online.
and he generously sent it to me. The problem is that I hadn't noticed the length of the manuscript. It's over a hundred pages, and the copy is nth generation, making OCR pretty much useless.
If I find some spare time, I'll do it. This paper is a classic in Comp Sci that we kindly invite our students to read. In research language, we say that Saltzer has made "the turn around the clock" regarding this issue, putting a period on it (i.e. there's hardly something more to say). It's interesting, however, to see how the theory was applied on Python and to establish the fairly easy analogy of the binding model. This analogy proves the good design choices Guido has made, but also reveals some weaknesses or the incompleteness of the current implementation. I hope to discuss this for Python 2 in due time and perhaps settle on a compromise which trades genericity for performance. The naming/binding problem drives the whole implementation logic in Python (objects, classes, scopes, etc.).
So, if anyone wants a copy, I can make and send copies (which would make most sense for folks in the US -- sending things from France isn't cheap).
I have 2 more copies lying around, ready to be sent. Give me an adress. The first 2 adresses win a hard copy, no matter the location (don't worry about mail costs.) -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
I've started reading the paper and agree that it's very good!
It's interesting, however, to see how the theory was applied on Python and to establish the fairly easy analogy of the binding model. This analogy proves the good design choices Guido has made, but also reveals some weaknesses or the incompleteness of the current implementation. I hope to discuss this for Python 2 in due time and perhaps settle on a compromise which trades genericity for performance. The naming/binding problem drives the whole implementation logic in Python (objects, classes, scopes, etc.).
I'd like to hear what those weaknesses are in your eyes. I can think of two areas myself: (1) sys.path, $PYTHONPATH etc.; (2) class/instance attributes in the context of subclassing and evolution of the base class. (I don't expect the paper to take a stance on nested scopes.) --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
I've started reading the paper and agree that it's very good!
It's interesting, however, to see how the theory was applied on Python and to establish the fairly easy analogy of the binding model. This analogy proves the good design choices Guido has made, but also reveals some weaknesses or the incompleteness of the current implementation. I hope to discuss this for Python 2 in due time and perhaps settle on a compromise which trades genericity for performance. The naming/binding problem drives the whole implementation logic in Python (objects, classes, scopes, etc.).
I'd like to hear what those weaknesses are in your eyes. I can think of two areas myself: (1) sys.path, $PYTHONPATH etc.; (2) class/instance attributes in the context of subclassing and evolution of the base class.
(2) subsumes (1).
(I don't expect the paper to take a stance on nested scopes.)
But we can. I can't make the time for this right now and I apologize. This subject deserves more attention and I can't describe it quickly, so it has to wait. As I said, in due time ;-). I'm currently overloaded. (In my defense, and Barry will undesrand me very well, I'll say that among othger things I'm reworking the www.inrialpes.fr Web site, which is actually a shame -- now that I'm in charge, come and visit it in a month). Anyway, some quick general notes on what actually exists: Where Python (Guido) really strikes is that almost everything we have at the language level is interpreted as a name. Thus, "sharing can occur". These names are always resolved in some context associated with the object containing the named object. Since all we have is names, the risk of name conflicts is real, especially when half of the contexts against which name resolution occurs are implicit. Therefore, name resolution has to be done in a controlled way (what Guido has successfully tried to provide when designing the language). Simple example:
print o.attr
This says: print the value of an object, whose name "attr" has to be resolved in the context associated with the object "o", this context being explicitely pointed out by a dot "." Another (not so obvious) one:
print 1
This says: print the value of an object, whose name "1" has to be resolved
in the current (implicit) context. And this is exactly what happens inside
the VM in terms of LOAD_CONST
a = 1 print a
This says: Resolve the name "1" in the current context (thus we reach the object in question) then assign a new binding ("a" -> the object) in the current context. Then for "print a", see "This says" of the previous example. A valuable thing happens in my last example:
print o.__dict__
This resolves the name "__dict__" in the context associated with the object named "o" (pointed by a dot "."), returning this same context! (or a fraction of it). Whether we have to get a portion of the context or the full context is debatable. It has been felt that with the dynamicity of Python, it's useful to get access to the context, then play with it in a controlled manner. So from here, I (and you) can deduce what happens in terms of naming and binding on function/class/... definitions, on module imports, on attr lookups, on "global" declarations, and so on, and when and where (and hopefully why) we get name conflicts or strange (implicit) name resolutions for nested functions. A last word towards classes: There's no difference between
o = C() # an instance of the class C o.__class__
and
o = 1 o.__class__
I'm prevented to type "1.__class__" only for syntactic reasons, but the context for the resolution of o.__class__ exists. What's missing is for a future mail. Later, -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
participants (3)
-
David Ascher -
Guido van Rossum -
Vladimir Marangozov