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 <some internal name, bound in another context,
the binding being derived from the resolution of the name "1">,
then PRINT_ITEM.
If you don't grasp this, try the same example:
>>> 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