Ian Bicking | 1 Dec 20:32 2008

Re: pyquery

Olivier Lauzanne wrote:
> Hello,
> 
> First thanks for lxml it's great.
> But I miss an interface on top of it. Something like jquery 
> <http://jquery.com> or hpricot <http://code.whytheluckystiff.net/hpricot/>.
> Is there any work in progress to go toward something like that in python ?
> 
> Missing a jquery like API in python, I started reproducing the jquery 
> API in python by using lxml and released it a few days ago : pyquery 
> <http://pypi.python.org/pypi/pyquery>

Some of this overlaps with what lxml.html already does, and some would 
already be appropriate there.  jQuery is a bit unusual in a Python 
context, because it only deals with sets of elements.  But it's not 
unreasonable.

Some things in jQuery are a result of Javascript, where the equivalent 
in Python would use a different syntax.  For instance:

   >>> p.attr("id")
   'hello'
   >>> p.attr("id", "plop")
   []

Would more typically be:

   >>> p.attrib['id']
   'hello'
   >>> p.attrib['id'] = 'plop'
(Continue reading)

Ian Bicking | 1 Dec 21:32 2008

Re: Question on clean_html

Brian Neal wrote:
> Hi,
> 
> I would like to use lxml to remove all tags except 'a' tags. Is this possible?
> 
> I don't seem to understand the arguments to the Cleaner class. What
> does allow_tags do?
> 
> I tried this:
> 
>>>> c = Cleaner(allow_tags=('a',), remove_unknown_tags=False)
>>>> print c.clean_html('<b>Hi</b>')
> <b>Hi</b>
> 
> Do I instead have to list all the tags I don't want, except for 'a',
> in a remove_tags keyword argument?
> 
> Any hints? Thank you.

There's not really a way to do this with the Cleaner I'm afraid. 
(Hrm... I really need to clean up the options there, as they overlap in 
lots of weird ways and are confusing.)

The method .drop_tag could help here, like (untested):

for el in list(doc.iter()):
     if el.tag not in ['a']:
         el.drop_tag()

I'm not 100% sure what happens if you modify the tree in place like 
(Continue reading)

Stefan Behnel | 2 Dec 09:23 2008
Picon

Re: Question on clean_html

Ian Bicking wrote:
> for el in list(doc.iter()):
>      if el.tag not in ['a']:
>          el.drop_tag()
>
> I'm not 100% sure what happens if you modify the tree in place like
> this, though I think list() will make it work.

It will at least refuse to drop the root element. Running through
list(root.iterdescendants()) should work, though, although the above will
definitely not result in a valid HTML document.

If you are really only interested in a couple of tags without a meaningful
structure, you should collect them in a list rather than cutting
everything else out of the document (which is quite costly).

Stefan
Olivier Lauzanne | 2 Dec 14:23 2008
Picon

Re: pyquery



On Mon, Dec 1, 2008 at 8:32 PM, Ian Bicking <ianb <at> colorstudy.com> wrote:
Olivier Lauzanne wrote:
Hello,

First thanks for lxml it's great.
But I miss an interface on top of it. Something like jquery <http://jquery.com> or hpricot <http://code.whytheluckystiff.net/hpricot/>.

Is there any work in progress to go toward something like that in python ?

Missing a jquery like API in python, I started reproducing the jquery API in python by using lxml and released it a few days ago : pyquery <http://pypi.python.org/pypi/pyquery>

Some of this overlaps with what lxml.html already does, and some would already be appropriate there.  jQuery is a bit unusual in a Python context, because it only deals with sets of elements.  But it's not unreasonable.

In lxml.html, it seems there is very specific code for each html tag. I think the css query approach is more powerfull and simple. And it can provide a similar enough api. Instead of doing p.inputs you just do p('input').

Dealing with sets of elements is something that I came to love about jquery. And I don't think it's actually unpythonic in any way. It's just a different approach. It's just like getting an element of a string gives you a string back and not a character.
 

Some things in jQuery are a result of Javascript, where the equivalent in Python would use a different syntax.  For instance:

 >>> p.attr("id")
 'hello'
 >>> p.attr("id", "plop")
 []

Would more typically be:

 >>> p.attrib['id']
 'hello'
 >>> p.attrib['id'] = 'plop'

Javascript just doesn't have anything like __getitem__/__setitem__, and doesn't really have getters and setters (at least on many browsers) so it also has to use functions to get and set values.  Also note you don't allow things like p.attr('id', None), which should be valid (probably meaning an attribute deletion).

attr('id', None) doesn't work, but it doesn't work in jquery either, there actually is a method called removeAttr for that purpose.

You're right, jquery isn't always perfectly pythonic, it doesn't use setters, and method names use the hungarian notation which isn't pythonic and which I don't like. But it is object oriented (very much so) and allow "streamed" method application, calling method over method over method on the same object, which you can't do if you use a python setter. Also jquery misses a method to access the full html string of a tag (you can only access innerHtml) which sucks.

On the other hand it is has the advantage of being simple,  well known, used and documented API. So it felt like it would already be good to replicate it. Also reproducing the jquery API has the advantage of making it trivial to move a functionality in a web application from server to client, or client to server. And then if people started using it and if there was a consensus that it should be changed it could always be done then. But I'm open enough if you have a vision of a better API, but it would have to be a significantly better API to compensate for the fact of not using a well known API.
 

Of course if you have CSS patches to CSSSelect (e.g., for :first -- though I thought that worked?) it would be good to have them in lxml directly.  Or if there are patches to make it easier to subclass CSSSelector, that'd be fine too -- there's a number of useful extensions to selectors in jQuery (e.g., input:checkbox), but it'd be nice to keep CSSSelect itself more strictly CSS 3.  The $() constructor is also overloaded to do a lot more than selection, but that's kind of out of style for Python -- alternate class methods would be preferable.

I don't have patches yet, but I have seen where they can be done. I was planning on monkey-patching, I perfectly agree that CSSSelect should remain standard compliant. I'll check if I can do something cleaner than monkey-patching.
 

You also seem to be using lxml.etree in places where lxml.html would definitely be better.  E.g., for setting .html:

children = lxml.html.fragments_fromstring(html)
if children and isinstance(children[0], basestring):
   parent.text = children.pop(0)
else:
   parent.text = None
parent[:] = children

Also to get the HTML contents, (parent.text or '')+''.join(tostring(el) for el in parent).  I'm sure there's several other things.

Thanks for the info, I'll look into it. pyquery was the occasion for me to learn lxml so I may have overlooked some more things.

Also jquery hacks are a common practice when working on complex applications, you can't understand the logic of the application (or just don't want to modify it) so you just hack the modification in another layer on top of the application, this layer can be javasscript but I think it's kind of the same idea that is used in deliverance. I would like to have a wsgi application where I could do some quick hacks like that on server side, maybe in deliverance or in its own wsgi middleware. What do you think ?

Thanks for your answer,
Olivier Lauzanne
 

_______________________________________________
lxml-dev mailing list
lxml-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/lxml-dev
Ian Bicking | 3 Dec 19:40 2008

Re: pyquery

Olivier Lauzanne wrote:
> 
> 
> On Mon, Dec 1, 2008 at 8:32 PM, Ian Bicking <ianb <at> colorstudy.com 
> <mailto:ianb <at> colorstudy.com>> wrote:
> 
>     Olivier Lauzanne wrote:
> 
>         Hello,
> 
>         First thanks for lxml it's great.
>         But I miss an interface on top of it. Something like jquery
>         <http://jquery.com> or hpricot
>         <http://code.whytheluckystiff.net/hpricot/>.
> 
>         Is there any work in progress to go toward something like that
>         in python ?
> 
>         Missing a jquery like API in python, I started reproducing the
>         jquery API in python by using lxml and released it a few days
>         ago : pyquery <http://pypi.python.org/pypi/pyquery>
> 
> 
>     Some of this overlaps with what lxml.html already does, and some
>     would already be appropriate there.  jQuery is a bit unusual in a
>     Python context, because it only deals with sets of elements.  But
>     it's not unreasonable.
> 
> 
> In lxml.html, it seems there is very specific code for each html tag. I 
> think the css query approach is more powerfull and simple. And it can 
> provide a similar enough api. Instead of doing p.inputs you just do 
> p('input').

In most cases there's something distinct about those attributes.  For 
instance p.inputs gives you special form fields.  If course 
p.cssselect('input,select,textarea') also works (and if you don't mind a 
honking long XPath query you could do that too).

> Dealing with sets of elements is something that I came to love about 
> jquery. And I don't think it's actually unpythonic in any way. It's just 
> a different approach. It's just like getting an element of a string 
> gives you a string back and not a character.

Well... it is unpythonic in that sets and items are treated differently 
in Python (except the oddball case of strings, as you mention).  It's 
more a question of whether it is justifiably unpythonic... and I'm not 
disputing that it can be.

>     Some things in jQuery are a result of Javascript, where the
>     equivalent in Python would use a different syntax.  For instance:
> 
>      >>> p.attr("id")
>      'hello'
>      >>> p.attr("id", "plop")
>      []
> 
>     Would more typically be:
> 
>      >>> p.attrib['id']
>      'hello'
>      >>> p.attrib['id'] = 'plop'
> 
>     Javascript just doesn't have anything like __getitem__/__setitem__,
>     and doesn't really have getters and setters (at least on many
>     browsers) so it also has to use functions to get and set values.
>      Also note you don't allow things like p.attr('id', None), which
>     should be valid (probably meaning an attribute deletion).
> 
> 
> attr('id', None) doesn't work, but it doesn't work in jquery either, 
> there actually is a method called removeAttr for that purpose.

Well, it would be easy to make it work, just don't use None as your 
sentinel.

> You're right, jquery isn't always perfectly pythonic, it doesn't use 
> setters, and method names use the hungarian notation which isn't 
> pythonic and which I don't like. But it is object oriented (very much 
> so) and allow "streamed" method application, calling method over method 
> over method on the same object, which you can't do if you use a python 
> setter. Also jquery misses a method to access the full html string of a 
> tag (you can only access innerHtml) which sucks.

There's a very small (4-line?) outerHtml plugin for jquery, BTW.

> On the other hand it is has the advantage of being simple,  well known, 
> used and documented API. So it felt like it would already be good to 
> replicate it. Also reproducing the jquery API has the advantage of 
> making it trivial to move a functionality in a web application from 
> server to client, or client to server. And then if people started using 
> it and if there was a consensus that it should be changed it could 
> always be done then. But I'm open enough if you have a vision of a 
> better API, but it would have to be a significantly better API to 
> compensate for the fact of not using a well known API.

I think there are arguably places where setters and getters are just 
simpler and look nicer.  I guess I see the jQuery technique for these 
specifically as a way of turning a deficiency in Javascript (lack of 
getters and setters) into an advantage (chaining)... but I'm not sure 
it's enough of an advantage to make it worth it.

For instance, el.html and el.html = '...' seems nicer to me than 
el.html() and el.html('...'), and all you lose is the ability to do 
something like el.html('...').attr('foo', 'bar'), and that doesn't seem 
like such a big thing.

Also there's two APIs: jQuery and lxml.  There's some advantage to 
reusing the lxml APIs as well, I think, so that for instance el.attrib 
and el.get().attrib are the same.  (I'm not sure you actually 
implemented .get()?)

It might be good, or it might be sloppy, to actually support both APIs 
to the degree they don't overlap (e.g., .attr vs. .attrib).

>     Of course if you have CSS patches to CSSSelect (e.g., for :first --
>     though I thought that worked?) it would be good to have them in lxml
>     directly.  Or if there are patches to make it easier to subclass
>     CSSSelector, that'd be fine too -- there's a number of useful
>     extensions to selectors in jQuery (e.g., input:checkbox), but it'd
>     be nice to keep CSSSelect itself more strictly CSS 3.  The $()
>     constructor is also overloaded to do a lot more than selection, but
>     that's kind of out of style for Python -- alternate class methods
>     would be preferable.
> 
> 
> I don't have patches yet, but I have seen where they can be done. I was 
> planning on monkey-patching, I perfectly agree that CSSSelect should 
> remain standard compliant. I'll check if I can do something cleaner than 
> monkey-patching.

Probably some of the functions would have to turn into methods of a 
class, and then you'd subclass that to add custom selectors and XPath 
translations of those selectors.

>     You also seem to be using lxml.etree in places where lxml.html would
>     definitely be better.  E.g., for setting .html:
> 
>     children = lxml.html.fragments_fromstring(html)
>     if children and isinstance(children[0], basestring):
>        parent.text = children.pop(0)
>     else:
>        parent.text = None
>     parent[:] = children
> 
>     Also to get the HTML contents, (parent.text or
>     '')+''.join(tostring(el) for el in parent).  I'm sure there's
>     several other things.
> 
> 
> Thanks for the info, I'll look into it. pyquery was the occasion for me 
> to learn lxml so I may have overlooked some more things.
> 
> Also jquery hacks are a common practice when working on complex 
> applications, you can't understand the logic of the application (or just 
> don't want to modify it) so you just hack the modification in another 
> layer on top of the application, this layer can be javasscript but I 
> think it's kind of the same idea that is used in deliverance. I would 
> like to have a wsgi application where I could do some quick hacks like 
> that on server side, maybe in deliverance or in its own wsgi middleware. 
> What do you think ?

Yeah, that could be possible -- people have asked for the ability to do 
arbitrary code-based transitions in Deliverance -- for the reasons you 
describe, like not wanting to touch the underlying application -- and 
this would probably be a very comfortable technique for people, 
especially if they are more front-end oriented.  Like people have asked 
for the ability to do something that I guess would be expressed like 
doc('ul#menu li').prepend('&gt;), when they want some kind of text 
separators in a list.

--

-- 
Ian Bicking : ianb <at> colorstudy.com : http://blog.ianbicking.org
Dirk Rothe | 4 Dec 12:57 2008
Picon

Re: html encoding

On Thu, 04 Dec 2008 12:46:34 +0100, Daniel Jirku <nepi <at> gmx.ch> wrote:

> hi...
>
> My problem is i suppose well known, but i couldnt find any soultion  
> through my searches...
>
> I have a regular html link with ? and an &. When i print the variable in  
> pyhton, it looks fine... (like:  
> http://www.somelink.com/site.html?param1=test&param2=hello), BUT when i  
> add it to my root xml element with:
> adId1 = etree.SubElement(tagAd, "originalAdUrl")
> adId1.text = adUrl
>
> and then later write the xml to a file with this:
> toStringValue = etree.tostring(xmlTagRoot, encoding="utf-8",  
> method="xml", xml_declaration=True, pretty_print=True)
> ...
>
> the tag has as its value the link with an &amp; instead of & !!
> How can i use the correct signs for persistant storage in a xml file...?

The XML Processor has correctly escaped your "&" character. If you  
deserialise (aka load) the file with a XML Parser of your choice, it will  
restore your "&" character.

see  
http://en.wikipedia.org/wiki/Character_encodings_in_HTML#XML_character_entity_references

--dirk
Filip Salomonsson | 4 Dec 15:00 2008
Picon

Tracking down bugs

lxml occasionally goes crashing on me, with an error message and
backtrace like the one below. Usually, the same program runs just fine
if I try again. What can I do to track down the cause?

*** glibc detected *** python: free(): invalid pointer: 0x0a0388cb ***
======= Backtrace: =========
/lib/libc.so.6[0x1d3b16]
/lib/libc.so.6(cfree+0x90)[0x1d7070]
/usr/lib/libxml2.so.2(xmlNodeSetName+0xa5)[0x68fc0c5]
/home/stp02/salo/lib/python/lxml-2.1.2-py2.4-linux-i686.egg/lxml/etree.so[0x3b988f]
/usr/lib/libpython2.4.so.1.0[0x5437d83]
/usr/lib/libpython2.4.so.1.0(PyObject_GenericSetAttr+0x104)[0x5455b84]
/usr/lib/libpython2.4.so.1.0(PyObject_SetAttr+0xbb)[0x54561db]
/usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x2d51)[0x548cd91]
/usr/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x896)[0x548fc76]
/usr/lib/libpython2.4.so.1.0(PyEval_EvalCode+0x63)[0x548fd03]
/usr/lib/libpython2.4.so.1.0[0x54acad8]
/usr/lib/libpython2.4.so.1.0(PyRun_SimpleFileExFlags+0x198)[0x54ae1e8]
/usr/lib/libpython2.4.so.1.0(PyRun_AnyFileExFlags+0x7a)[0x54ae8ca]
/usr/lib/libpython2.4.so.1.0(Py_Main+0xb85)[0x54b52d5]
python(main+0x32)[0x80485b2]
/lib/libc.so.6(__libc_start_main+0xdc)[0x180dec]
python[0x80484c1]
--

-- 
filip salomonsson
Stefan Behnel | 4 Dec 15:37 2008
Picon

Re: Tracking down bugs

Hi,

thanks for the report.

Filip Salomonsson wrote:
> lxml occasionally goes crashing on me, with an error message and
> backtrace like the one below. Usually, the same program runs just fine
> if I try again. What can I do to track down the cause?

First of all, use the latest released (!) version of lxml and build it
without having Cython installed and with debug symbols enabled (add "-g3"
to your CFLAGS) so that the stack trace shows line numbers that can be
looked up in the released sources.

Then, install valgrind and try to make your program crash under valgrind
control. Valgrind usually gives pretty accurate information about the
origin of a bad memory location, so that's a lot more informative than a
bare stack trace. There is a command line in the Makefile (make valtest)
that you can use to find the appropriate options.

Stripping down your program to a shorter snippet that shows the crash more
or less reliably is a very good way to track down the circumstances that
are required to trigger the problem. In the best case, you end up with a
short test case that we can add to lxml's test suite to make sure the
problem never comes back.

Lastly, if you know how to use gdb and can investigate a bit more, any
further hints that you find can be helpful in tracking down the problem.

Thanks,

Stefan
Filip Salomonsson | 4 Dec 15:58 2008
Picon

Re: Tracking down bugs

On Thu, Dec 4, 2008 at 15:37, Stefan Behnel <stefan_ml <at> behnel.de> wrote:
>
> First of all, use the latest released (!) version of lxml and build it
> without having Cython installed and with debug symbols enabled (add "-g3"
> to your CFLAGS)

> Then, install valgrind and try to make your program crash under valgrind
> control.

Excellent; thanks! I'll try that and see what I can find. (Hadn't
noticed 2.1.3, really - I'll go get that regardless.)

> Stripping down your program to a shorter snippet that shows the crash more
> or less reliably is a very good way to track down the circumstances that
> are required to trigger the problem.

Sure will - if and when I'm able to provoke a repeatable crash. It all
seems annoyingly random so far.

> Lastly, if you know how to use gdb and can investigate a bit more, any
> further hints that you find can be helpful in tracking down the problem.

I'm afraid gdb is mostly black voodoo magic to me so far, but I'll
probably try to dive into it if I get to the point where that seems
useful.

Thank you,

Filip
(If I didn't have lxml, I think my job would be really tedious, so
thanks for that too!)
Olivier Lauzanne | 5 Dec 16:27 2008
Picon

Re: pyquery

I released pyquery 0.2 with a much more complete API. http://pypi.python.org/pypi/pyquery

On Wed, Dec 3, 2008 at 7:40 PM, Ian Bicking <ianb <at> colorstudy.com> wrote:
Olivier Lauzanne wrote:



On Mon, Dec 1, 2008 at 8:32 PM, Ian Bicking <ianb <at> colorstudy.com <mailto:ianb <at> colorstudy.com>> wrote:

   Olivier Lauzanne wrote:

       Hello,

       First thanks for lxml it's great.
       But I miss an interface on top of it. Something like jquery
       <http://jquery.com> or hpricot
       <http://code.whytheluckystiff.net/hpricot/>.

       Is there any work in progress to go toward something like that
       in python ?

       Missing a jquery like API in python, I started reproducing the
       jquery API in python by using lxml and released it a few days
       ago : pyquery <http://pypi.python.org/pypi/pyquery>


   Some of this overlaps with what lxml.html already does, and some
   would already be appropriate there.  jQuery is a bit unusual in a
   Python context, because it only deals with sets of elements.  But
   it's not unreasonable.


In lxml.html, it seems there is very specific code for each html tag. I think the css query approach is more powerfull and simple. And it can provide a similar enough api. Instead of doing p.inputs you just do p('input').

In most cases there's something distinct about those attributes.  For instance p.inputs gives you special form fields.  If course p.cssselect('input,select,textarea') also works (and if you don't mind a honking long XPath query you could do that too).


Dealing with sets of elements is something that I came to love about jquery. And I don't think it's actually unpythonic in any way. It's just a different approach. It's just like getting an element of a string gives you a string back and not a character.

Well... it is unpythonic in that sets and items are treated differently in Python (except the oddball case of strings, as you mention).  It's more a question of whether it is justifiably unpythonic... and I'm not disputing that it can be.


   Some things in jQuery are a result of Javascript, where the
   equivalent in Python would use a different syntax.  For instance:

    >>> p.attr("id")
    'hello'
    >>> p.attr("id", "plop")
    []

   Would more typically be:

    >>> p.attrib['id']
    'hello'
    >>> p.attrib['id'] = 'plop'

   Javascript just doesn't have anything like __getitem__/__setitem__,
   and doesn't really have getters and setters (at least on many
   browsers) so it also has to use functions to get and set values.
    Also note you don't allow things like p.attr('id', None), which
   should be valid (probably meaning an attribute deletion).


attr('id', None) doesn't work, but it doesn't work in jquery either, there actually is a method called removeAttr for that purpose.

Well, it would be easy to make it work, just don't use None as your sentinel.

It works in the 0.2 version that I just released.
 


You're right, jquery isn't always perfectly pythonic, it doesn't use setters, and method names use the hungarian notation which isn't pythonic and which I don't like. But it is object oriented (very much so) and allow "streamed" method application, calling method over method over method on the same object, which you can't do if you use a python setter. Also jquery misses a method to access the full html string of a tag (you can only access innerHtml) which sucks.

There's a very small (4-line?) outerHtml plugin for jquery, BTW.

Cool.
 


On the other hand it is has the advantage of being simple,  well known, used and documented API. So it felt like it would already be good to replicate it. Also reproducing the jquery API has the advantage of making it trivial to move a functionality in a web application from server to client, or client to server. And then if people started using it and if there was a consensus that it should be changed it could always be done then. But I'm open enough if you have a vision of a better API, but it would have to be a significantly better API to compensate for the fact of not using a well known API.

I think there are arguably places where setters and getters are just simpler and look nicer.  I guess I see the jQuery technique for these specifically as a way of turning a deficiency in Javascript (lack of getters and setters) into an advantage (chaining)... but I'm not sure it's enough of an advantage to make it worth it.

For instance, el.html and el.html = '...' seems nicer to me than el.html() and el.html('...'), and all you lose is the ability to do something like el.html('...').attr('foo', 'bar'), and that doesn't seem like such a big thing.

You're right. But I still think that the fact of being compatible with a known API is good.
 

Also there's two APIs: jQuery and lxml.  There's some advantage to reusing the lxml APIs as well, I think, so that for instance el.attrib and el.get().attrib are the same.  (I'm not sure you actually implemented .get()?)

No this get is not implemented yet. It seems that it's in jQuery only for backward compatibility http://docs.jquery.com/Core/get
 

It might be good, or it might be sloppy, to actually support both APIs to the degree they don't overlap (e.g., .attr vs. .attrib).

Gael Pasgrimaud started contributing to pyquery (and he contributed a lot !) and he created a more pythonic API for the attributes alongside the jQuery one.



   Of course if you have CSS patches to CSSSelect (e.g., for :first --
   though I thought that worked?) it would be good to have them in lxml
   directly.  Or if there are patches to make it easier to subclass
   CSSSelector, that'd be fine too -- there's a number of useful
   extensions to selectors in jQuery (e.g., input:checkbox), but it'd
   be nice to keep CSSSelect itself more strictly CSS 3.  The $()
   constructor is also overloaded to do a lot more than selection, but
   that's kind of out of style for Python -- alternate class methods
   would be preferable.


I don't have patches yet, but I have seen where they can be done. I was planning on monkey-patching, I perfectly agree that CSSSelect should remain standard compliant. I'll check if I can do something cleaner than monkey-patching.

Probably some of the functions would have to turn into methods of a class, and then you'd subclass that to add custom selectors and XPath translations of those selectors.

Didn't had time for it yet, but I'll look into it.
 


   You also seem to be using lxml.etree in places where lxml.html would
   definitely be better.  E.g., for setting .html:

   children = lxml.html.fragments_fromstring(html)
   if children and isinstance(children[0], basestring):
      parent.text = children.pop(0)
   else:
      parent.text = None
   parent[:] = children

   Also to get the HTML contents, (parent.text or
   '')+''.join(tostring(el) for el in parent).  I'm sure there's
   several other things.


Thanks for the info, I'll look into it. pyquery was the occasion for me to learn lxml so I may have overlooked some more things.

Also jquery hacks are a common practice when working on complex applications, you can't understand the logic of the application (or just don't want to modify it) so you just hack the modification in another layer on top of the application, this layer can be javasscript but I think it's kind of the same idea that is used in deliverance. I would like to have a wsgi application where I could do some quick hacks like that on server side, maybe in deliverance or in its own wsgi middleware. What do you think ?

Yeah, that could be possible -- people have asked for the ability to do arbitrary code-based transitions in Deliverance -- for the reasons you describe, like not wanting to touch the underlying application -- and this would probably be a very comfortable technique for people, especially if they are more front-end oriented.  Like people have asked for the ability to do something that I guess would be expressed like doc('ul#menu li').prepend('&gt;), when they want some kind of text separators in a list.

Gael also created an api for getting urls from wsgi applications so I think pyquery is getting really close from something that is actually usable :)

-
Olivier Lauzanne

_______________________________________________
lxml-dev mailing list
lxml-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/lxml-dev

Gmane