New to Python - block grouping (spaces)

[Dave Angel]

On 04/19/2015 07:38 AM, BartC wrote:
....
> Perhaps you don't understand what I'm getting at.
>
> 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?
>
> A can write code in the preferred syntax, and B can view/modify exactly
> the same code in /their/ preferred syntax. What would be the problem?
> (The actual stored representation of the program would be in one of
> those two styles, or something else entirely; Lisp-like syntax for
> example. It doesn't matter because no-one would care.
>
> (I think much of the problem that most languages are intimately
> associated with their specific syntax, so that people can't see past it
> to what the code is actually saying. a=b, a:=b, b=>a, (setf a b),
> whatever the syntax is, who cares? We just want to do an assignment!)
>

If you make enough simplifying assumptions, of course it's easy and natural.

Assume that a text editor is the only way you'll be viewing the source 
code.  You and your coworkers are willing to each use a prescribed text 
editor, rather than your previous favorite one that doesn't happen to 
support the customization you're suggesting here.  You're not going to 
use a version control system, nor diff programs.  You're not going to 
post your code in messages on the internet.

You're not going to display error messages showing source code, from a 
running system.  You're not going to use the interactive debugger.

You're not going to copy code from one place to another without copying 
sufficient context to be able to reconstruct the funny syntax.

You're going to permit only one such variation, and it's just big enough 
that it's always obvious which version of the code is being examined (by 
programs or by humans) [1]

You're not going to use eval()  [good].  You're not going to examine 
source code that comes from 3rd party or the standard library.

The changes you want are all completely reversible, regardless of 
interspersed comments, and when reversed, preserve spacing and 
characters completely in the way that each user expects to see the code. 
  And they are reversible even if you only have a small fragment of the 
code.

I implemented something analogous to such a system 40 years ago.  But on 
that system, nearly all of the restrictions above applied.  There was no 
clipboard, no version control, no internet.  Programs had to fit in 64k. 
Each line stood completely on its own, so context was not a problem.  i 
wrote the text editor, much of the interactive debugger, the listing 
utility, the pretty printer, the cross reference program, etc.  So they 
were consistent.  Further, we had a captive audience -- if they didn't 
like it, they could buy the competitor's product, which had similar 
constraints.  Would I do things differently now?  You bet I would.  At 
least if I could upgrade the memory addressability to a few megs.


For the purposes you've described so far, I'd suggest just writing two 
translators, one a mirror image of the other.  Invoke them automatically 
on load and save in your personal editor  And learn to live with both 
syntaxes, because it will leak.  And if it's really not reversible, 
don't use them when you're editing somebody else's code.  And even if it 
is reversible, don't use them when you edit code you plan to post on the 
internet.

[1] So for example  a=b can not mean assignment in one version, and a 
comparison in the other.  Because then you'd need to either discover 
that it's a line by itself, or within an if expression, or ...  But you 
could arrange two disjoint sets of symbols readily enough.  In your 
version, require either := or ==, and make = just plain illegal.

PS.  I haven't examined the costs in tool development to support this. 
Just whether it's practical.  You can easily discount any one of these 
constraints, but taken as a whole, they very much limit what you can do.

-- 
DaveA