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. -- http://mail.python.org/mailman/listinfo/python-list
