namespace/dictionary quandry

[Alex Martelli]

Jack Carter <jcarter at johmar.engr.sgi.com> wrote:
   ...
> > > later within the called function. That way I could assume
> > > that all failed eval()'ed names are literals meant for my
> > > command and not a python variable/name.
   ...
> The length was really taken up with a testcase to make
> the problem less hand wavey.

If you can't make a shorter example, I'm not gonna make time to study
that one, sorry.


> > I'll assume the known variable-names are in some dictionary (such as a
> > locals() or globals() or vars(something)):
> >
> > class WeirdNamespace:
> >     def __init__(self, d): self.d = d
> >     def __getitem__(self, n): return self.d.get(n,repr(n))
> 
> So, how and or where does this fit in with my example?
> Does both the call to the function where I want to do
> the eval() and self.push(line) command have to be in the
> same namespace and or file for this to work?

All it does is implement what you asked: make a mapping that assumes all
unknown variable names are to be taken as literals, starting from a
mapping of all 'known variable names' to their values.


> > I'll assume you know your users better than I do and that they _do_
> > really desire with all their hearts this unholy confusion between
> > variables and constants...
> 
> This is driven by customers that who want both a type-in command
> language and a variant using all the power of python for test
> scripting purposes. If you misspell something and there is the
> possibility of it screwing something up that we can't tell either
> in the parser or downstream in the backend of the tool, well that's
> life in the big city.

I suspect the first time your users want to use a file named 'for'
they'll scream bloody murder, but hopefully that won't happen before
they've paid you enough for you to retire in comfort to a nice
Carribbean island without extradition treaties, so, cheer up.


Alex