Proposal for adding symbols within Python

[Michael]

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

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."NAME" [1] and
namespaceTwo."NAME" 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:
>>> s = "h"*10000
>>> x = "h"*10000
>>> id(s), id(x)
(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.