[Python-3000] symbols?

[Nick Coghlan]

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'd like to link a few threads together here. . .

Guido proposed a while back on python-dev to support the idea of overridable 
properties - properties that were implemented in terms of other methods of the 
class, and were looked up when the property was invoked rather than when it 
was defined. Something like:

class C:
   x = property("_get_x", "_set_x", "_del_x",
                "This is the x property")

   def _get_x(self):
       # Retrieve x

   def _set_x(self):
       # Set x

   def _del_x(self):
       # Delete x


This is a PITA to type (particularly if programming in C has ingrained in you 
the habit of using double-quotes for strings) and isn't all that easy to read, 
either. What objections there were at the time seemed to stem mostly from 
aesthetics - the strings for attribute names in the call to property() are 
just plain ugly.

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")

   def _get_x(self):
       # Retrieve x

   def _set_x(self):
       # Set x

   def _del_x(self):
       # Delete x

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)

Easier to write, easier to read and better error checking adds up to a big win 
in 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

   def self._set_x():
       # Set x

   def self._del_x():
       # Delete x

YMMV, but that's a property declaration syntax I could definitely live with - 
it makes it clear that the first three arguments passed to property are Python 
identifiers, it makes it easy for subclasses to control some or all of the 
aspects of the way the property is handled, and it doesn't require any 
metaclass magic or new statements like 'make'.

This meaning for a leading dot also aligns well with normal attribute access:

   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')

Cheers,
Nick.

P.S. I did try this with a real object in front of the dot with a 
__getattribute__ that simply returns an interned string of the attribute name. 
This just ended up being confusing because the symbol definition looks too 
much like normal attribute access.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org