Xython - XML-Formed Python

[Steve Horne]

On 4 Feb 2002 01:42:33 -0800, alanmk at hotmail.com (Alan Kennedy) wrote:

>Gerard Braad <g_braad at survion.com> wrote:
>> Any help would be appreciated. We hope this will become a standard for
>> inclusion of Python in XML documents.
>
>Gerard,
>
>I don't understand what's wrong with
>
><script language="python" xml:space="preserve">
>    def messiah():
>        print "He's NOT the Messiah."
>        print "He's a very naughty boy."
></script>
>
>or something similar.
>
>Alan.
>
>P.S. It's from "The Life of Brian", in case you're wondering.

This solves one problem - a simple embedding of Python in XML.

I haven't looked at their site, but XML (using tags for structures,
statements etc) may have considerable benefits over plain text as a
source code representation - the only problem being the need for good
XML editors...

One major advantage is the possibility that source code could be more
concerned with semantics, and the presentation could be an issue for
the editor. No more arguments about indentation against braces - tell
the dissenters to simply configure their editor to work with braces
instead of (or as well as) indentation. With a sufficiently
sophisticated editor, the syntax of the language becomes 'skinnable'.

Another advantage is that identifiers inherently occupy a different
namespace to tag names (ie keywords), so the issue of adding new
keywords becomes a complete non-issue. Odds are there would be a
simple <id name="xxx" /> tag for identifiers, editors would make the
keyword/identifier issue clear using colour or style, and conflicts
between identifiers and keywords would simply be impossible.

Another advantage - issues where the semantics of certain syntax have
changed become a non-issue. An example would be the division operators
semantic change. Whether a tag is represented in the editor using a
function or an operator, in addition to the actual symbol used, could
be configurable. Simply create additional division tags for the new
semantics (keeping the old ones) and let people reconfigure their
editors to use the syntax they want for the semantics they want.

Of course, all of this is technically possible now - you'd simply need
an editor capable of translating Python syntax to/from a user
configurable presentation - but working from an XML based language
would be much more practical.

BTW - this isn't the first time this idea has been proposed.

-- 
Steve Horne
steve at lurking.demon.co.uk