Idea: Python Shorthand (was Re: Why a class when there will only be one instance?

[Ville Vainio]

>>>>> "Ryan" == Ryan Paul <segphault at sbcglobal.net> writes:

    Ryan> the line. It's a good OO strategy. I do understand your
    Ryan> dislike of 'self'.  It does seem like clutter. In my code, I
    Ryan> shorten it to 's'. In ruby, class variables are prefixed
    Ryan> with an '@', which makes them easier to discern in code, and
    Ryan> it is easier than typing 'self'. I wish python had something

Prefixing names with symbols like $ and @ is a great idea - it makes
the "nouns" (variables) stand out from "verbs", and makes the code
flow like a natural language, making reading it easy and writing it
fun!

On a more serious note, you could consider creating a binding for @
that inserts "self.". @ is almost never used in Python, so it should
be pretty safe.

    Ryan> like that. I also think that having to specify the class
    Ryan> variable in every function definition is a bit silly. Ruby
    Ryan> gets rid of that too.

You might want to create a preprocessor that adds "self" to all
in-class definitions that have @, and convert @hei to self.hei. Voila,
Ruby non-silliness.

The idea could be extended to provide a "Python shorthand", which
would expand to full-blown Python:

d hello x y:  -> def hello(x,y):


c hello baseclass:
  d init arg1 arg2:   # expand to __init__
    .x = arg1
    .y = arg2
  d sayhi:
    p "hi!"
    .x = 555



o = hello 12 13

p o.x + o.y # prints 25

o.sayhi

p o.x   # prints 555


Actually, while this would make zero sense for language-as-such, it
might turn out to be a fun way to hammer out that first ultra-rapid
prototype. At the moment something comes up that needs the
explicitness of Python (say, after 45 minutes of hacking), the
shorthand can be expanded to Python (optimally with M-x
py-expand-shorthand).

I find that I write Python code quite fast already, but some phases of
the coding process (esp. the implementation of classes) could be
further accelerated by this shorthand, mostly due to alleviating the
need to use the shift-key. ":" should still be there to enable the use
of python-mode.el.

The implementation of the shorthand could be pretty ad-hoc, with
possibly ambigous grammar. The shorthand would never be shipped
unexpanded anyway.

-- 
Ville Vainio   http://tinyurl.com/2prnb