Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
glomde wrote: 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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
Ian Bicking wrote:
glomde wrote:
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/
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
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
There are some difference which are quite essential. First of all I dont se how you set attributes with that and then I dont see how you can mix python code with the creation. So how do you do this: root = ET.Element(html) *!*root: *!*head(head): *!*title(title): for i in sections: !*! section(): *=*Text = section[i] -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
But you cant mix python code in there when creating the nodes. That is when it gets quite ugly an unreadable according to me. But I also relly do think that this: # build a tree structure root = ET.Element(html) *!*root: *!*head(head): *!*title(title): *=*text = Page Title *!*body(body): *=*bgcolor = #ff *=*text = Hello, World! Especially if you start having deeper hierachies like. But the big other plus is that you can have any python code in beetween. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
Actually we did start of with YAML, but realised that we need to have the power of a programming language aswell. But I wanted to come up with something that looked very clos to YAML since I find it quite readable. I have implemented the syntax, but as a preprocessor for python and it works quite nice. Cheers, T -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
glomde wrote:
There are some difference which are quite essential.
First of all I dont se how you set attributes with that and
Use dicts as childs.
then I dont see how you can mix python code with the creation.
You can put any python expression in there, and in the Node class you can do
what you want.
Seems that you are after a templating-system. Well, there are plenty of them
available, including yours. A preprocessor is nothing but a template system
- see TurboGears-utilized KID (http://kid.lesscode.org/) for example, it
generates python files. And way more readable, because you are working in
the domain of your application (HTML) instead of some crude syntax that is
neither fish or flesh.
Counterquestion: how do you create this:
?xml version='1.0' encoding='utf-8'?
?python
from urllib import urlopen
from elementtree.ElementTree import parse, tostring
feed = 'http://naeblis.cx/rtomayko/weblog/index.atom'
root = parse(urlopen(feed)).getroot()
ns = '{http://purl.org/atom/ns#}'
title = root.findtext(ns + 'title')
?
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:py=http://purl.org/kid/ns#;
head
title py:content=title /
/head
body bgcolor=blue text=yellow
h1 py:content=title /
table cellpadding=4 cellspacing=4
tr py:for=i, entry in enumerate(root)
py:if=entry.tag == ns + 'entry'
td py:attrs=bgcolor=('white', 'yellow')[i % 2]
a py:attrs=href=entry.find(ns + 'link').attrib['href']
py:content=entry.findtext(ns + 'title') /
/td
/tr
/table
/body
/html
Diez
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
glomde wrote: i I would like to extend python so that you could create hiercical [...] # build a tree structure root = ET.Element(html) *!*root: *!*head(head): *!*title(title): *=*text = Page Title *!*body(body): *=*bgcolor = #ff *=*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? I personally dislike the nested-indented-brackets type of code given in other replies, and i think your suggestion has a certain appeal - 'What you see is what you mean' . But it's not Python. You also repeat yourself: head(head), title(title), body(body) What about this: # build a tree structure root = ET.Element(html) !root !head !title if A is True: text = Page A else: text = Page B !body bgcolor = #ff text = Hello, World! mmm...yamlthon? yython...:-) All the best Gerard -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
glomde wrote:
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.
(snip)
With syntactical sugar:
# build a tree structure
root = ET.Element(html)
*!*root:
*!*head(head):
*!*title(title):
*=*text = Page Title
*!*body(body):
*=*bgcolor = #ff
*=*text = Hello, World!
What about using XXXdata/XXX for nodes and '=' for attributes ?
Would look like:
html
head
titlePage Title/title
/head
body bgcolor='#ff'
Hello World
/body
/html
I think that with the added syntax you get better view of the html
page.
indeed !-)
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: 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. Any comments? Yes: it's ugly and unnecessary. Why would you want to change the language syntax just to make it easier to express markup directly in program code? Javascript just made that mistake with E4X: IMHO, it makes for some of the ugliest code. E4X reminds me of that Microsoft b*stardisation, XML Data Islands. http://www.w3schools.com/e4x/e4x_howto.asp http://en.wikipedia.org/wiki/E4X For a nice pythonic solution to representing markup directly in python code, you should check out stan. http://divmod.org/users/exarkun/nevow-api/public/nevow.stan-module.html Here's a nice stan example, taken from Kieran Holland's tutorial http://www.kieranholland.com/code/documentation/nevow-stan/ aDocument = tags.html[ tags.head[ tags.title[Hello, world!] ], tags.body[ tags.h1[ This is a complete XHTML document modeled in Stan. ], tags.p[ This text is inside a paragraph tag. ], tags.div(style=color: blue; width: 200px; background-color: yellow;) [ And this is a coloured div. ] ] ] That looks nice and simple, and no need to destroy the elegance of python to do it. regards, -- alan kennedy -- email alan: http://xhaus.com/contact/alan -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
You can put any python expression in there, and in the Node class you can do
what you want.
But the main advantage is any python code not only expressions. In
addition to that
you get nice flow style. Can set variables which you later use as want.
Seems that you are after a templating-system. Well, there are plenty of them
available, including yours. A preprocessor is nothing but a template system
- see TurboGears-utilized KID (http://kid.lesscode.org/) for example, it
generates python files. And way more readable, because you are working in
the domain of your application (HTML) instead of some crude syntax that is
neither fish or flesh.
What I propose is for all data that is hierarcical. Not only HTML. I
dont use it for creating html. Templating systems have the drawback IMO
that the more code you get the more undreadable it gets. If the code
part is small they are very nice.
The other part is that indentation, syntax highlighting and so on works
not so well when working with such code.
I would translate your example to the below. Which I think is much more
readable, since you see the python code flow much easier. I realised
that you realy should do Element(html) and not html(html) when
adding nodes in my syntax and using elementtree.
from urllib import urlopen
from elementtree.ElementTree import parse, tostring
feed = 'http://naeblis.cx/rtomayko/weblog/index.atom'
root = parse(urlopen(feed)).getroot()
ns = '{http://purl.org/atom/ns#}'
title = root.findtext(ns + 'title')
root = ET.Element(html)
*+* root:
*+* Element(head):
*+* Element(title)
*+* Element(body):
*=* bgcolor = blue
*=* text = yellow
*+* Element(table):
*=* cellpadding=4
*=* cellspacing=4
for i, entry in enumerate(root):
*+* Element(tr):
if entry.tag==ns + 'entry':
*+* Element(td):
*=* bgcolor = ('white', 'yellow')[i %
2]
*+* Element(a):
*=* href = entry.find(ns +
'link').attrib['href']
*=* text = entry.findtext(ns +
'title')
With the above you can use your favorite editor to do the coding and
get indentation, syntax highlightning and so on. Which I find can be
quite a burden with a templating system especially the more code that
is in there.
It is also easier to debug in comparison when using a templating system.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
You also repeat yourself: head(head), title(title), body(body) What about this: # build a tree structure root = ET.Element(html) !root !head !title if A is True: text = Page A else: text = Page B !body bgcolor = #ff text = Hello, World! Yes this is how it should be. But It depends on which package would be used. If you used xist it would look like that since they have one class for each html tag. I really propose a generic solution that any package that support the method append and __settiem__ could use the new syntax. But minor isssues but it would look something like this with xist: !root !head(): !title(): if A is True: text = Page A else: text = Page B !body() bgcolor = #ff text = Hello, World! mmm...yamlthon? yython...:-) Guess what I have for suffix on the files before preprocessing? pyml ofcourse. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
What about using XXXdata/XXX for nodes and '=' for attributes ? Would look like: html head titlePage Title/title /head body bgcolor='#ff' Hello World /body /html I think that with the added syntax you get better view of the html page. indeed !-) I dont think it is very pythonic :-). You dont use endtags and then you dont use ':' to mark that you nest a level. :-) And I dont see where it is allowed to put real python code. So could you show an example with a for loop? :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
Here's a nice stan example, taken from Kieran Holland's tutorial http://www.kieranholland.com/code/documentation/nevow-stan/ I took a quick look and it looks nice as long as your page is static. But I couldnt se how you could mix in python code seamlessy when creating your tree. But I might be wrong if you could write: tags.body[ for i in range(10): tags.h1[ Heading %s. %(i) ], tags.p[ This text is inside a paragraph tag. ], ] I think that this is close enough to my syntax. But I dont think you can do it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
glomde wrote:
What about using XXXdata/XXX for nodes and '=' for attributes ?
Would look like:
html
head
titlePage Title/title
/head
body bgcolor='#ff'
Hello World
/body
/html
I think that with the added syntax you get better view of the html
page.
indeed !-)
I dont think it is very pythonic :-).
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...
I think you would have much more success trying to get this added to
Perl !-)
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
Am Donnerstag 18 Mai 2006 13:27 schrieb bruno at modulix: 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... 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). Adding these kind of operators to Python is an absolute NoNo, because it's nothing general the OP is trying to achieve here. Creating a small wrapper language: why not? (it's not that we have enough templating languages already ;-)) 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? --- Heiko. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
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. But it would work for any package that manipulates, creates hierarchical data. I used HTML as example since it is a good example and most people would understand the intention. But could you elaborate on your comment that it is unusable. Do you think all template systems are unusable or what is the specific reason you think what i propose is unusable? IMO it is a mix between yml and python. Yml has the advantage that it can be read by many programming languages but the disadvantage is that it is static. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
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 it can be used for all hieracical data.
Example:
myList = []
*+* myList:
*+* []:
for i in range(10):
*+* i
*+* {}:
for i in range(10):
*=* i = i
Which should create myList = [[0..9], {0:0, ... 9:9}]
So it adds the power of for loops etc when creating data structures.
ANY datastructure.
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.
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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
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 '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
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 '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
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 '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
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_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.
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
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[i] -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
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[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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
Heiko Wundram a écrit :
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?
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).
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
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')
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
glomde wrote: 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. Given that python doesn't have syntactic sugar for something as prevalent as regular expressions, it's not that hard to predict the luck of this proposal. Good luck pushing it forward. George -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
glomde schrieb:
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(html)
head = ET.SubElement(root, head)
title = ET.SubElement(head, title)
title.text = Page Title
body = ET.SubElement(root, body)
body.set(bgcolor, #ff)
body.text = Hello, World!
With syntactical sugar:
# build a tree structure
root = ET.Element(html)
*!*root:
*!*head(head):
*!*title(title):
*=*text = Page Title
*!*body(body):
*=*bgcolor = #ff
*=*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?
It's ugly, and could easily achieved using the built-in tupels, lists
and dictionaries together with a simple traversing function.
Like this (untested):
class Node(object):
def __init__(self, value):
self.value = vallue
self._childs = []
def append(self, child):
self._childs.append(child)
t = ('root',
('child1,
('grandchild', ()),
'child2',
()
)
)
def create_node(t):
value, childs = t
n = Node(value)
if childs:
for ch in childs:
n.append(create_node(ch))
return n
IMHO that tuple-based tree is waaay more readable than your proposal -
and no need to come up with new syntax.
Diez
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
glomde [EMAIL PROTECTED] writes: With element tree package. # build a tree structure root = ET.Element(html) head = ET.SubElement(root, head) title = ET.SubElement(head, title) title.text = Page Title body = ET.SubElement(root, body) body.set(bgcolor, #ff) body.text = Hello, World! With syntactical sugar: # build a tree structure root = ET.Element(html) *!*root: *!*head(head): *!*title(title): *=*text = Page Title *!*body(body): *=*bgcolor = #ff *=*text = Hello, World! We already have syntax for building hierarchical data structures: lists and/or tuples. If you want to define Node and Attribute classes, you can already do so without adding new syntax. I think that with the added syntax you get better view of the html page. I think indenting our existing data type syntax can do the same thing: root = Node(html, children=[ Node(head, children=[ Node(title, children=[ Page Title, ]) ]), Node(body, children=[ Attribute(bgcolor, white), Hello, World!, ]), ]) Set up the __init__ for those classes to do whatever you would have done with the syntax you proposed. Repeating things dissapears and you get indentation that corresponds to the tree. Indeed. I think it is very pythonic IMHO. Adding new punctuation to deal with a particular type is extremely un-Pythonic. -- \ The cost of a thing is the amount of what I call life which is | `\ required to be exchanged for it, immediately or in the long | _o__)run. -- Henry David Thoreau | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal for new operators to python that add syntactic sugar for hierarcical data.
glomde wrote: i I would like to extend python so that you could create hiercical tree structures (XML, HTML etc) easier ... With syntactical sugar: # build a tree structure root = ET.Element(html) *!*root: *!*head(head): *!*title(title): *=*text = Page Title *!*body(body): *=*bgcolor = #ff *=*text = Hello, World! Hunt up PyYAML. It might be what you want. --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
