Proposal for new operators to python that add syntactic sugar for hierarcical data.

[glomde]

i I would like to extend python so that you could create hiercical
tree structures (XML, HTML etc) easier and that resulting code would be
more readable than how you write today with packages like elementtree
and xist.
I dont want to replace the packages but the packages could be used with
the
new operators and the resulting IMHO is much more readable.

The syntax i would like is something like the below:

# Example creating html tree

'*!*' is an operator that creates an new node,
'*=*' is an operator that sets an attribute.

So if you take an example to build a smalle web page
and compare with how it looks with in element tree now
and how it would look like when the abover operators would exist.

With element tree package.

# build a tree structure
root = ET.Element("htm l")
head = ET.SubElement(r oot, "head")
title = ET.SubElement(h ead, "title")
title.text = "Page Title"
body = ET.SubElement(r oot, "body")
body.set("bgcol or", "#ffffff")
body.text = "Hello, World!"

With syntactical sugar:

# build a tree structure
root = ET.Element("htm l")
*!*root:
*!*head("head") :
*!*title("title ):
*=*text = "Page Title"
*!*body("body") :
*=*bgcolor = "#ffffff"
*=*text = "Hello, World!"

I think that with the added syntax you get better view of the html
page.
Repeating things dissapears and you get indentation that corresponds to
the tree.
I think it is very pythonic IMHO.

It could be done quite generic. If the variable, object after '*!*'
must support append
method and if you use '*=*' it must support __setitem__

Any comments?

[bruno at modulix]

glomde wrote:

Adding ugly and unintuitive "operators" to try to turn a general purpose
programming language into a half-backed unusable HTML templating
language is of course *much* more pythonic...

IT is not only for HTML. I do think html and xml are the biggest
creators of
hierarcical treestructures.

What is a 'non-hierarchical treestructure' ? A list ?-)

But it would work for any package that
manipulates,
creates hierarchical data.
FWIW, filesystems are trees, most RDBMS use BTrees, and almost any OO
program is a graph of objects - trees being a subset of graphs..

Strange enough, working with trees is nothing new, and it seems that
almost anyone managed to get by without cryptic 'operators' stuff.
I used HTML as example since it is a good
example and
most people would understand the intention.
Sorry for being dumb.
But could you elaborate on your comment that it is unusable.
Ask all the coders that switched from Perl to Python why they did so...
Do you
think all template systems are unusable

Nope - I use template systems everyday.

Please don't take it wrong: there's surely something to do to ease
declarative XML-like (including JSON, Yaml etc...) datastructure
construction. But I think the pythonic way to go would rely on
metaprogramming - not on ugly perlish syntax.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[bruno at modulix]

glomde wrote:

What about writing a mini-language that gets translated to Python? Think of
Cheetah, which does exactly this (albeit not being limited to templating HTML
data).
I have implemented my proposal as preprocessor. And it works fine. But
my
proposal in not only for HTML

Nor is Cheetah. Nor is Django's templating system. Nor are some other
Python templating systems.
it can be used for all hieracical data.
Example:

myList = []
*+* myList:
*+* []:
for i in range(10):
*+* i
*+* {}:
for i in range(10):
*=* i = i
Sweet Lord, have mercy !
Which should create myList = [[0..9], {0:0, ... 9:9}]
myList = [
range(10),
dict((i, i) for i in range(10))
]

Let's talk about readability....
I do think I solve something and make it more
readable.

Lol. Any Perl coder around ?

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[Heiko Wundram]

Am Donnerstag 18 Mai 2006 15:17 schrieb glomde:

> nothing general the OP is trying to achieve here

Define general :-). I do think I solve something and make it more
readable.
You could also argue that list comprehension doesnt solve anything
general.

Sure, a list comprehension solves something general. It's syntactic sugar for
a recurring pattern in a for loop.

What you are trying to achieve is to make syntactic sugar for making namespace
definitions look nicer. But: the way you are trying to do so isn't pythonic,
because there isn't one obvious way how your proposal works; you're not even
specifying a proper semantic interpretation of your syntax (and use "magic"
markers, which is even more a NoNo).

For a better thought out proposal (IMHO) for stacking and defining namespaces
(based on the current metaclass behaviour), look for the PEP on the "make"
keyword (which was sent to Py-Dev some weeks ago).

By the way: the language you (the OP) are trying to implement here goes
strictly against the MVC model of application programming. You know that,
right?

???. I cant see how this breaks MVC. MVC depends on how you parition
your application
this doesnt put any constraint on how you should do your application.

Sure it does.

In case you implement a templating language that simply contains the "full"
power of the Python language, you create a (somewhat) cripled PHP, basically.
The View part of MVC shouldn't do branching (well, in the strict sense of
MVC), shouldn't do looping, shouldn't do modification of the data, all that
stuff is up to the controller.

If you empower the template writer with the full power of the Python
programming language by integrating your proposal with Python itself, you're
bound to water down the split between the three, and to create a maintenance
nightmare (as I said, PHP comes to mind, where you basically can't split
controller from model properly).

For a proper (and pretty strict) MVC templating language, have a look at
Nevow.

--- Heiko.

[glomde]

I'm answering two of you posts here...

Sweet Lord, have mercy !

> Which should create myList = [[0..9], {0:0, ... 9:9}]
myList = [
range(10),
dict((i, i) for i in range(10))
]

Let's talk about readability....
My code was just to show that the proposal is not only for HTML
generation but could be used whenever you want to create COMPLEX
hierarcical datastructures.
In the above example I would of course use what you wrote.

Do I need to show you a example where you cant use the style you
showed?
Strange enough, working with trees is nothing new, and it seems that
almost anyone managed to get by without cryptic 'operators' stuff. Strange enough once almost anyone managed to get by without Python...
:-)

I used HTML as example since it is a good
example and
most people would understand the intention.

Sorry for being dumb.

It not your fault :-)

But could you elaborate on your comment that it is unusable.

Ask all the coders that switched from Perl to Python why they did so...

You seem to really have a thing for Perl...
From what you written I assume you mean that it is no good because you

find the syntax cryptic. For me cryptic is for example how you in Perl
create list of lists, ie
it takes a while to understand and when you havent done in a while
youyou have to relearn it. Python has a few of those aswell... but you
really
only need them when doing something cryptic...

IMO what I propose isnt cryptic, because of
* I think after it has been explained it is no problem to understand
how it works.
* It doesnt have strange sideeffects
* Doesnt break any old code.
* You dont have to relearn if you havent done it a while.

Also if you never would have seen such code before, I think you would
understand
what is meant and even be able to modify it.

[glomde]

> What you are trying to achieve is to make syntactic sugar for making namespace

definitions look nicer. But: the way you are trying to do so isn't pythonic,
because there isn't one obvious way how your proposal works; you're not even
specifying a proper semantic interpretation of your syntax (and use "magic"
markers, which is even more a NoNo). I used 'magic' markers, since I am lousy at coming up with new
keywords....

For a better thought out proposal (IMHO) for stacking and defining namespaces
(based on the current metaclass behaviour), look for the PEP on the "make"
keyword (which was sent to Py-Dev some weeks ago).

It might be that my proposal the same as the 'make' pep but not so
general...
But I'll try to formalize it a little bit more.

I am proposing two new keywords 'node' and 'attr'. Which have the
syntax:

node [callable|name][:]

This will append itself to the current node if it is a callable. If it
is a name it
will become the new current node. The current node has the scope of the
block
or until a new node is created.

attr name = expression
This will set the attribute name to expression on the current node.

I dont think it is the same as the 'make' but I wouldnt rule it
out.....

[bruno at modulix]

glomde wrote:

I'm answering two of you posts here...

Sweet Lord, have mercy !

> Which should create myList = [[0..9], {0:0, ... 9:9}]
myList = [
range(10),
dict((i, i) for i in range(10))
]

Let's talk about readability....

My code was just to show that the proposal is not only for HTML
generation but could be used whenever you want to create COMPLEX
hierarcical datastructures.

It's enough to see why no-one in it's own mind would ever want to use
such a syntax.
Do I need to show you a example where you cant use the style you
showed?
Please, don't. Let's protect innocent eyes.

Strange enough, working with trees is nothing new, and it seems that
almost anyone managed to get by without cryptic 'operators' stuff.
Strange enough once almost anyone managed to get by without Python...
:-)

I used HTML as example since it is a good
example and
most people would understand the intention.

Sorry for being dumb.

It not your fault :-)

But could you elaborate on your comment that it is unusable.

Ask all the coders that switched from Perl to Python why they did so...

You seem to really have a thing for Perl...

Yes : readability. Being dumb, I need a readable, cryptic-operator free
language.

From what you written I assume you mean that it is no good because you

find the syntax cryptic.

cryptic *and* utterly ugly FWIW.

Also, you failed to address the fact that there may be much better ways
to do so, even probably without syntax change.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[bruno at modulix]

glomde wrote:

What you are trying to achieve is to make syntactic sugar for making namespace
definitions look nicer. But: the way you are trying to do so isn't pythonic,
because there isn't one obvious way how your proposal works; you're not even
specifying a proper semantic interpretation of your syntax (and use "magic"
markers, which is even more a NoNo).
I used 'magic' markers, since I am lousy at coming up with new
keywords....

This is an understatement.

(snip) But I'll try to formalize it a little bit more.

I am proposing two new keywords 'node' and 'attr'. Which have the
syntax:

node [callable|name][:]

This will append itself to the current node if it is a callable. If it
is a name it
will become the new current node. The current node has the scope of the
block
or until a new node is created.

attr name = expression
This will set the attribute name to expression on the current node.
We already have this (quite close to) this syntax:

class <name>(super) :
<name>=<attr_va lue> *
[class *]

There's also the Zope3 'implements' trick, that allow to modify the
class namespace without assignement:

class <name>:
<callable>(*arg s, **kw)*

So what you want is very certainly doable without any syntax change.

I dont think it is the same as the 'make' but I wouldnt rule it
out.....

It has already been ruled out IIRC.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[glomde]

> We already have this (quite close to) this syntax:

class <name>(super) :
<name>=<attr_va lue> *
[class *]

There's also the Zope3 'implements' trick, that allow to modify the
class namespace without assignement:

class <name>:
<callable>(*arg s, **kw)*

So what you want is very certainly doable without any syntax change.

It's not obvious me how you would do it it with the above syntax.
Could you give me an example?
For example how would you do:

root = ET.Element("htm l")
node root:
attr head("head"):
node title("title):
for i in sections:
node section():
attr Text = section[i]

[Bruno Desthuilliers]

glomde a écrit :

We already have this (quite close to) this syntax:

class <name>(super) :
<name>=<attr_va lue> *
[class *]

There's also the Zope3 'implements' trick, that allow to modify the
class namespace without assignement:

class <name>:
<callable>(*arg s, **kw)*

So what you want is very certainly doable without any syntax change.

It's not obvious me how you would do it it with the above syntax.
Could you give me an example?
For example how would you do:

root = ET.Element("htm l")
node root:
attr head("head"):
node title("title):
for i in sections:
node section():
attr Text = section[i]

Your snippet doesn't follow the syntax you described.
But FWIW:

class Root(Node):
class Head(Node):
class Title(Node):
content="page title"
for section in sections:
class Section(Node):
content=section

Ok. Get it. Doh :(

Can't work, because we can't neither reuse the same name nor dynamically
create it (or if it's possible, I fail to see how without really dirty
code).

Point taken.

We'd need the make: statement, but the BDFL has pronounced against.

I'm still -2 against your proposition, but it could make a good use case
for the make statement. I gave an eye at the new 'with' statement, but
I'm not sure it could be used to solve this.

[Heiko Wundram]

Am Freitag 19 Mai 2006 02:08 schrieb Bruno Desthuilliers:

We'd need the make: statement, but the BDFL has pronounced against.

I'm still -2 against your proposition, but it could make a good use case
for the make statement. I gave an eye at the new 'with' statement, but
I'm not sure it could be used to solve this.

Couldn't. "with" is a blatant misnomer for that it's functionality is
(basically a "protected" generator), at least if you know what with does in
VB (god, am I really comparing VB with Python? And I've never even programmed
in the former...)

--- Heiko.