xml <-> python Re: pre-PEP: The create statement

[Azolex]

Steven Bethard wrote:
...
> 
> Optional Extensions
> ===================
> 
> Remove the create keyword
> -------------------------
> 
> It might be possible to remove the create keyword so that such
> statements would begin with the callable being called, e.g.:
> 
>     module mod:
>         def f1():
>             ...
>         def f2():
>             ...
> 
>     interface C(...):

as someone else noted, this is not the ideal example

>         ...
> 
> However, this would probably add some complexity in the grammar and
> so far I (Steven Bethard) have not been able to implement the feature
> without the keyword.

Well, I can't pronounce myself on the technical difficulties, but I'd 
like to point out that the proposal of the pep (especially without 
keyword I'd say) offers part of what would be needed to endow python 
with a standard bidirectional source-to-source transform to/fro xml. But 
it might as well miss the opportunity...

I feel the python grammar offers more readable solutions (or 
near-solutions) to the problems solved by the cumbersome grammar of xml. 
So whenever I need to work with xml source or templates, I dream of a 
reversible transformer that would allow me to work with a transparent 
"mock-python" rendering of my xml file - it would replace closing tags 
with indentations, attributes with keyword parameters syntax, cdatas 
with triple quotes and perhaps xmlns with import statements - doing away 
with all the unnecessary <xml/> cruft.

Symmetrically, I feel a (family of) standard xml rendition(s) of python 
source would be quite useful. For one, it would facilitate access of 
python source to vehicles designed for xml. For two, it would provide 
python with an equivalent to lisp s-expression syntax. To illustrate : 
imagine processing python source code using xslt over an xml 
representation of python source with the relevant xslt itself expressed 
in transparent python source.

So what I'd ideally want (and also to attract "foreign" programmers to 
python) is to modify python syntax and semantics conservatively to eg 
"xpython" that would make the following possible :

(a) given arbitrary "xpython" source code, there is a clearly obvious 
way to express in xml a superficial parse of the code (ie a parse of 
statement-level syntax).

(b) given arbitrary xml, there is a clearly obvious way to transform it 
to mimetic "xpython" source code.

(c) the transforms are mutual inverses.

(d) running any "xpython" obtained from arbitrary xml will reconstruct 
the original xml.

Similar wish, anyone ?

As relates to the pre-pep :

+1 for adding this general style of statement,

-0.5 on requiring a keyword,

-1 on choosing a *verb* keyword that forces to the imperative 
interpretation of the code (since I'd want "xpython" to function as well 
as a declarative language equivalent to xml)

-0.8 on the parameter syntax that restricts to positional parameters 
while leaving out keyword arguments

Cheers.