[ ... ]
>
>The function approach fails for two reasons. First, asymbol is a defined
>symbol, because it's a formal parameter. Second, if the name passed
>to boundp is unbound, a NameError will occur when the function arguments
>are evaluated. A similar situation arises with Lisp, and the
>programmer must quote the symbol argument. Unfortunately, Python has no
>equivalent token quote mechanism.
>
>Writing an extension might be a feasible solution. The argument
>passed would still have to be quoted somehow (because it would
>be evaulated too early otherwise). Also, Python interpreter
>internal functions for symbol table lookup would have to be used.
>
>Conclusion: Python needs eval and quote language built-ins,
>and an improved try statement (ie, a notexcept: clause).
>
Python *HAS* eval()
>>> eval('open')
<built-in function __builtin__.open>
>>> eval('not_defined')
Traceback (innermost last):
File "<stdin>", line 1
File "<string>", line 0
NameError: not_defined
And if you want to see if it is bound ANYWHERE, not just the current
scope ( or if you don't want to wrap your eval in try/except's ) :
>>> import sys
>>> for M in sys.modules.values() :
... if M.__dict__.has_key( 'open' ) : print repr( M.__dict__['open'] )
...
<built-in function __builtin__.open>
But Python's quote|backquote is not anything like Lisp's because
Python doesn't have symbols in the Lisp sense ( although there
was a whole thread about the possibility of adding them. )
An important point is that:
>>> `open` # or repr(open')
'<built-in function __builtin__.open>'
and:
>>> eval('open')
<built-in function __builtin__.open>
but:
>>> eval( repr(open) )
Traceback (innermost last):
File "<stdin>", line 1
File "<string>", line 1
<built-in function __builtin__.open>
^
SyntaxError: invalid syntax
Built-in functions don't have a func_name attribute, many other objects
do not have an accessable name attribute, and those that do don't have
a consistant name for them. ( e.g. modules have '__name__' variables. )
So, it's not just a matter of adding a missing function.
Python semantics are not Lisp semantics.
Python names are not Lisp symbols.
And it's hard to give a better example of an "equivalent" in Python,
since when you talk about passing a "symbol" , I have no idea what
you mean! You can pass a name-string, or you can pass an Object,
but what do you mean by "symbol" ?
[ I don't think I would want to turn Python into Lisp, even if Guido
*suspects* me of that sometimes, but if I could turn back the clock,
I would wish that some things, like "name" attributes were done
more consistently! ]
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics