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

[Josh Gilbert]

Ville Vainio wrote:

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

Now that's a great idea! Not the sigils stuff, I switched from Perl to
Python for a reason, I was putting sigils in my English, C, and so on. 

I love the shorthand tho:

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

That seems unambiguous to me and I could see a parser for that language that
would output equivalent Python. It just so happens that there was an
article on slashdot a few minutes ago recommending a similar principle
(http://www.third-bit.com/~gvwilson/xmlprog.html).

The rules of the game: 
*This language must require less typing or be easier to use than Python.
*Each construct must map to an equivalent Python construct unambiguously. 
*We always generate the Python equivalent ASAP and throw out the shorthand.
(You might want sigils, but I don't. Only Python is portable.)

There are two paths, have the IDE convert each line to Python when you hit
'\n' or as a batch. The first method would allow it in Python shells. 

One final thought, it should be added to IPython. I'm not associated with
IPython in any way, but it already supports alternate Python syntax and
generates genuine Python.  
In [6]: range 3
------> range(3)
Out[6]: [0, 1, 2]


This is a very good idea. I wonder how hard it will be. 

        Josh Gilbert