New to Python - block grouping (spaces)

[BartC]

On 19/04/2015 13:59, Ben Finney wrote:
> BartC <bc at freeuk.com> writes:
>
>> 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?
>
> I don't recall anyone saying that *shouldn't* be done. Feel free to
> make, and maintain and support and propagate and keep pace with changes
> in everything Python interacts with, a full Python stack that supports
> such flexibility.
>
>> 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?
>
> I can only invite you to embark on the project of a Python compiler
> which accepts such a switchable syntax, maintain it consistently over
> the lifetime of a project with significant numbers of people
> collaborating using different switch settings for that syntax, and
> working on the same code with different editor settings.
>
> Once you've done that, report back to us about the problems encountered.
>
>> (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.
>
> No-one except the people who have to maintain and debug and continue
> developing a Python that supports multiple radically-different syntaxes.
> I suspect the efforts of those people is being discounted in your vision.

I used actual languages Python and C in my example, I should have used A 
and B or something.

If this was actually Python, then clearly source must be stored in 
Python syntax, to get around some of the objections that have been 
raised. Then all existing tools will work as before.

But it means an editor would need to understand Python extremely well in 
order to do the 2-way transformation I was suggesting. And while that 
would need maintaining, I don't think it's impossible (don't smart 
editors already understand a lot of the syntax? And if I was doing this, 
I would use a conventional editor, and an separate translator). But it 
would all be optional; everything would then still work as before.

However, I have played around with an actual project along these lines, 
but with some differences. Let's call actual Python source ".PY", and my 
preferred syntax ".JPY" (since those were the file extensions I used; 
"J" was the name I used to designate my syntax - syntax, not language, 
as the language must still be Python).

Here, the intention was to store source code in .JPY files, with .PY 
used as an intermediate form when I need to use an existing Python tool. 
So the translation was one-way (which suited me because I tend to do my 
own thing).

There are a few issues: I can still import .PY files created by others, 
but if it's one of mine created as .JPY, it just means it needs 
translating before running Python. Things such as eval() that have been 
mentioned, I haven't attempted. (Probably, it would be written as 
jeval() and would need to invoke the translator on the string, the 
results of which are passed to eval(). You can get around most such 
problems.)

So I'm aware of some of the things that are involved.

(BTW that project worked reasonably well, but I decided to go in a 
different direction: turning "J" from a mere syntax into an actual 
language of its own.)

-- 
Bartc