On 19/04/2015 13:59, Ben Finney wrote:
BartC <b...@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
--
https://mail.python.org/mailman/listinfo/python-list
