> 'S funny --- my non-programmer friends can't figure out why any sane
> person would use a glorified glass TTY like emacs... or why they should
> have to, just to program... I just think that someone's going to do this
> for some language, some time soon, and I'd rather Python be in the lead
> than play catch-up.
But the scheme you put forth causes major problems for current Python users
who *are* using glass TTYs, so I don't think it'll fly for very basic
political reasons nicely illustrated by Dave-the-diplomat's response.
While storage of Python files in XML documents is a good thing, it's hard to
see why XML should be viewed as the only storage format for Python files. I
think a much richer XML schema could be useful in some distant future:
<class name="Foo">
<method name="Foo">
<argumentlist>
<argument name="self">
...
What might be more useful in the short them IMO is to define a _standard_
mechanism for Python-in-XML encoding/decoding, so that all code which
encodes Python in XML is done the same way, and so that XML editors can
figure out once and for all how to decode Python-in-CDATA.
Strawman Encoding # 1:
replace < with < and > with > when not in strings, and vice versa on
the decoding side.
Strawman Encoding # 2:
- do Strawman 1, AND
- replace space-determined indentation with { and } tokens or other INDENT
and DEDENT markers using some rare Unicode characters to work around
inevitable bugs in whitespace handling of XML processors.
--david
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4