Proposal for adding symbols within Python

[Björn Lindström]

Re: Proposal for adding symbols within Python

Ben Finney <bignose+hate s-spam@benfinney. id.au> writes:
[color=blue]
> I've yet to see a convincing argument against simply assigning values
> to names, then using those names.[/color]

The problem with that is that you can't pass around the names of objects
that are used for other things. Obviously they make enums unnecessary,
but only people damaged by non-dynamic languages could think that's the
main point. ;-)

Being able to do that precludes the need for converting going back and
forth between strings and method names when you need to do things like
keeping a list of function names, even when you need to be able to
change what those function names point to.

Python doesn't really need to introduce a new type to do this. It's
already there, as what we usually just call names. Probably this
discussion would benefit from talking about names rather than symbols,
as that seems to confuse some people.

So, Python already has symbols. What we need is a way to refer to these
symbols explicitly. I would suggest to do it like in Lisp:

quote(spam)

Of course, this would preferably be implemented so that it doesn't just
work on simple names:

quote(spam(eggs ))

I syntactic sugar, like ' in Lisp, could be introduced later, but I
don't think that would be strictly necessary.

--
Björn Lindström <bkhl@stp.lingf il.uu.se>
Student of computational linguistics, Uppsala University, Sweden

[Steven D'Aprano]

Re: Proposal for adding symbols within Python

On Mon, 14 Nov 2005 00:48:46 +1100, Ben Finney wrote:
[color=blue]
> Steven D'Aprano <steve@removeth iscyber.com.au> wrote:[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"
>> > 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.[/color]

Unless I've misunderstood something, it would be easy to modify the recipe
given here to do something like that:

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

The example code does this:

Days = Enum('Mo', 'Tu', 'We', 'Th', 'Fr', 'Sa', 'Su')
print Days.Mo, Days.Tu
# etc.

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

The only advantage would be if you want to do something like this:

MO, TU, WE, TH, FR, SA, SU = Symbols()

and have it magically work. I can see the advantage of that, and you don't
even need new syntax, just a magic function that somehow knows how many
names are on the left hand side of the assignment.

This is a poor substitute:

MO, TU, WE, TH, FR, SA, SU = range(7)

Firstly, if you change the number of symbol names, you have to manually
adjust the argument to range. Secondly, your symbols are actually ints,
and so will compare the same way ints compare.


I don't know enough about the Python internals to tell: is there any
feasible way for there to be a magic function like Symbol above that knew
how many names were waiting for it to be supplied? If there is no way to
do this from Python itself, it is possible to patch the compiler to do so?



--
Steven.

[Pierre Barbier de Reuille]

Re: Proposal for adding symbols within Python

Steven D'Aprano a écrit :[color=blue]
> On Sun, 13 Nov 2005 12:33:48 +0100, Pierre Barbier de Reuille wrote:
>
>[color=green]
>>Steven D'Aprano a écrit :
>>[...][/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]

Well, as stated, I don't care about the actual value of symbols. They
*are* values. A trivial implementation of symbols are strings :

$x$ <=> "x"

However, that won't fit because of the scope, because it would be great
to use "is" instead of "==" (even if not necessary), and as said Mike,
you might want something else than a string. That's why `x` would be a
good wawy to write that.
[color=blue]
>
>[color=green][color=darkred]
>>>[snip][/color][/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?
>[/color]

Well, I suspect Python will know them, exactly as it know "without
defining it" that "foo" is the string with chars f, o, o, that 3 is the
number 3, that [1,2] is the list with 1 and 2, ... However, to get
quicker, symbols could be created at compile-time when possible (like
variables). The fact is, symbols allow compilation optimisations that
you cannot get with regular types, because the language is completely
free about their representations . Then, to the programmer it is a good
way to have a meaningful value without caring about how to represent it
in the computer. That way, while debugging, if I ask the value of
file.state I will get something I can read instead of some meaningless
integer or other anonymous object.

So I gain in readability of my code and in debugging capacity.

Pierre

[Pierre Barbier de Reuille]

Re: Proposal for adding symbols within Python

Björn Lindström a écrit :[color=blue]
> Ben Finney <bignose+hate s-spam@benfinney. id.au> writes:
>
>[color=green]
>>I've yet to see a convincing argument against simply assigning values
>>to names, then using those names.[/color]
>
>
> The problem with that is that you can't pass around the names of objects
> that are used for other things. Obviously they make enums unnecessary,
> but only people damaged by non-dynamic languages could think that's the
> main point. ;-)
>
> Being able to do that precludes the need for converting going back and
> forth between strings and method names when you need to do things like
> keeping a list of function names, even when you need to be able to
> change what those function names point to.
>
> Python doesn't really need to introduce a new type to do this. It's
> already there, as what we usually just call names. Probably this
> discussion would benefit from talking about names rather than symbols,
> as that seems to confuse some people.
>
> So, Python already has symbols. What we need is a way to refer to these
> symbols explicitly. I would suggest to do it like in Lisp:
>
> quote(spam)
>
> Of course, this would preferably be implemented so that it doesn't just
> work on simple names:
>
> quote(spam(eggs ))
>
> I syntactic sugar, like ' in Lisp, could be introduced later, but I
> don't think that would be strictly necessary.
>[/color]

Well, if this already exists in Python's internals, then, it would be
great just to expose them. Now, just being able to write :
[color=blue][color=green][color=darkred]
>>> quote(spam)[/color][/color][/color]
quote(spam)

requires a new syntax so that spam is not resolved *before* calling the
quote method.

Pierre

[Michael]

Re: Proposal for adding symbols within Python

Ben Finney wrote:
....[color=blue]
> I've yet to see a convincing argument against simply assigning values
> to names, then using those names.[/color]

I don't like any syntax I've seen so far, but I can understand the problem.
If you have a name, you can redefine a name, therefore the value a name
refers to is mutable. As a result if you have 2 symbols represented by
names and values, you may have two symbols with different names but the
same value. Hence the two "symbols" are no longer unique)

Conversely consider "NAME" to be a symbol. I can't modify "NAME". It always
means the same as "NAME" and "NAME", but is never the same as "FRED".
What's tricky is I can't have namespaceOne."N AME" [1] and
namespaceTwo."N AME" as different "NAME"s even though logically there's no
reason I couldn't treat "NAME" differently inside each.

[1] Supposing for a moment that I could have a string as a name in a
namespace. (Rather than a string used as a key in that namespace)

However it might be useful to note that these two values (or symbols) are
actually different, even if you remove their namespaces.

To me, the use of a symbol implies a desire for a constant, and then to only
use that constant rather than the value. In certain situations it's the
fact that constant A is not the same as constant B that's important (eg
modelling state machines).

Often you can use strings for that sort of thing, but unfortunately even
python's strings can't be used as symbols that are always the same thing
in all ways. For example, we can force the id of identical strings to be
different:[color=blue][color=green][color=darkred]
>>> s = "h"*10000
>>> x = "h"*10000
>>> id(s), id(x)[/color][/color][/color]
(135049832, 135059864)

As a result I can see that *IF* you really want this kind of symbol, rather
than the various other kinds people have discussed in the thread, that some
special syntax (like u'hello' for unicode 'hello') could be useful.

However, I'd be more interested in some real world usecases where this would
be beneficial, and then seeing what sort of syntax would be nice/useful
(Especially since I can think of some uses where it would be nice).

On the original syntax proposal, I'm firmly in the -1 camp - to me having
done lots of perl in the past $foo looks very firmly like a mutable, rather
than an immutable.

The reason I'm more interested in seeing usecases, is because I'd rather see
where the existing approaches people use/define symbols has caused the OP
problems to the extent he feels the language needs to change to fix these
real world problems.


Michael.

[Ben Finney]

Re: Proposal for adding symbols within Python

Steven D'Aprano <steve@removeth iscyber.com.au> wrote:[color=blue]
> On Mon, 14 Nov 2005 00:48:46 +1100, Ben Finney wrote:[color=green]
> > 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.[/color]
>[color=green]
> > 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.[/color]
>
> The only advantage would be if you want to do something like this:
>
> MO, TU, WE, TH, FR, SA, SU = Symbols()[/color]

I believe that's exactly what Pierre doesn't want to do. He wants to
simply use names (marked special in some way) and have Python
automatically determine a unique value for each name, with nary an
assignment in sight.

To me, that's a net loss. It makes names more complicated, it loses
"explicit is better than implicit", and it loses the checks Python
could do against using a name that hasn't been assigned a value
(caused by e.g. a misspelled name).

--
\ "Why should I care about posterity? What's posterity ever done |
`\ for me?" -- Groucho Marx |
_o__) |
Ben Finney

[Erik Max Francis]

Re: Proposal for adding symbols within Python

Ben Finney wrote:
[color=blue]
> I believe that's exactly what Pierre doesn't want to do. He wants to
> simply use names (marked special in some way) and have Python
> automatically determine a unique value for each name, with nary an
> assignment in sight.
>
> To me, that's a net loss. It makes names more complicated, it loses
> "explicit is better than implicit", and it loses the checks Python
> could do against using a name that hasn't been assigned a value
> (caused by e.g. a misspelled name).[/color]

I agree. And, when done explicitly, it's already easy enough to do this
within the language, by just assigning it a value, even if it's an
integer from range/xrange or a new sentinel like object().

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
The stairs of the sky are let down for him that he may ascend thereon
to heaven. O gods, put your arms under the king: raise him, lift him

[Ben Finney]

Re: Proposal for adding symbols within Python

Michael <ms@cerenity.or g> wrote:[color=blue]
> Ben Finney wrote:[color=green]
> > I've yet to see a convincing argument against simply assigning
> > values to names, then using those names.[/color]
>
> If you have a name, you can redefine a name, therefore the value a
> name refers to is mutable.[/color]

Since there are mutable and immutable values, it might be clearer to
say "the binding of a name to a value can be changed". Yes?

In that case, I don't see why someone who wants such a binding to be
unchanging can't simply avoid changing it. Where's the case for having
Python enforce this?
[color=blue]
> Conversely consider "NAME" to be a symbol. I can't modify "NAME". It
> always means the same as "NAME" and "NAME", but is never the same as
> "FRED". What's tricky is I can't have namespaceOne."N AME" [1] and
> namespaceTwo."N AME" as different "NAME"s even though logically
> there's no reason I couldn't treat "NAME" differently inside each.[/color]

So you want to mark such objects as being in a namespace, where they
compare the same within that namespace but not outside. Why is
separate syntax necessary for this? A data type that is informed of
its "space", and refuses comparison with values from other spaces,
would suffice.

class Xenophobe(objec t):
def __init__(self, space, value):
self.__space = space
self.__value = value

def __str__(self):
return str(self.__valu e)

def __cmp__(self, other):
if not isinstance(othe r, Xenophobe):
raise AssertionError, \
"Can only compare Xenophobes to each other"
if not other.__space == self.__space:
raise AssertionError, \
"Can only compare Xenophobes from the same space"
return cmp(self.__valu e, other.__value)

With the bonus that you could pass such values around between
different names, and they'd *still* compare, or not, as you choose
when you first create them.

Replace the AssertionError with some appropriate return value, if you
want such comparisons to succeed.
[color=blue]
> However it might be useful to note that these two values (or
> symbols) are actually different, even if you remove their
> namespaces.[/color]

The above Xenophobe implementation creates objects that know their
"space" forever.
[color=blue]
> To me, the use of a symbol implies a desire for a constant, and then
> to only use that constant rather than the value. In certain
> situations it's the fact that constant A is not the same as constant
> B that's important (eg modelling state machines).[/color]

Since the actual value can't be easily accessed, the only purpose of a
Xenophobe is too be created and compared to others.
[color=blue]
> Often you can use strings for that sort of thing, but unfortunately
> even python's strings can't be used as symbols that are always the
> same thing in all ways. For example, we can force the id of
> identical strings to be different:[/color]

Hold up -- what in your stated use case requires *identity* to be the
same? You said you just wanted to compare them to each other.

Besides, Python *does* preserve identity for short strings...
[color=blue][color=green][color=darkred]
> >>> s = "h"*10000
> >>> x = "h"*10000
> >>> id(s), id(x)[/color][/color]
> (135049832, 135059864)[/color]

.... which is sufficient for unique values, if you're not actively
fighting the system as above. If the use case is for brief, identical
values, we have those: short strings.
[color=blue]
> As a result I can see that *IF* you really want this kind of symbol,
> rather than the various other kinds people have discussed in the
> thread, that some special syntax (like u'hello' for unicode 'hello')
> could be useful.[/color]

I can see the case for a new type. I disagree that syntax changes are
necessary.
[color=blue]
> However, I'd be more interested in some real world usecases where
> this would be beneficial, and then seeing what sort of syntax would
> be nice/useful (Especially since I can think of some uses where it
> would be nice).[/color]

Real use cases would interest me, too, but *only* if they can't be
satisfied with a new type that knows things about its creation state,
such as Xenophobe.
[color=blue]
> The reason I'm more interested in seeing usecases, is because I'd
> rather see where the existing approaches people use/define symbols
> has caused the OP problems to the extent he feels the language needs
> to change to fix these real world problems.[/color]

Ditto.

--
\ "My aunt gave me a walkie-talkie for my birthday. She says if |
`\ I'm good, she'll give me the other one next year." -- Steven |
_o__) Wright |
Ben Finney

[Pierre Barbier de Reuille]

Re: Proposal for adding symbols within Python

Ben Finney a écrit :[color=blue]
> Michael <ms@cerenity.or g> wrote:
>[color=green]
>>Ben Finney wrote:
>>[color=darkred]
>>>I've yet to see a convincing argument against simply assigning
>>>values to names, then using those names.[/color]
>>
>>If you have a name, you can redefine a name, therefore the value a
>>name refers to is mutable.[/color]
>
>
> Since there are mutable and immutable values, it might be clearer to
> say "the binding of a name to a value can be changed". Yes?
>
> In that case, I don't see why someone who wants such a binding to be
> unchanging can't simply avoid changing it. Where's the case for having
> Python enforce this?
>[/color]

The problem is not about having something constant !
The main point with symbols is to get human-readable values.
Let say you have a symbol "opened" and a symbol "closed". The state of a
file may be one of the two.

If you have these symbols, you can ask for the state at any point and
get something readable. If you use constants valued, typically, to
integers, the state of your file will we 0 or 1, which does not mean
anything.

Now, if you're using an object with more than two states, and moreover
if the number of states is likely to increase during developpement, it's
much more convenient to directly get the *meaning* of the value rather
than the value itself (which does not mean anything).

The key point that, I think, you misunderstand is that symbols are not
*variables* they are *values*.
[color=blue]
>[color=green]
>>Conversely consider "NAME" to be a symbol. I can't modify "NAME". It
>>always means the same as "NAME" and "NAME", but is never the same as
>>"FRED". What's tricky is I can't have namespaceOne."N AME" [1] and
>>namespaceTwo. "NAME" as different "NAME"s even though logically
>>there's no reason I couldn't treat "NAME" differently inside each.[/color]
>
>
> So you want to mark such objects as being in a namespace, where they
> compare the same within that namespace but not outside. Why is
> separate syntax necessary for this? A data type that is informed of
> its "space", and refuses comparison with values from other spaces,
> would suffice.
>
> class Xenophobe(objec t):
> def __init__(self, space, value):
> self.__space = space
> self.__value = value
>
> def __str__(self):
> return str(self.__valu e)
>
> def __cmp__(self, other):
> if not isinstance(othe r, Xenophobe):
> raise AssertionError, \
> "Can only compare Xenophobes to each other"
> if not other.__space == self.__space:
> raise AssertionError, \
> "Can only compare Xenophobes from the same space"
> return cmp(self.__valu e, other.__value)
>
> With the bonus that you could pass such values around between
> different names, and they'd *still* compare, or not, as you choose
> when you first create them.
>
> Replace the AssertionError with some appropriate return value, if you
> want such comparisons to succeed.
>[/color]

Well, I think a new syntax will promote the use of symbols. And as I
think they are good practice (much better than meaningless constants)
they should be promoted. Needless to say that in every language I know
implementing symbols (or something close to symbols), there is an
easy-to-use syntax associated.
[color=blue]
>[color=green]
>>However it might be useful to note that these two values (or
>>symbols) are actually different, even if you remove their
>>namespaces.[/color]
>
>
> The above Xenophobe implementation creates objects that know their
> "space" forever.
>
>[color=green]
>>To me, the use of a symbol implies a desire for a constant, and then
>>to only use that constant rather than the value. In certain
>>situations it's the fact that constant A is not the same as constant
>>B that's important (eg modelling state machines).[/color]
>
>
> Since the actual value can't be easily accessed, the only purpose of a
> Xenophobe is too be created and compared to others.
>
>[color=green]
>>Often you can use strings for that sort of thing, but unfortunately
>>even python's strings can't be used as symbols that are always the
>>same thing in all ways. For example, we can force the id of
>>identical strings to be different:[/color]
>
>
> Hold up -- what in your stated use case requires *identity* to be the
> same? You said you just wanted to compare them to each other.
>
> Besides, Python *does* preserve identity for short strings...
>
>[color=green][color=darkred]
>>>>>s = "h"*10000
>>>>>x = "h"*10000
>>>>>id(s), id(x)[/color]
>>
>>(135049832, 135059864)[/color]
>
>
> ... which is sufficient for unique values, if you're not actively
> fighting the system as above. If the use case is for brief, identical
> values, we have those: short strings.[/color]

Well, one *big* difference between short string and symbols is that the
identity between short strings are implementation dependant, while
between symbols it has to be in all implementations as you will rely on
this identity. Then, once more, strings are just one possible
implementation for symbols and I wouldn't like to tie that much symbols
to strings.
[color=blue][color=green]
>>As a result I can see that *IF* you really want this kind of symbol,
>>rather than the various other kinds people have discussed in the
>>thread, that some special syntax (like u'hello' for unicode 'hello')
>>could be useful.[/color]
>
>
> I can see the case for a new type. I disagree that syntax changes are
> necessary.
>[/color]

Well, syntactic sugar is all about what you want to promote or
discourage ... it is never necessary, even if it can really be usefull.
[color=blue]
>[color=green]
>>However, I'd be more interested in some real world usecases where
>>this would be beneficial, and then seeing what sort of syntax would
>>be nice/useful (Especially since I can think of some uses where it
>>would be nice).[/color]
>
>
> Real use cases would interest me, too, but *only* if they can't be
> satisfied with a new type that knows things about its creation state,
> such as Xenophobe.
>[/color]

Well, once more, new syntax for new objects never solve new problems,
they just make them easier to write.
[color=blue]
>[color=green]
>>The reason I'm more interested in seeing usecases, is because I'd
>>rather see where the existing approaches people use/define symbols
>>has caused the OP problems to the extent he feels the language needs
>>to change to fix these real world problems.[/color]
>
>
> Ditto.
>[/color]

Pierre

[Rocco Moretti]

Re: Proposal for adding symbols within Python

Pierre Barbier de Reuille wrote:[color=blue]
> Please, note that I am entirely open for every points on this proposal
> (which I do not dare yet to call PEP).[/color]

I still don't see why you can't just use strings. The only two issues I
see you might have with them are a) two identical strings might not be
identical by id(), b) they aren't local in scope.

The objection a) is minor. One, all of your examples use equality for
testing already, and two, short strings are interned and identical in
most cases anyway (they only differ if you go to lengths to create
them, or they aren't sufficiently "variable like") - at most you would
have to standardize the rules.

The objection b) is a little harder to dismiss. But I'm not sure if
you've completely thought what it means for a symbol to be "local to a
module". What happens when you assign a variable containing a symbol to
a variable in another module? For that matter, what does it mean to be
"in a module". Which module is a class instance (and associated sybols)
"in" if the class is defined in one module, instantiated in another, and
then passed as a return value to a third? What about from ... imports?
If you need a symbol "from another class" what's the mechanism of
obtaining it? Can you import symbols? Since you advocate storing symbols
internally as integers, I suppose you would have a program-global table
to keep symbols from different modules from having the same internal
representation. How do you pickle a symbol and have it go to a different
Python program, which may have a massive symbol table of it's own?


It's been said before, and I'll say it again - the key to successful
Python language changes is compelling use cases. Find an existing Python
program or library (the stdlib is best) which would be markedly improved
by your language change. Not only will Guido be more likely to be
convinced, but what you're proposing will likely be clearer to everyone
else, if it's grounded in practical use cases.

[Reinhold Birkenfeld]

Re: Proposal for adding symbols within Python

Rocco Moretti wrote:[color=blue]
> Pierre Barbier de Reuille wrote:[color=green]
>> Please, note that I am entirely open for every points on this proposal
>> (which I do not dare yet to call PEP).[/color]
>
> I still don't see why you can't just use strings.[/color]

As does Guido.

Reinhold

[Ben Finney]

Re: Proposal for adding symbols within Python

Pierre Barbier de Reuille <pierre_dot_bar bier@_nospam_ci rad.fr> wrote:[color=blue]
> The problem is not about having something constant !
> The main point with symbols is to get human-readable values.
> Let say you have a symbol "opened" and a symbol "closed". The state
> of a file may be one of the two.[/color]

from some_enum_modul e import Enum

FileState = Enum('open', 'closed')

input_file.stat e = FileState.close d
[color=blue]
> If you have these symbols, you can ask for the state at any point
> and get something readable. If you use constants valued, typically,
> to integers, the state of your file will we 0 or 1, which does not
> mean anything.[/color]

str(input_file. state) # -> 'closed'
[color=blue]
> Now, if you're using an object with more than two states, and
> moreover if the number of states is likely to increase during
> developpement, it's much more convenient to directly get the
> *meaning* of the value rather than the value itself (which does not
> mean anything).[/color]

PixelColour = Enum('red', 'green', 'blue', 'black')
[color=blue]
> The key point that, I think, you misunderstand is that symbols are
> not *variables* they are *values*.[/color]

So far, I see nothing that requires anything but a special object type
with the behaviour you describe. Which most of the enumerated-type
implementations do quite neatly.
[color=blue]
> Well, once more, new syntax for new objects never solve new
> problems, they just make them easier to write.[/color]

If you want to promote something, it would be best to implement it and
demonstrate some problems that it solves. You don't seem to be arguing
against a new object type, so perhaps it would be best to simply start
using that type to solve some actual problems.

Since "promotion" is the only argument you've given for new syntax
for this concept, I don't see what is served talking about creating
syntax for something that does not yet exist to be promoted. Once an
implementation exists for examination and is actually useful to some
amount of users for solving actual problems, that's the time to talk
about promoting it.

--
\ "I went to the cinema, it said 'Adults: $5.00, Children $2.50'. |
`\ So I said 'Give me two boys and a girl.'" -- Steven Wright |
_o__) |
Ben Finney

[Steven D'Aprano]

Re: Proposal for adding symbols within Python

On Mon, 14 Nov 2005 17:15:04 +0100, Pierre Barbier de Reuille wrote:
[color=blue]
> The problem is not about having something constant !
> The main point with symbols is to get human-readable values.
> Let say you have a symbol "opened" and a symbol "closed". The state of a
> file may be one of the two.
>
> If you have these symbols, you can ask for the state at any point and
> get something readable. If you use constants valued, typically, to
> integers, the state of your file will we 0 or 1, which does not mean
> anything.[/color]

???

Why does the byte string "\x6f\x70\x65\x 6e\x65\x64" have intrinsic meaning
when the int 0 doesn't? It certainly doesn't mean anything to non-English
speakers.

If all you want is human readable byte strings, then just use them:

class MyFile:
def open(self):
self.state = "opened"
def close(self):
self.state = "closed"


You don't need special syntax to use strings as symbols, you get them for
free without all the overhead you are proposing.

[color=blue]
> Now, if you're using an object with more than two states, and moreover
> if the number of states is likely to increase during developpement, it's
> much more convenient to directly get the *meaning* of the value rather
> than the value itself (which does not mean anything).[/color]

How do you expect this to work in practice? You have an object which
has states:

obj = SomeThingComple x()

Now you want to operate on it according to the state. What do you do?

if obj.state is $closed$:
obj.open()
elif obj.state is $opened$:
obj.close()
elif obj.state is $full$:
obj.make_empty( )
elif obj.state is $empty$:
obj.make_full()
else:
# some other symbol
raise ValueError("Une xpected state %s") % obj.state

Replace "is" with "==" and $ with " and you have strings. You still need
to know what the object state is, and the way you do that is by comparing
it to something. Whether you call that something a symbol, an enum, a
string, an int, a class, whatever, the comparison still needs to be done.

[color=blue]
> The key point that, I think, you misunderstand is that symbols are not
> *variables* they are *values*.[/color]

Python doesn't have variables. It has names and objects.

[color=blue]
> Well, I think a new syntax will promote the use of symbols. And as I
> think they are good practice (much better than meaningless constants)
> they should be promoted. Needless to say that in every language I know
> implementing symbols (or something close to symbols), there is an
> easy-to-use syntax associated.[/color]

Why is $closed$ better practice than "closed"?

Why is "closed" a meaningless constant and $closed$ a good symbol?

[color=blue]
> Well, one *big* difference between short string and symbols is that the
> identity between short strings are implementation dependant,[/color]

Then don't use identity. Who cares whether the state you are testing
against points to the same chunk of memory or not? What possible
difference will that make, except some unnecessary optimization
_possibly_ saving you one millionth of a second at runtime?
[color=blue]
> while
> between symbols it has to be in all implementations as you will rely on
> this identity. Then, once more, strings are just one possible
> implementation for symbols and I wouldn't like to tie that much symbols
> to strings.[/color]

And ints are another possible implementation for symbols, or classes, or
enums.

obj.state = 42 is not an ideal implementation, because it is not
self-documenting, and self-documenting code is good code. But in some
contexts, it may be the right thing to do:

class MutablePolygon:
"""Define a polygon object that can grow or lose sides."""
def __init__(self, n):
"""Create a new polygon with n sides."""
self.state = n
def grow_side(self) :
self.state += 1
def lose_side(self) :
self.state -= 1

Compare that with something like this:

class MutablePolygon:
"""Define a polygon object that can grow or lose sides."""
def __init__(self, n):
"""Create a new polygon with n sides."""
if n == 1:
self.state = $one$
elif n == 2:
self.state = $two$
elif n == 3:
self.state = $three$
elif n ...


--
Steven.

[Grant Edwards]

Re: Proposal for adding symbols within Python

On 2005-11-14, Rocco Moretti <roccomoretti@h otpop.com> wrote:[color=blue]
>[color=green]
>> Please, note that I am entirely open for every points on this proposal
>> (which I do not dare yet to call PEP).[/color]
>
> I still don't see why you can't just use strings.[/color]

Same here. In the situations described, I always use strings
and have never felt the need for something else:

file.state = 'closed'

...

if file.state == 'open':
whatever
elif file.state == 'error':
something_else

[color=blue]
> The only two issues I see you might have with them are a) two
> identical strings might not be identical by id(), b) they
> aren't local in scope.
>
> The objection a) is minor.[/color]
[...][color=blue]
>
> The objection b) is a little harder to dismiss. But I'm not
> sure if you've completely thought what it means for a symbol
> to be "local to a module".[/color]

I don't think I even understand what the objection is. What is
needed is a code fragment that shows how the use of strings is
untenable.

--
Grant Edwards grante Yow! And furthermore,
at my bowling average is
visi.com unimpeachable!! !

[Björn Lindström]

Re: Proposal for adding symbols within Python

Steven D'Aprano <steve@REMOVETH IScyber.com.au> writes:
[color=blue]
> Why does the byte string "\x6f\x70\x65\x 6e\x65\x64" have intrinsic
> meaning when the int 0 doesn't? It certainly doesn't mean anything to
> non-English speakers.
>
> If all you want is human readable byte strings, then just use them:
>
> class MyFile:
> def open(self):
> self.state = "opened"
> def close(self):
> self.state = "closed"[/color]

So, I guess no one read my explanation of why this an issue about more
than implementing enums (which is fairly trivial, as we have seen).

--
Björn Lindström <bkhl@stp.lingf il.uu.se>
Student of computational linguistics, Uppsala University, Sweden