self

David Bolen db3l at fitlinxx.com
Wed Jun 5 22:25:38 CEST 2002


holger krekel <pyth at devel.trillke.net> writes:

> the problem is that the values in the dict have to be 'evaluated' if
> accessed.  For every name in such a value you need to evaluate its
> value again.  IOW it's recursive. The obvious solution is to
> intercept the namevalue-lookups during evaluation of an
> equation. But this doesn't work for exec/eval: They ignore the
> interception points.

Right, so even if you use Python 2.2 and subclass dict, while you'll
get the first lookup properly the recursive lookups within the eval go
directly to the dictionary.

I think your earlier solution posted here, which was to start with an
empty dictionary for the eval, and then trap lookup errors and slowly
populate the dictionary by evaluating the needed symbol, looked the
most promising.  It ends up doing a bunch of eval() calls, but using
the exception processing in lieu of needing the __getattr__ override
on the dictionary.  I think it might still need some checking to
avoid infinite loops in cyclical references though.

> IOW you cannot successfully wrap or inherit a dictionary type and pass it 
> to exec/eval :-(

Yes, I did also find a posting by Guido (didn't save the reference,
but it was via a google search) where he seemed to indicate that
subclassing list/dict other than add additional functionality (rather
than override core operations like lookups) could be problematic -
presumably because of cases like this where the special Python-exposed
functions are used.  The message was during one of the later betas of
2.2, so I don't know if the viewpoint changed before final release.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/



More information about the Python-list mailing list