New to Python - block grouping (spaces)

[Chris Angelico]

On Sun, Apr 19, 2015 at 9:38 PM, BartC <bc at 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!