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 packa
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 cou
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
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 rep
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' statem
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 cou
glomde a écrit :
>>We already have this (quite close to) this syntax:
>>
>>class (super):
>> = *
>> [class *]
>>
>>There's also the Zope3 'implements' trick, that allow to modify the
>>class namespace without assignement:
>>
>>class :
>> (*args, **kw)*
>>
>>So what you want is very certainly doabl
> We already have this (quite close to) this syntax:
>
> class (super):
> = *
> [class *]
>
> There's also the Zope3 'implements' trick, that allow to modify the
> class namespace without assignement:
>
> class :
> (*args, **kw)*
>
> So what you want is very certainly doable without any syntax
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
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
> 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
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
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
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
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
> hierar
> 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 hier
> 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
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 trans
glomde wrote:
>>What about using data for nodes and '=' for attributes ?
>>Would look like:
>>
>>
>>
>>Page Title
>>
>>
>>Hello World
>>
>>
>>
>>>I think that with the added syntax you get better view of the html
>>>page.
>>
>>indeed !-)
>
>
> I dont think it is very pythonic :-).
> 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 b
> What about using data for nodes and '=' for attributes ?
> Would look like:
>
>
>
> Page Title
>
>
> Hello World
>
>
>
> > 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
> 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
> &bgc
> 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-syste
[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 yo
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 cou
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"):
> *=*b
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 d
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
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
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):
fo
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):
> *
"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
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 c
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 somet
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
35 matches
Mail list logo
