[plt-scheme] An Editors Tale

From: Jeremy Hylton (jeremy at alum.mit.edu)
Date: Wed Feb 4 01:16:27 EST 2004

On Thu, 2004-01-29 at 13:36, Matthias Felleisen wrote:
> Ah, but the problem is that 3% "black holes" that you inject into a 
> program analysis quickly pollute the entire analysis. Do you know of an 
> analysis that copes with higher-order objects (closures) and "black 
> holes" (without additional information about them)? -- Matthias

Do you?  (I'm late getting back to this thread, but I wanted to add a
few things.)

Do you know of any analysis that deals with higher-order objects and
MOPs?  I think Python's metaprogramming facilities are evolving slowly,
and I, for one, don't have any experience with Common Lisp MOPs.

Ken's list of methods with __names__ covers operator overloading and
metaprogramming.  Methods like __getitem__ and __cmp__ are just there to
support overloading for indexing and comparison, respectively.  I assume
they don't pose an issue for analysis.

I think the only problematic methods are __getattr__ and company.  I
think they tend to be over-used in Python programs; most code that uses
a __getattr__ hook would probably be better off doing something less
dynamic.  (I probably disagree with ESR on this point.)  On the other
hand, it's incredibly valuable in a few rare cases.  The persistence
system I talked about at LL2 depends on being able to trap attribute
accesses to persistent objects.

A slightly different tack would be to ask what benefits Python
programmers would get if they avoided the dynamic features that cause
problems.  If there's some static analysis that only works on a subset
of Python code and that analysis is valuable, then there's incentive for
programmers to use only that subset of Python.

I also don't know how to take your comment that Python isn't OO, it's
just got dictionaries.  It sounds a little like saying C++ isn't OO,
it's just got vtables.  The runtime representation is dictionaries
(mostly), but they don't capture any of the rules for inheritance,
method resolution, etc.  Those rules are the core of the object system. 
(And they are open to extension using metaclasses.)


Posted on the users mailing list.