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

[bruno at modulix]

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 at modulix]

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 ?

 

[Heiko Wundram]

Am Donnerstag 18 Mai 2006 15:17 schrieb glomde:

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).

???. 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...

Sorry for being dumb.

It not your fault

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]

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 once almost anyone managed to get by without Python...




It not your fault




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

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

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 at modulix]

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_value> *
[class *]

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

class <name>:
<callable>(*args, **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.

 

[glomde]

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

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

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

class <name>:
<callable>(*args, **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("html")
node root:
attr head("head"):
node title("title):
for i in sections:
node section():
attr Text = section

 

[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.

 

[glomde]

So I read trough all of the make PEP and make would support the syntax
i propose..
and more generic and better in many ways. Since it was rejected I have
to continue live
with my preprocessor...

From the make PEP

...... Allowing this sort of customization could allow XML to be written
without repeating element names, and with nesting of make-statements
corresponding to nesting of XML elements:

make Element html:
make Element body:
text('before first h1')
make Element h1:
attrib(style='first')
text('first h1')
tail('after first h1')
make Element h1:
attrib(style='second')
text('second h1')
tail('after second h1')

 

[Bruno Desthuilliers]

glomde a écrit :

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

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

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

class <name>:
<callable>(*args, **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("html")
node root:
attr head("head"):
node title("title):
for i in sections:
node section():
attr Text = section

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.

 

[Bruno Desthuilliers]

Heiko Wundram a écrit :

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



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?

Lol !-)

And I've never even programmed
in the former...)

I did in a previous life. And believe me, this is kind of a WTF
language... To quote the poet : "Dumb all over, a little ugly on the side".

But I was not thinking about anything related to VB's 'with' !-)
Just about what other (than class) statements defines a block that then
becomes a namespace you can manipulate.

Something like:

with Node('root') as root:
with Node('head') as head:
with Node('title') as title:
title.content = "Page Title"
for s in section:
with Node('section %s' % s['title']) as section:
section.content = s['content']


Now the question is : how to we get the Node objects back ? If possible
without adding them explicitely to the parent object ? (which would not
solve the problem of the root Node anyway).

 

[Bruno Desthuilliers]

glomde a écrit :

So I read trough all of the make PEP and make would support the syntax
i propose..
and more generic and better in many ways. Since it was rejected I have
to

.... bug the BDFL until he reconsiders its position.

 

[Ian Bicking]

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.

You might want to look at PEP 359 for ideas:
http://www.python.org/dev/peps/pep-0359/

 

[bruno at modulix]

You might want to look at PEP 359 for ideas:
http://www.python.org/dev/peps/pep-0359/

And more specifically here - this answers my doubts about the
possibility to use the with statement:

http://mail.python.org/pipermail/python-list/2006-April/336774.html