Proposal for adding symbols within Python

[Pierre Barbier de Reuille]

Please, note that I am entirely open for every points on this proposal
(which I do not dare yet to call PEP).

Abstract
========

This proposal suggests to add symbols into Python.

Symbols are objects whose representation within the code is more
important than their actual value. Two symbols needs only to be
equally-comparable. Also, symbols need to be hashable to use as keys of
dictionary (symbols are immutable objects).

Motivations
===========

Currently, there is no obvious way to define constants or states or
whatever would be best represented by symbols. Discussions on
comp.lang.pytho n shows at least half a dozen way to replace symbols.

Some use cases for symbols are : state of an object (i.e. for a file
opened/closed/error) and unique objects (i.e. attributes names could be
represented as symbols).

Many languages propose symbols or obvious ways to define symbol-like
values. For examples in common languages:

In C/C++ : Symbols are emulated using Enums.
In Haskell/OCaml : Symbols are defined by union types with empty
constructors. Symbols are local to modules.
In Prolog : Symbols are called atoms ... they are local to modules (at
least in swi-prolog)
In Ruby : Symbols are introduced be the ":" notation. ":open" is a
symbol. Symbols are global.
In LISP : Symbols are introduced by "'". "'open" is a symbol. Symbols
are local to modules.

Proposal
========

First, I think it would be best to have a syntax to represent symbols.
Adding some special char before the name is probably a good way to
achieve that : $open, $close, ... are $ymbols.

On the range of symbols, I think they should be local to name space
(this point should be discussed as I see advantages and drawbacks for
both local and global symbols). For example, for the state of the file
object I would write :
[color=blue][color=green][color=darkred]
>>> file.$open, file.$close, file.$error[/color][/color][/color]

Then, given some other objects (say some other device which also may be
opened) :
[color=blue][color=green][color=darkred]
>>> assert f.state != dev.state[/color][/color][/color]

would always hold if both objects use locally-defined symbols. The only
way for these states to be equal would be, for example, for the device
object to explicitly assign the file symbols :
[color=blue][color=green][color=darkred]
>>> dev.state = file.$open[/color][/color][/color]

By default, symbols should be local to the current module. Then, being
in the module "device_manager ", this would hold:
[color=blue][color=green][color=darkred]
>>> assert $opened == device_manager. $opened[/color][/color][/color]

There should be a way to go from strings to symbols and the other way
around. For that purpose, I propose:
[color=blue][color=green][color=darkred]
>>> assert symbol("opened" ) == $opened
>>> assert str($opened) == "opened"[/color][/color][/color]

Implementation
==============

One possible way to implement symbols is simply with integers resolved
as much as possible at compile time.

The End
=======

Thanks to those who read entirely this proposal and I hope this proposal
will gather enough interests to become a PEP and someday be implemented,
maybe (probably?) in a completely different way ;)

Pierre

[Ben Finney]

Re: Proposal for adding symbols within Python

Pierre Barbier de Reuille <pierre.barbier @cirad.fr> wrote:[color=blue]
> This proposal suggests to add symbols into Python.[/color]

I still don't think "symbol" is particularly descriptive as a name;
there are too many other things already in the language that might
also be called a "symbol".
[color=blue]
> Symbols are objects whose representation within the code is more
> important than their actual value.[/color]

An interesting
[color=blue]
> Two symbols needs only to be equally-comparable.[/color]

I believe it would be more useful to have enumerated types in Python,
which would also allow values from the same type to be cmp() compared.
[color=blue]
> Currently, there is no obvious way to define constants or states or
> whatever would be best represented by symbols.[/color]

"constants" isn't a good equivalent here, since constants in most
other languages are all about the name-to-value mapping, which you
said was unimportant for this concept.
[color=blue]
> Discussions on comp.lang.pytho n shows at least half a dozen way to
> replace symbols.[/color]

s/replace/implement/
[color=blue]
> Some use cases for symbols are : state of an object (i.e. for a file
> opened/closed/error) and unique objects (i.e. attributes names could
> be represented as symbols).[/color]

That pretty much covers the common use cases. Nicely done.
[color=blue]
> First, I think it would be best to have a syntax to represent
> symbols.[/color]

I disagree. Namespaces would be fine, and would also make clear which
values were related to each other; e.g. for your "state of an object"
use case, it's useful to have all the states in one namespace,
separate from unrelated states of other classes of objects.
[color=blue]
> Adding some special char before the name is probably a good way to
> achieve that : $open, $close, ... are $ymbols.[/color]

Counterproposal :

FileState = SomeTypeDefinin gStates( 'open', 'closed' )

thefile.state = FileState.open
if thefile.state == FileState.close d:
print "File is closed"

So all that's needed here is the type SomeTypeDefinin gStates, not a
new syntax.
[color=blue]
> One possible way to implement symbols is simply with integers
> resolved as much as possible at compile time.[/color]

I believe all your requirements and motivations could be met with an
Enum type in the language. Here's an implementation using a sequence
of integers for the underlying values:

"First Class Enums in Python"
<URL:http://aspn.activestat e.com/ASPN/Cookbook/Python/Recipe/413486>

An enumerated type would also allow values from that type to be
compared with cmp() if their sequence was considered important. e.g.
for object state, the "normal" sequence of states could be represented
in the enumeration, and individual states compared to see if they are
"later" that each other. If sequence was not considered important, of
course, this feature would not get in the way.

--
\ "I put instant coffee in a microwave oven and almost went back |
`\ in time." -- Steven Wright |
_o__) |
Ben Finney

[Mike Meyer]

Re: Proposal for adding symbols within Python

Pierre Barbier de Reuille <pierre.barbier @cirad.fr> writes:[color=blue]
> Please, note that I am entirely open for every points on this proposal
> (which I do not dare yet to call PEP).
>
> Abstract
> ========
>
> This proposal suggests to add symbols into Python.[/color]

You're also proposing adding a syntax to generate symbols. If so, it's
an important distinction, as simply addig symbols is a lot more
straightforward than adding new syntax.
[color=blue]
> Symbols are objects whose representation within the code is more
> important than their actual value. Two symbols needs only to be
> equally-comparable. Also, symbols need to be hashable to use as keys of
> dictionary (symbols are immutable objects).[/color]

The values returned by object() meet this criteria. You could write
LISPs gensym as:

gensym = object

As you've indicated, there are a number of ways to get such
objects. If all you want is symbols, all that really needs to happen
is that one of those ways be blessed by including an implementation in
the distribution.
[color=blue]
> In LISP : Symbols are introduced by "'". "'open" is a symbol.[/color]

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.
[color=blue]
> Proposal
> ========
>
> First, I think it would be best to have a syntax to represent symbols.[/color]

That's half the proposal.
[color=blue]
> Adding some special char before the name is probably a good way to
> achieve that : $open, $close, ... are $ymbols.[/color]

$ has bad associations for me - and for others that came from an
earlier P-language. Also, I feel that using a magic character to
introduce type information doesn't feel very Pythonic.

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.
[color=blue]
> On the range of symbols, I think they should be local to name space
> (this point should be discussed as I see advantages and drawbacks for
> both local and global symbols).[/color]

Agreed. Having one type that has different scoping rules than
everything else is definitely a bad idea.
[color=blue]
> There should be a way to go from strings to symbols and the other way
> around. For that purpose, I propose:
>[color=green][color=darkred]
>>>> assert symbol("opened" ) == $opened
>>>> assert str($opened) == "opened"[/color][/color][/color]

So the heart of your proposal seems to be twofold: The addition of
"symbol" as a type, and the syntax that has the lookup/create behavior
I described above.
[color=blue]
> Implementation
> ==============
>
> One possible way to implement symbols is simply with integers resolved
> as much as possible at compile time.[/color]

What exactly are you proposing be "resolved" at compile time? How is
this better than using object, as illustratd above?

Suggested changes:

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.

I left the type of the value argument unspecified on purpose. Strings
are the obvious type, but I think it should be as unrestricted as
possible. The test on value is equality, not identity, because two
strings can be equal without being the same string, and we want that
case to give us the same symbol. I also added gensym-like behavior,
because it seemed useful. You could do without equality comparison,
but it seems like a nice thing to have.

Now propose a new syntax that "means" symbol, ala {} "meaning" dict
and [] "meaning" list. Don't use "$name" (& and ^ are also probably
bad, but not as; pretty much everything else but ? is already in
use). Python does seem to be moving away from this kind of thing,
though.

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.

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

[Bengt Richter]

Re: Proposal for adding symbols within Python

On Sat, 12 Nov 2005 16:52:12 -0500, Mike Meyer <mwm@mired.or g> wrote:
[...][color=blue]
>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.[/color]
I wonder if the backquote could be deprecated and repurposed.
It could typographically serve nicely as a lisp quote then. But in python,
how would 'whatever be different from lambda:whatever ?
(where of course whatever could be any expression parenthesized
as necessary)

Regards,
Bengt Richter

[Steven D'Aprano]

Re: Proposal for adding symbols within Python

On Sat, 12 Nov 2005 18:59:39 +0100, Pierre Barbier de Reuille wrote:
[color=blue]
> First, I think it would be best to have a syntax to represent symbols.
> Adding some special char before the name is probably a good way to
> achieve that : $open, $close, ... are $ymbols.[/color]

I think your chances of convincing Guido to introduce new syntax is slim
to none. (Not quite zero -- he did accept @ for decorators.)

I think symbols should simply be an immutable object, one with state and
limited or no behaviour, rather than a brand new syntactical element.
Being an object, you can reference them in whatever namespace you define
them in.

Personally, I think rather than adding a new language feature (...slim to
none...) there is more hope of getting something like this added to the
standard library:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/413486

--
Steven.

[Pierre Barbier de Reuille]

Re: Proposal for adding symbols within Python

Ben Finney a écrit :[color=blue]
> Pierre Barbier de Reuille <pierre.barbier @cirad.fr> wrote:
>[color=green]
>>This proposal suggests to add symbols into Python.[/color]
>
>
> I still don't think "symbol" is particularly descriptive as a name;
> there are too many other things already in the language that might
> also be called a "symbol".[/color]

Well, that's the name in many languages. Then, probably all the things
already in the language that might be called "symbol" may be implemented
using the symbols in this proposal ... or maybe I don't see what you
mean here ?
[color=blue]
>[/color]
[...][color=blue][color=green]
>>First, I think it would be best to have a syntax to represent
>>symbols.[/color]
>
>
> I disagree. Namespaces would be fine, and would also make clear which
> values were related to each other; e.g. for your "state of an object"
> use case, it's useful to have all the states in one namespace,
> separate from unrelated states of other classes of objects.
>
>[color=green]
>>Adding some special char before the name is probably a good way to
>>achieve that : $open, $close, ... are $ymbols.[/color]
>
>
> Counterproposal :
>
> FileState = SomeTypeDefinin gStates( 'open', 'closed' )
>
> thefile.state = FileState.open
> if thefile.state == FileState.close d:
> print "File is closed"
>
> So all that's needed here is the type SomeTypeDefinin gStates, not a
> new syntax.[/color]

The problem, IMHO, is that way you need to declare "symbols"
beforehands, that's what I was trying to avoid by requiring a new syntax.
[color=blue][color=green]
>>One possible way to implement symbols is simply with integers
>>resolved as much as possible at compile time.[/color]
>
>
> I believe all your requirements and motivations could be met with an
> Enum type in the language. Here's an implementation using a sequence
> of integers for the underlying values:
>
> "First Class Enums in Python"
> <URL:http://aspn.activestat e.com/ASPN/Cookbook/Python/Recipe/413486>
>
> An enumerated type would also allow values from that type to be
> compared with cmp() if their sequence was considered important. e.g.
> for object state, the "normal" sequence of states could be represented
> in the enumeration, and individual states compared to see if they are
> "later" that each other. If sequence was not considered important, of
> course, this feature would not get in the way.
>[/color]

Well, I don't think enumarated objects ARE symbols. I can see two
"problems" :
1 - in the implementation, trying to compare values from different
groups raises an error instead of simply returning "False" (easy to fix ...)
2 - You have to declare these enumerable variables, which is not
pythonic IMO (impossible to fix ... needs complete redesign)

In the end, I really think symbols and enum are of different use, one of
the interest un symbols being to let the compiler does what he wants
(i.e. probably what is the most efficient).

Thanks for your reply,

Pierre

[Pierre Barbier de Reuille]

Re: Proposal for adding symbols within Python

Mike Meyer a écrit :[color=blue]
> Pierre Barbier de Reuille <pierre.barbier @cirad.fr> writes:
>[color=green]
>>Please, note that I am entirely open for every points on this proposal
>>(which I do not dare yet to call PEP).
>>
>>Abstract
>>========
>>[/color][/color]
[...][color=blue]
>
>[color=green]
>>Symbols are objects whose representation within the code is more
>>important than their actual value. Two symbols needs only to be
>>equally-comparable. Also, symbols need to be hashable to use as keys of
>>dictionary (symbols are immutable objects).[/color]
>
>
> The values returned by object() meet this criteria. You could write
> LISPs gensym as:
>
> gensym = object
>
> As you've indicated, there are a number of ways to get such
> objects. If all you want is symbols, all that really needs to happen
> is that one of those ways be blessed by including an implementation in
> the distribution.[/color]

Well, I may rewrite the proposal, but one good thing to have is the
hability to go from symbol to string and the opposite (as written below)
and that is not really allowed by this implementation of symbols.
[color=blue]
>
>[color=green]
>>In LISP : Symbols are introduced by "'". "'open" is a symbol.[/color]
>
>
> 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.[/color]

You're right ! I was a bit quick here ... "'" is a way to stop
evaluation and you may also write "(quote open)" for "'open".
[color=blue]
>
>[color=green]
>>Proposal
>>========
>>
>>First, I think it would be best to have a syntax to represent symbols.[/color]
>
>
> That's half the proposal.
>
>[color=green]
>>Adding some special char before the name is probably a good way to
>>achieve that : $open, $close, ... are $ymbols.[/color]
>
>
> $ has bad associations for me - and for others that came from an
> earlier P-language. Also, I feel that using a magic character to
> introduce type information doesn't feel very Pythonic.
>
> 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.
>[/color]

Well, that's why symbols are absolutely not variables. One good model
(IMO) is LISP symbols. Symbols are *values* and equality is not
depending on the way you obtained the symbol :

(eq (quote opened) 'opened)
[color=blue]
>[color=green]
>>On the range of symbols, I think they should be local to name space
>>(this point should be discussed as I see advantages and drawbacks for
>>both local and global symbols).[/color]
>
>
> Agreed. Having one type that has different scoping rules than
> everything else is definitely a bad idea.
>
>[color=green]
>>There should be a way to go from strings to symbols and the other way
>>around. For that purpose, I propose:
>>
>>[color=darkred]
>>>>>assert symbol("opened" ) == $opened
>>>>>assert str($opened) == "opened"[/color][/color]
>
>
> So the heart of your proposal seems to be twofold: The addition of
> "symbol" as a type, and the syntax that has the lookup/create behavior
> I described above.
>[/color]

Indeed !
[color=blue]
>[color=green]
>>Implementatio n
>>============= =
>>
>>One possible way to implement symbols is simply with integers resolved
>>as much as possible at compile time.[/color]
>
>
> What exactly are you proposing be "resolved" at compile time? How is
> this better than using object, as illustratd above?
>
> Suggested changes:
>
> 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.[/color]

Good definition to me !
[color=blue]
>
> I left the type of the value argument unspecified on purpose. Strings
> are the obvious type, but I think it should be as unrestricted as
> possible. The test on value is equality, not identity, because two
> strings can be equal without being the same string, and we want that
> case to give us the same symbol. I also added gensym-like behavior,
> because it seemed useful. You could do without equality comparison,
> but it seems like a nice thing to have.
> Now propose a new syntax that "means" symbol, ala {} "meaning" dict
> and [] "meaning" list. Don't use "$name" (& and ^ are also probably
> bad, but not as; pretty much everything else but ? is already in
> use). Python does seem to be moving away from this kind of thing,
> though.[/color]

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.
[color=blue]
>
> 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.
>
> <mike[/color]

Maybe, although I may say I cannot see clearly how LISP quote mechanism
translates into Python.

[Mike Meyer]

Re: Proposal for adding symbols within Python

Pierre Barbier de Reuille <pierre.barbier @cirad.fr> writes:[color=blue][color=green][color=darkred]
>>>In LISP : Symbols are introduced by "'". "'open" is a symbol.[/color]
>> 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.[/color]
> You're right ! I was a bit quick here ... "'" is a way to stop
> evaluation and you may also write "(quote open)" for "'open".[/color]

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.
[color=blue][color=green]
>> 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.[/color]
>
> Well, that's why symbols are absolutely not variables.[/color]

If they aren't variables, they probably shouldn't *look* like
variables.
[color=blue][color=green]
>> 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.[/color]
>
> Good definition to me ![/color]

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).v alue is identical to stuff. I you want,
define symbol.__str__ as str(symbol.valu e) so that str(symbol("foo "))
returns "foo".
[color=blue]
> 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.[/color]

Well, symbol('opened' ) solves the declaration issue, but it's not as
easy as you'd like.
[color=blue][color=green]
>> 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.[/color]
> Maybe, although I may say I cannot see clearly how LISP quote mechanism
> translates into Python.[/color]

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@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Pierre Barbier de Reuille]

Re: Proposal for adding symbols within Python

Mike Meyer a écrit :[color=blue]
> Pierre Barbier de Reuille <pierre.barbier @cirad.fr> writes:
>[color=green][color=darkred]
>>>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.[/color]
>>
>>Well, that's why symbols are absolutely not variables.[/color]
>
>
> If they aren't variables, they probably shouldn't *look* like
> variables.[/color]

Yes, that's why we should find some way to express that.
[color=blue][color=green][color=darkred]
>>>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.[/color]
>>
>>Good definition to me ![/color]
>
>
> 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.[/color]

Very interesting ... that way we could get global AND local symbols ...
I like it !
[color=blue]
>
> 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).v alue is identical to stuff. I you want,
> define symbol.__str__ as str(symbol.valu e) so that str(symbol("foo "))
> returns "foo".
>
>[color=green]
>>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.[/color]
>
>
> Well, symbol('opened' ) solves the declaration issue, but it's not as
> easy as you'd like.
>
>[color=green][color=darkred]
>>>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.[/color]
>>
>>Maybe, although I may say I cannot see clearly how LISP quote mechanism
>>translates into Python.[/color]
>
>
> 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.[/color]

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

symbol( "symbol" )

And $object.symbol$ could translate into :

symbol( (object, "symbol") )
[color=blue]
>
> 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[/color]

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

[Steven D'Aprano]

Re: Proposal for adding symbols within Python

On Sun, 13 Nov 2005 10:11:04 +0100, Pierre Barbier de Reuille wrote:
[color=blue]
> The problem, IMHO, is that way you need to declare "symbols"
> beforehands, that's what I was trying to avoid by requiring a new syntax.[/color]

???

If you don't declare your symbols, how will you get the ones that you want?

I don't understand why it is a problem to declare them first, and if it is
a problem, what your solution would be.

[snip]
[color=blue]
> Well, I don't think enumarated objects ARE symbols. I can see two
> "problems" :
> 1 - in the implementation, trying to compare values from different
> groups raises an error instead of simply returning "False" (easy to fix ...)[/color]

As you say, that's easy to fix.
[color=blue]
> 2 - You have to declare these enumerable variables, which is not
> pythonic IMO (impossible to fix ... needs complete redesign)[/color]

Are you suggesting that the Python language designers should somehow
predict every possible symbol that anyone in the world might ever need,
and build them into the language as predefined things?

If that is not what you mean, can you explain please, because I'm confused.



--
Steven.

[Pierre Barbier de Reuille]

Re: Proposal for adding symbols within Python

Steven D'Aprano a écrit :[color=blue]
> On Sun, 13 Nov 2005 10:11:04 +0100, Pierre Barbier de Reuille wrote:
>
>[color=green]
>>The problem, IMHO, is that way you need to declare "symbols"
>>beforehands , that's what I was trying to avoid by requiring a new syntax.[/color]
>
>
> ???
>
> If you don't declare your symbols, how will you get the ones that you want?
>
> I don't understand why it is a problem to declare them first, and if it is
> a problem, what your solution would be.
>[/color]

Well, just as Python do not need variable declaration, you can just
*use* them ... in dynamic languages using symbols, they just get created
when used (i.e. have a look at LISP or Ruby).
[color=blue]
> [snip]
>
>[color=green]
>>Well, I don't think enumarated objects ARE symbols. I can see two
>>"problems" :
>> 1 - in the implementation, trying to compare values from different
>>groups raises an error instead of simply returning "False" (easy to fix ...)[/color]
>
>
> As you say, that's easy to fix.
>
>[color=green]
>> 2 - You have to declare these enumerable variables, which is not
>>pythonic IMO (impossible to fix ... needs complete redesign)[/color]
>
>
> Are you suggesting that the Python language designers should somehow
> predict every possible symbol that anyone in the world might ever need,
> and build them into the language as predefined things?
>
> If that is not what you mean, can you explain please, because I'm confused.
>[/color]

Well, the best I can propose is for you to read the discussion with Mike
Meyer.
He pointer out the flaws in my proposal and we're trying to precise things.

Pierre

[Ben Finney]

Re: Proposal for adding symbols within Python

Steven D'Aprano <steve@removeth iscyber.com.au> wrote:[color=blue]
> On Sun, 13 Nov 2005 10:11:04 +0100, Pierre Barbier de Reuille wrote:[color=green]
> > The problem, IMHO, is that way you need to declare "symbols"
> > beforehands, that's what I was trying to avoid by requiring a new
> > syntax.[/color]
>
> If you don't declare your symbols, how will you get the ones that
> you want?
> [...]
> Are you suggesting that the Python language designers should somehow
> predict every possible symbol that anyone in the world might ever
> need, and build them into the language as predefined things?[/color]

I believe Pierre is looking for a syntax that will save him from
assigning values to names; that Python will simply assign arbitrary
unique values for these special names. My understanding of the
intended use is that their only purpose is to compare differently to
other objects of the same type, so the actual values don't matter.

What I still don't understand is why this justifies additional syntax
baggage in the language, rather than an explicit assignment earlier in
the code.

--
\ "Smoking cures weight problems. Eventually." -- Steven Wright |
`\ |
_o__) |
Ben Finney

[Ben Finney]

Re: Proposal for adding symbols within Python

Pierre Barbier de Reuille <pierre.barbier @cirad.fr> wrote:[color=blue]
> Mike Meyer a écrit :[color=green]
> > Hmm. You know, $symbol$ doesn't seem nearly as bad as $symbol. It
> > tickles TeX, not P***. I could live with that.[/color]
> Yep, I like this $symbol$ notation ![/color]

Gets a big -1 here.

I've yet to see a convincing argument against simply assigning values
to names, then using those names.

--
\ "Yesterday I parked my car in a tow-away zone. When I came back |
`\ the entire area was missing." -- Steven Wright |
_o__) |
Ben Finney

[Steven D'Aprano]

Re: Proposal for adding symbols within Python

On Sun, 13 Nov 2005 12:33:48 +0100, Pierre Barbier de Reuille wrote:
[color=blue]
> Steven D'Aprano a écrit :[color=green]
>> On Sun, 13 Nov 2005 10:11:04 +0100, Pierre Barbier de Reuille wrote:
>>
>>[color=darkred]
>>>The problem, IMHO, is that way you need to declare "symbols"
>>>beforehand s, that's what I was trying to avoid by requiring a new syntax.[/color]
>>
>>
>> ???
>>
>> If you don't declare your symbols, how will you get the ones that you want?
>>
>> I don't understand why it is a problem to declare them first, and if it is
>> a problem, what your solution would be.
>>[/color]
>
> Well, just as Python do not need variable declaration, you can just
> *use* them ... in dynamic languages using symbols, they just get created
> when used (i.e. have a look at LISP or Ruby).[/color]

If you want to be technical, Python doesn't have variables. It has names
and objects.

If I want a name x to be bound to an object 1, I have to define it
(actually bind the name to the object):

x = 1

If I want a symbol $x$ (horrible syntax!!!) with a value 1, why shouldn't
I define it using:

$x$ = 1

instead of expecting Python to somehow magically know that I wanted it?
What if somebody else wanted the symbol $x$ to have the value 2 instead?

[color=blue][color=green]
>> [snip]
>>
>>[color=darkred]
>>>Well, I don't think enumarated objects ARE symbols. I can see two
>>>"problems" :
>>> 1 - in the implementation, trying to compare values from different
>>>groups raises an error instead of simply returning "False" (easy to fix ...)[/color]
>>
>>
>> As you say, that's easy to fix.
>>
>>[color=darkred]
>>> 2 - You have to declare these enumerable variables, which is not
>>>pythonic IMO (impossible to fix ... needs complete redesign)[/color]
>>
>>
>> Are you suggesting that the Python language designers should somehow
>> predict every possible symbol that anyone in the world might ever need,
>> and build them into the language as predefined things?
>>
>> If that is not what you mean, can you explain please, because I'm confused.
>>[/color]
>
> Well, the best I can propose is for you to read the discussion with Mike
> Meyer.
> He pointer out the flaws in my proposal and we're trying to precise things.[/color]

I've read the discussion, and I am no wiser.

You haven't explained why enums are not suitable to be used for symbols.
You gave two "problems", one of which was "easy to fix", as you said
yourself, and the other reason was that you don't want to define enums as
symbols.

If you don't want to define something manually, that can only mean that
you expect them to be predefined. Or am I misunderstandin g something?



--
Steven.

[Pierre Barbier de Reuille]

Re: Proposal for adding symbols within Python

Ben Finney a écrit :[color=blue]
> Pierre Barbier de Reuille <pierre.barbier @cirad.fr> wrote:
>[color=green]
>>Mike Meyer a écrit :
>>[color=darkred]
>>>Hmm. You know, $symbol$ doesn't seem nearly as bad as $symbol. It
>>>tickles TeX, not P***. I could live with that.[/color]
>>
>>Yep, I like this $symbol$ notation ![/color]
>
>
> Gets a big -1 here.
>
> I've yet to see a convincing argument against simply assigning values
> to names, then using those names.
>[/color]

I can see three interests :
1 - ensure values are unique (i.e. a bit like using instances of object)
2 - values are meaningful (i.e. with introspection on the values you get
a human-readable value, unlike with instances of object)
3 - getting an *easy* access to those two properties

1 and 2 require a new type, 3 a new syntax (IMO).

Here's a try for the symbol class :

class symbol(object):
def __init__(self, value):
self._value = value
def _get_value(self ):
return self._value
value = property(_get_v alue)
def __eq__(self, other):
return self.value == other.value
def __str__(self):
return str(self.value)
def __repr__(self):
return "symbol(%s) " % (repr(self.valu e),)

One thing to do would be to return the same object for symbols with the
same value (when possible ...).

For example, if we limit symbol to hashable types, we can implement
something which can be tested with "is" instead of "==":

class symbol(object):
_cache = {}
def __new__(cls, value):
if value in symbol._cache:
return symbol._cache[value]
self = object.__new__( cls)
self._value = value
symbol._cache[value] = self
return self
def _get_value(self ):
return self._value
value = property(_get_v alue)
def __eq__(self, other):
return self.value == other.value
def __str__(self):
return str(self.value)
def __repr__(self):
return "symbol(%s) " % (repr(self.valu e),)

Then, as I suggested, you can do something like :

a = symbol((file, "opened"))

But it's less readable than $file.opened$ (or something similar).

Pierre