Proposal for adding symbols within Python

[Pierre Barbier de Reuille]

Mike Meyer a écrit :
> Pierre Barbier de Reuille <pierre.barbier at cirad.fr> writes:
> 
>>>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.

Yes, that's why we should find some way to express that.

>>>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.

Very interesting ... that way we could get global AND local symbols ...
I like it !

> 
> 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.

Yep, I like this $symbol$ notation ! It could me equivalent to :

symbol( "symbol" )

And $object.symbol$ could translate into :

symbol( (object, "symbol") )

> 
> 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

Yep, that's something I always found strange but I think this is for
optimization reasons. However, with symbols the problem is quite
different and we can take some time to ensure there are never two same
objects with different ids ... then, we can also garanty only the use of
"==" and not of "is" ...

Pierre