namespace/dictionary quandry

[Jack Carter]

On Sep 22,  7:18pm, Alex Martelli wrote:
> Subject: Re: namespace/dictionary quandry
> Jack Carter <jcarter at johmar.engr.sgi.com> wrote:
>    ...
> > The solution it would seem would be to do the evaluation
> > 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.
> >
> > If this makes sense, the problem I need to solve is how to
> > deliver the correct namespace dictionary to the called function
> > so I can invoke eval with it.
> >
> > Does this make sense?
>
> Not very, but then I didn't follow the previous LONG posts on this

Alex,

The length was really taken up with a testcase to make
the problem less hand wavey.

> thread, so I'll just answer this specific question and hope it helps.
> 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?

>
> voila: if n is a key in dict d, this returns the corresponding value,
> otherwise it returns n suitably quoted.  Just pass to eval a
> WeirdNamespace(d) rather than the bare d.
>
> It appears to me your user interface is courting trouble: if I mispell
> 'variablename' as 'varaiblename' I end up creating a file I didn't mean
> to rather than getting a clean error about unknown variable names.  But
> 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.

Thanks,

Jack