Proposal for adding symbols within Python

[Mike Meyer]

Pierre Barbier de Reuille <pierre.barbier at cirad.fr> writes:
>>>In LISP : Symbols are introduced by "'". "'open" is a symbol.
>> No, they're not. "'(a b c)" is *not* a symbol, it's a list. Symbols in
>> LISP are just names. "open" is a symbol, but it's normally evaluated.
>> The "'" is syntax that keeps the next expression from being evaluated,
>> so that "'open" gets you the symbol rather than it's value. Since
>> you're trying to introduce syntax, I think it's important to get
>> existing practice in other languages right.
> You're right ! I was a bit quick here ... "'" is a way to stop
> evaluation and you may also write "(quote open)" for "'open".

Yup. Also notice that if you eval the symbol, you get any value that
happens to be bound to it. This is irrelevant for your purposes. But
the properties you're looking for are - in LISP, anyway -
implementation details of how it handles names.

>> While you don't make it clear, it seems obvious that you intend that
>> if $open occurs twice in the same scope, it should refer to the same
>> symbol. So you're using the syntax for a dual purpose. $name checks to
>> see if the symbol name exists, and references that if so. If not, it
>> creates a new symbol and with that name. Having something that looks
>> like a variables that instantiates upon reference instead of raising
>> an exception seems like a bad idea.
>
> Well, that's why symbols are absolutely not variables.

If they aren't variables, they probably shouldn't *look* like
variables.

>> Provide a solid definition for the proposed builtin type "symbol".
>> Something like:
>> 
>>           symbol objects support two operations: is and equality
>>           comparison. Two symbol objects compare equal if and only if
>>           they are the same object, and symbol objects never compare
>>           equal to any other type of object. The result of other
>>           operations on a symbol object is undefined, and should raise
>>           a TypeError exception.
>> 
>>           symbol([value]) - creates a symbol object. Two distinct
>>           calls to symbol will return two different symbol objects
>>           unless the values passed to them as arguments are equal, in
>>           which case they return the same symbol object. If symbol is
>>           called without an argument, it returns a unique symbol.
>
> Good definition to me !

Note that this definition doesn't capture the name-space semantics you
asked for - symbol(value) is defined to return the same symbol
everywhere it's called, so long as value is equal. This is probably a
good thing. Using the ability to have non-strings for value means you
can get this behavior by passing in something that's unique to the
namespace as part of value. Said something probably depends on the the
flavor of the namespace in question. This allows you to tailor the
namespace choice to your needs.

Also, since I'm allowing non-strings for value, just invoking str on
the symbol isn't really sufficient. Let's add an attribute 'value',
such that symbol(stuff).value is identical to stuff. I you want,
define symbol.__str__ as str(symbol.value) so that str(symbol("foo"))
returns "foo".

> Well, maybe we should find some other way to express symbols. The only
> thing I wanted was a way easy to write, avoiding the need to declare
> symbols, and allowing the specification of the scope of the symbol. My
> prefered syntax would be something like :
> 'opened, `opened or `opened`
> However, none are usable in current Python.

Well, symbol('opened') solves the declaration issue, but it's not as
easy as you'd like.

>> Personally, I think that the LISP quote mechanism would be a better
>> addition as a new syntax, as it would handle needs that have caused a
>> number of different proposals to be raised.  It would require that
>> symbol know about the internals of the implementation so that ?name
>> and symbol("name") return the same object, and possibly exposing said
>> object to the programmer. And this is why the distinction about how
>> LISP acts is important.
> Maybe, although I may say I cannot see clearly how LISP quote mechanism
> translates into Python.

It compiles the quoted expression and returns a code object.  I'd love
to recycle backquotes so that `expr` means
compile(expr, 'quoted-expr', 'eval'), but that won't happen anytime soon.

Hmm. You know, $symbol$ doesn't seem nearly as bad as $symbol. It
tickles TeX, not P***. I could live with that.

Like I said, the tricky part of doing this is getting `symbol` to have
the semantics you want. If you compile the same string twice, you get
two different code objects, though they compare equal, and the
variable names in co_names are the same strings. Maybe equality is
sufficient, and you don't need identity.

         <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.