[Python-3000] symbols?

[Guido van Rossum]

> Kendall Clark wrote:
> > I don't know if the Ruby syntax for symbols, :foo, will work in
> > Python (though I think visually it's a good thing), but it would be
> > really nice to have symbols with *some* syntax in Python 3000.
> >
> > Again, this design request is based on aesthetics and fun: having
> > symbols would make Python more fun.

I don't see how this particular feature adds more fun; I'd rather see
it argued on the basis of use cases.

The aesthetics of the earlier proposal to use :foo to indicate symbols
are poor; using random punctuation is unpythonic (as is the use of ?
or ! in identifiers BTW) but more importantly there are a few
syntactic positions where it would be ambiguous, e.g. foo[:bar]
already means foo[0:(bar)].

I'd also like to point out (again?) that the "const-ness" of ALLCAPS
is a red herring; in practice, we treat almost all imported names as
constants, and in fact class and function names are generally
considered constant. (I've also seen plenty of code that used ALLCAPS
to indicate "configuration parameter" rather than "constant" and which
freely assigned to ALLCAPS variables in configuration code.)

Then, on 4/14/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
[...]
class C:
  x = property("_get_x", "_set_x", "_del_x",
               "This is the x property")
[...]

(BTW I thought I implemented this but can't find any evidence.)

> However, if a leading dot in an expression simply indicated "this is a string
> that is also a legal Python identifier", the above could be written:
[...]
class C:
  x = property(._get_x, ._set_x, ._del_x,
               "This is the x property")
[...]

This is slightly more Pythonic, and unambiguous, but I'd rather
reserve leading dot for a more powerful feature, perhaps .foo as an
abbreviation for self.foo, or some other scope-ish operator. (I also
note that in a proportional font the . is easily missed.)

> By using a separate syntax, you get the following benefits:
>    1. It makes the code easier to write as it's not a bracketed syntax and if
> your keyboard makes '.' inconvenient writing Python code would already be hellish
>    2. It lets the reader know that these values are identifiers rather than
> arbitrary strings
>    3. It also lets the compiler know to enforce the rules for identifiers
> rather than the rules for strings (which are far more lax)

I'm not sure (1) weighs much but I buy (2) and some of (3), so perhaps
we ought to think of some other prefix character (or overcome my
objection to '.').

Somewhat unrelated: there's one advantage to enums (which have been
suggested as an alternative to symbols) which symbols don't share: if
you have a typo in an enum name, you presumably get an early, hard
NameError or AttributeError (and pychecker could easily check this);
but if you misspell a symbol, you just pass a different symbol, which
is likely to trigger a later error or no error at all (depending on
how the symbol is used). Of course, enums really serve a different use
case; they wouldn't help at all for the property-defining use case
Nick described here.

> Easier to write, easier to read and better error checking adds up to a big win
> in my book :)

Is that also my book? :-)

> Add in the method syntax idea from the thread about method definitions, and
> you get the final result:
>
> class C:
>    x = property(._get_x, ._set_x, ._del_x,
>                 "This is the x property")
>
>    def self._get_x():
>        # Retrieve x

Oh, but I don't like this at all. Anyway, it's pretty much unrelated
to the other idea.

>    x.attr      <=>  getattr(x, .attr)     <=>  getattr(x, 'attr')
>    x.attr = y  <=>  setattr(x, .attr, y)  <=>  setattr(x, 'attr', y)
>    del x.attr  <=>  delattr(x, .attr)     <=>  delattr(x, 'attr')

So this begs the question: would the following assertion pass or fail?

    assert .foo == "foo"

What about this one?

    assert type(.foo) == str

(I'm just trying to probe for implementation details of the proposal;
I'm something like -0 on the whole idea.)

--
--Guido van Rossum (home page: http://www.python.org/~guido/)