[Python-ideas] An Alternate Suite Delineation Syntax For Python? (was Re: [Python-Dev] [PATCH] Adding braces to __future__)

[Mike Meyer]

On Sat, 10 Dec 2011 15:06:13 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> An Alternate Suite Delineation Syntax For Python?
> =================================================
>
> However, this benefit comes at quite a high price: it is effectively
> impossible to embed arbitrary Python statements into any environment
> where leading whitespace is *not* significant, including Python's own
> expression syntax.

Since you sent it to Python-ideas, I'm going to assume you were at
least semi-serious. So let me add the use case I came up with while
reading the original post, also often seen in template languages:

    Writing code to generate python.

With significant whitespace, you have to keep explicit track of the
current nesting level in order to generate the appropriate
indent. With real delimiters, you can drop that. Compare:

    def generate(self):
        yield '{keyword} {expr}{:'.format(keyword=self.name,
                                         expr=self.expresion)
        for s in self.suite:
	    for l in s.generate():
	        yield l

With:

    def generate(self, level):
        yield '{0}{keyword} {expr}:'.format(' ' * level,
                                            keyword=self.name,
                                            expr=self.expresion)
        for s in self.suite:
       	    for l in s.generate(level + 1):
	    	yield l


A minor improvement in just that one method, but it will show up in
every generate method of every class, making it significant in total.

> Applying the excellent set of criteria suggested by Mike Meyer:

"Suggested" may be a bit to much credit. I've observed the community
applying these criteria to pretty much every idea. Some ideas get
adopted in spite of failing one or more of them, but a *lot* of ideas
get dropped after failing one of them.

In this case:

1. What's the use case?

Writing code that's going to write python code.

> 2. Does it make such code more readable?

It makes the code generating code less complicated, which means more
readable.

> 3. Does it encourage writing unreadable code? Perhaps. You certainly
> end up with a lot of braces, colons and semi-colons floating around.
> However, that's also something that can be addressed by style guides -
> if people are using the embedded syntax when the indented syntax would
> work fine, the problem isn't really due to the embedded syntax, it's
> due to people not caring about maintainability.

I think not. As someone else observed, Haskell has both options
available - and the rules for the indented version are a lot less
straightforward than they are in Python (at least I haven't seen as
clean a statement of them). About the only use of the delimited
version in real code is turning a short suite into a one-line suite.

    <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org