Re: Lambda binding solved? ( __builtin__, options, etc... )

Steven D. Majewski (sdm7g@elvis.med.virginia.edu)
Tue, 1 Mar 1994 13:21:53 -0500

... However, after writing the previous message, I skipped to the top
and REREAD this quote from you:

On Mar 1, 1:00, Tim Peters wrote:
>
> I've grown to appreciate the 3-namespace rule (which, as Guido could tell
> you, I squirmed over at first) precisely because I hate being "not sure".
> When there are only 3 places to look (& "builtin" is no burden on the
> brain, so it's more like 2 places), there are only 2 (& more like 1!)
> ways to screw up. That simplicity is worth something, but doesn't seem
> to be valued in this thread.
>

And I realized that I had been thinking of it as a 2-space rule myself.
I forgot about __builtin__, or assumed that it was not possible to add
names into that module, but I *was* able to:

>>> import __builtin__
>>> __builtin__.xxx = 1
>>> xxx
1

So maybe that fact can be utilized to solve some of these
"default settings" sort of cases.
[ Though I haven't yet figure exactly how. ]

Discussion of optional parameters reminded me to dig out this
pair of modules ( just in case you want to add ONE MORE level
of defaults: the shell environment. It will try to eval one
level, so tuples and lists of constants can be passed. )
This was done before the "if __name__ == '__main__' :" test
became possible. That feature removed one pressing need I
had for this module, so I haven't fiddled with it much since.
I was saving it for the occasion of trying to start up a
general thread on developing STANDARD practices for certain
defaults ( like DEBUG, for example. It would be nice if all
module, classes had a default method of turning DEBUGGING mode
ON. And this is another example, to go with the previous post,
where you might want to turn debuggin on in a single module,
OR you might want debugging turned on in ALL imported modules
without having to find each module and turn it on. This is ALSO
another example where a solution can go in either the language-
support direction, or the language-convention direction. i.e.
if everyone agreed to the convention that an options.py file
should exist somewhere ( not necessarily THIS one ) and if
options.DEBUG exists and is True, then DEBUG mode should be
turned on in all modules. ( Or should it be __builtin__.DEBUG ? ))

$ PYTHONTEST="( 1,2,3 )"
$ PYTHONARG1="Hello World"
$ python -c 'import options; dir(options)'

The above shell assignments and the python command produces:

{PYTHONTEST} : ( 1,2,3 )
Try: exec: TEST = ( 1,2,3 )
{PYTHONARG1} : Hello World
Try: exec: ARG1 = Hello World
Try: exec: ARG1 = 'Hello World'
['ARG1', 'LIST', 'OK', 'TEST', '__name__', 'test']

- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics

------------------------

# options.py
#
# if posix.environ supported then look for any environ variables
# that start with "PYTHON". For each, strip off the leading "PYTHON"
# and try to create a symbol by constructing and exec-ing an assignment:
# first with the value itself, then try it quoted.
try:
from posix import environ
for env in environ.keys():
if env[:6] == 'PYTHON' :
print '{'+env+'}', ':', environ[env]
try:
e = env[6:] + ' = ' + environ[env]
print 'Try: exec:',e
exec(e)
except (NameError, SyntaxError):
e = env[6:] + ' = \'' + environ[env] +'\''
print 'Try: exec:', e
exec( e )
del e
else:
del env
del environ
# clean up all of the extraneous symbols.
except ImportError:
pass
#
# set any global options here:
#
test='Testing: 1,2,3...'
OK=1

# getoptions.py
#
import options
#
# options can be accesses by:
# "options.name" or "options.__dict__['name']" or "getattr( options, 'name' )"
# but all of the above will create an exception if it doesn't exist.
#
#
def getopt( name ):
return ((name in dir(options)) and getattr( options, name ) )