Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <7tMYw.252071$SO1.39320@fx43.am4>
References: <9fc57fc9-0399-4ff3-882a-d041f02827d8@googlegroups.com> <6580b5d5-92f5-4bfa-b1d0-889c69fe82bb@googlegroups.com> <mailman.374.1429285961.12925.python-list@python.org> <mgrcb5$sn2$1@reader1.panix.com> <Y3bYw.302660$ms.24839@fx30.am4> <mailman.388.1429323788.12925.python-list@python.org> <7tMYw.252071$SO1.39320@fx43.am4>
Date: Mon, 20 Apr 2015 01:15:08 +1000
Subject: Re: New to Python - block grouping (spaces)
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.405.1429456511.12925.python-list@python.org>
Lines: 43
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:89157

On Sun, Apr 19, 2015 at 9:38 PM, BartC <bc@freeuk.com> wrote:
> Suppose there were just two syntaxes: C-like and Python-like (we'll put
> aside for a minute the question of what format is used to store Python
> source code).
>
> Why shouldn't A configure his editor to display a Python program in C-like
> syntax, and B configure their editor to use Python-like tabbed syntax?

You still haven't addressed the question of the extent of "C-like
syntax" for Python. It's not simply a matter of block delimiters. With
git (and I believe similarly with hg, but I'm not sure about smaller
and/or proprietary source control systems), you can define a pair of
filters which transform a file between the actual source control
system and your checked-out version, so (for instance) you could have
source control work with four-space indents where you work with tab
indents. That one's dead easy. With a little more work, you could
probably rig something up to use keywords or symbols to delimit blocks
of code; braces would be harder, because Python uses them for dicts
and sets, so you'd need some sort of context-aware parsing.

But the biggest problem is that you wouldn't actually be changing
anything else. You'd end up with a bizarre hybrid that uses a tiny bit
of C-like syntax, but entirely Python-like syntax everywhere else. For
example, Python doesn't allow this:

if condition: for i in range(3): do_stuff()

So you'd never truly be able to take advantage of the braces. In fact,
all you'd _really_ have would be a way to key in some braces, commit
to source control, check out again, and have your indentation
auto-fixed for you... and if that's all you want, I think there are
editors which make the reindenting of code a ton easier than that!

As Dave suggests, make yourself a parser which turns *any* legal[1]
Python code into your preferred "C-like" syntax, and another which
performs a perfect reverse transformation. I suspect you'll find the
task fundamentally hard.

ChrisA

[1] Coping with broken Python code is going to be important later on,
but ignore it for now. It's a ton harder to ensure that you can do a
reversible syntactic change on something with syntax errors!