Proposal for adding symbols within Python

[Rocco Moretti]

Rocco Moretti a écrit :
[...]

I did, but I still don't see why it is an argument against using
strings. The point you may not appreciate is that (C)Python already uses
strings to represent names, as an important part of its introspective
abilities.

Well, I'm well aware of that, but I'm also well aware that's (as you
said yourself) specific to C-Python, so can just *cannot* rely on
strings being used as symbols in the language.

It's true that a different implementation of Python may use a different
internal storage system for names, but as long as the semantics are the
same as CPython, it really doesn't doesn't matter what the internal
storage is. That is to say, as long as the other implementation of
Python has __getattr__ and __dict__, you can use strings to represent
names, regardless of how the interpreter stores them internally.

The point is, why don't provide the programmer to express just what he
needs (that is, some symbolic value like "opened", "blocked", ...) and
let the interpreter use whatever he think is more efficient for him ?

It's just that, for the current interpreters and usage of "symbol-like"
construct, the efficiency gained by the interpreter choosing how to
represent symbols is probably *far* outweighed by the inefficiency and
hassle of implementing and maintaining the symbol syntax in the existing
interpreters.

Besides, "have the programmer specify intent, and allow the interpreter
to substitute a more efficient implementation on the off chance that
interpreter can or wants to" doesn't have much cache in the Python
community.(1) The interpreter could get more efficiency if it knew a
list was fixed length, or contained only ints, or knew that a for loop
was looping over consecutive integers, instead of a random list. But
despite the possibility that there might exist, at some time in the
future, a Python interpreter which *might* optimize such things, we
haven't thrown in variable declarations or integer loop syntaxes yet.

As I've mentioned before, the key to getting feature put into the
language is compelling use cases. Find a (non-hypothetical) Python
program or library which would be improved by addition of <insert your
chosen feature here>, and where the existing alternatives are
inadequate. Lacking that, any attempt to get a feature into the language
is an uphill battle.

But why say a name is a
*string* when it is just an implementation detail ??? Isn't Python
mainly about allowing the programmer to concentrate on important stuff ?

One could flip it around and say that names *not* being strings are an
implementation detail - after all, what is a name in your source code,
besides just a string of ASCII characters? Having just names and strings
simplifies things as well - you have only two items to convert between,
as opposed to three items (names, symbols and strings).

-

(1) The future of Python seems to be towards the PyPy way, where the
interpreter will analyze your code, and automagically determine the most
efficient implementation for your particular use case.

 

[Steven Bethard]

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.

How about using the prefix "symbol." instead of "$"?
symbol.spam(symbol.eggs)

And the definition of symbol that I used:
.... class __metaclass__(type):
.... def __getattr__(cls, name):
.... return symbol(name)
.... def __getattr__(self, name):
.... return symbol('%s.%s' % (self.name, name))
.... def __init__(self, name):
.... self.name = name
.... def __eq__(self, other):
.... return self.name == other.name
.... def __repr__(self):
.... return '%s.%s' % (type(self).__name__, self.name)
.... def __call__(self, *args):
.... arg_str = ', '.join(str(arg) for arg in args)
.... return symbol('%s(%s)' % (self.name, arg_str))
....

It doesn't work with "is", but otherwise I think it's pretty close to
your proposal, syntax-wise. Is there something obvious this won't
address for you?

STeVe

 

[Kay Schluehr]

How about using the prefix "symbol." instead of "$"?

I recognize 3 symbols: a "symbol" a dot and another symbol. So I
wouldn't call this a symbol. Maybe a "diabolon"? Other languages have
symbols, Python has diaboli

Kay