Development of the lxml library

Dirk Rothe | 1 Feb 16:58

Re: exslt functions in xpath expressions

done: https://bugs.launchpad.net/lxml/+bug/515553

On Sat, 30 Jan 2010 17:10:25 +0100, Stefan Behnel <stefan_ml <at> behnel.de>  
wrote:

>
> Dirk Rothe, 30.01.2010 16:14:
>> In [9]: print tree.xpath("/a[@b=str:split('12 34')]", namespaces={'str':
>> "http://exslt.org/strings"})
>> [...]
>> XPathEvalError: Unregistered function
>
> You're right, they are currently only available to XSLT. It seems that at
> least the date, math, sets and string functions can be enabled in plain
> XPath, but only from libxslt 1.1.25 onwards. That version was released on
> 2009-09-17, so it's fairly recent.
>
> http://xmlsoft.org/XSLT/EXSLT/html/libexslt-exslt.html
>
> Could you file a feature request for this in the bug tracker? I should be
> able to add support in lxml 2.3.
>
> Stefan

headers

Stefan Behnel | 1 Feb 20:18

Re: ElementTree 1.3a xpath position broken?


Richard Baron Penman, 31.01.2010 14:56:
>>> I am after xpath support for an application running on Google App Engine,
>>> which unfortunately rules out lxml.
>> Yeah, I know. That's one of the reasons I never found a use for the GAE on
>> my side. That also makes your e-mail somewhat misplaced on this list. ;)
> 
> Hopefully the lxml feature request goes somewhere:
> http://code.google.com/p/googleappengine/issues/detail?id=18

Intestering. Yes, let's see what that gives. Everyone's invited to vote for
that bug, obviously.

> Can you recommend an alternative for discussing ElementTree?
> I tried emailing Fredrik earlier but didn't get a response and the
> ElementTree repository hasn't been committed to since 2007.

Fredrik is rather packed with other stuff these days.

Note that ET 1.3 may make it into 3.2/2.7:

http://bugs.python.org/issue1143

So c.l.py and the Python bug tracker are suitable places. For
implementation specific questions, there is also python-dev and the stdlib
sig mailing list.

> http://sourceforge.net/projects/pdis-xpath/
>> I never tried it, but it's been recently updated, so it looks like it's
>> still maintained.

(Continue reading)

headers

Richard Baron Penman | 2 Feb 01:56

Re: ElementTree 1.3a xpath position broken?

On Tue, Feb 2, 2010 at 6:18 AM, Stefan Behnel <stefan_ml <at> behnel.de> wrote:

Fredrik is rather packed with other stuff these days.

Note that ET 1.3 may make it into 3.2/2.7:

http://bugs.python.org/issue1143

hmm, not sure that is a good idea if ET was not maintained recently.

> http://sourceforge.net/projects/pdis-xpath/
>> I never tried it, but it's been recently updated, so it looks like it's
>> still maintained.
>>
>
> That project does look promising, however it doesn't yet support // or ..

I believe that it lacks support for '..' (although that's trivial to
implement even with ET), but '//'???

Yep - no // support.
And I found out (from Ken Riley) that pdis is no longer maintained.

> I found it was half implemented and finished it off. There is some elegant
> code in ElementPath.py but it needs refactoring...

Care to provide a patch?

To who? Fredrik seems busy...
So I plan to fork ElementPath.py with my own updates and then release as a standalone ElementTree xpath library like pdis. Also I aim to add support for absolute xpaths, for compatibility with my existing lxml dependent code.

Richard

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

headers

Stefan Behnel | 2 Feb 09:20

Re: ElementTree 1.3a xpath position broken?

Richard Baron Penman, 02.02.2010 01:56:
> On Tue, Feb 2, 2010 at 6:18 AM, Stefan Behnel wrote:
>>> I found it was half implemented and finished it off. There is some
>>> elegant code in ElementPath.py but it needs refactoring...
>>
>> Care to provide a patch?
> 
> To who? Fredrik seems busy...

To lxml - remember what list we have this discussion on?

Also, to the Python bug tracker. I doubt that a new feature like this would
be rejected.

> So I plan to fork ElementPath.py with my own updates and then release as a
> standalone ElementTree xpath library like pdis. Also I aim to add support
> for absolute xpaths, for compatibility with my existing lxml dependent code.

That's also an option, and a good one IMHO. That would make it easily
available to both ET and lxml. (Advantage for lxml being the incremental
search support which is not available in XPath).

Please take a look at both implementations, the one in ET 1.3 and the one
in lxml.

http://codespeak.net/svn/lxml/trunk/src/lxml/_elementpath.py

There are some minor differences that make the latter one run faster on top
of lxml's advanced tree iterators.

Stefan

headers

jholg | 4 Feb 00:33

Re: [Bug 488222] Feature request: add better schematron support to lxml


> > This speaks for pulling the result accessor into the Schematron class,
> probably as a class attribute that can be overridden on an instance level.
> > 
> > The same might make sense for the iso-schematron implementation xsl
> transformation steps.
> 
> Sounds like a much better interface. Any interesting global options would
> be better overridden by subtyping the validator class, so class attributes
> make sense to me.

Committed to trunk:
https://codespeak.net/viewvc/?view=rev&revision=71090

This simply exposes the skeleton xslt steps and the validation result xpath as class attributes.

I consider the iso-schematron works pretty much finished for now...

Holger

--

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

headers

David Chandek-Stark | 5 Feb 19:38

Get the xml-stylesheet processing instruction

Hi,

I had a hard time tracking this info down (only figured out after reading the thread at http://codespeak.net/pipermail/lxml-dev/2006-September/001903.html), so posted a recipe:

http://fragmentsofcode.wordpress.com/2010/02/05/get-the-xml-stylesheet-processing-instruction-with-lxml/

Feel free to use or copy for any purpose.

Thanks,

David

--
David Chandek-Stark
dchandekstark (at) gmail (dot) com

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

headers

Emanuele D'Arrigo | 5 Feb 21:02

Re: Get the xml-stylesheet processing instruction

On 5 February 2010 18:38, David Chandek-Stark <dchandekstark <at> gmail.com> wrote:

I had a hard time tracking this info down (only figured out after reading the thread at http://codespeak.net/pipermail/lxml-dev/2006-September/001903.html), so posted a recipe:

http://fragmentsofcode.wordpress.com/2010/02/05/get-the-xml-stylesheet-processing-instruction-with-lxml/

True, obtaining PIs (and comments) is not exactly intuitive nor straightforward (in, fact for head-of-file PIs it's straightbackward!! =) ). I guess ideally there could be a list of them available via read-only properties on the tree object, i.e.: docTree.PIs and docTree.comments.

Manu

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

headers

John Krukoff | 5 Feb 21:58

Re: Get the xml-stylesheet processing instruction

On Fri, 2010-02-05 at 20:02 +0000, Emanuele D'Arrigo wrote:
<snip>

> True, obtaining PIs (and comments) is not exactly intuitive nor
> straightforward (in, fact for head-of-file PIs it's straightbackward!!
> =) ). I guess ideally there could be a list of them available via
> read-only properties on the tree object, i.e.: docTree.PIs and
> docTree.comments.
> 
> Manu

I agree, although my version of ideally would be for the ElementTree class 
to do a better imitation of being a root node, so that something simple 
like this would work for looping over all root level nodes:

>>> from lxml import etree
>>> x = etree.XML( '<!--Comment--><?PI?><root/>' )
>>> t = x.getroottree()
>>> list( t )
[<!--Comment-->, <?PI?>, <Element root at 872f66c>]

Or if ElementTree even supported just getchildren() to retrieve the same
data. Even more ideally ;) it'd support insert/append/replace/remove and
company for editing such root level elements. Oh yeah, and if
xpath( '/' ) returned said extended ElementTree as the root node, as
long as I'm wishing for ponies and unicorns.

I suppose the reason it's hard is because effbot's ElementTree hasn't
ever dealt with the issue of non-element root level contents.

--

-- 
John Krukoff <jkrukoff <at> ltgc.com>
Land Title Guarantee Company

headers

Martin Aspeli | 6 Feb 12:46

Copying children including text nodes

Hi,

I have two trees that were parsed with the HTML parser. The source tree is:

<html>
<head>
<body>
     Foo
     <p>Bar</p>
     Baz
</body>
</html>

The target is:

<html>
<head>
<body>
     <div id="target">Placeholder</div>
</body>
</html>

Now, I want to replace the whole of <div id="target"> tag (so, the tag 
and its children) with the *contents* of the <body> tag in the source 
tree. I obviously don't want the body tag itself.

Performance is important. Also, I don't care about the source tree after 
I'm done, so if "moving" rather than copying makes things faster/easier, 
that's OK.

What's the best way to do this? My naive approach was to do this:

sourceBody = source.find('body')
for sourceBodyChild in sourceBody:
	targetPlaceholder.addnext(sourceBodyChild)
targetPlaceholder.getparent().remove(targetPlaceholder)

However, this loses the text ("Foo"). I guess this is one case where 
dealing with text nodes explicitly would actually be better. :)

Martin

--

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

headers

Antti Kaihola | 8 Feb 11:11

Typo in exception message

Hi,

I'm catching exceptions from cssselect and my code needs to make decisions based on not only exception classes but also the particular exception messages.

The word "pseudo" is mistyped as "psuedo" in four different exceptions. Are these typos going to be kept unchanged for good, or should my code be prepared to match a corrected version as well?

The same typo seems to occur on the lxml web pages as well, by the way.

Regards,

Antti Kaihola
Espoo, Finland

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

10	February 2012
46	January 2012
29	December 2011
33	November 2011
44	October 2011
29	September 2011
26	August 2011
28	July 2011
44	June 2011
42	May 2011
45	April 2011
46	March 2011
82	February 2011
8	January 2011
27	December 2010
36	November 2010
39	October 2010
68	September 2010
29	August 2010
80	July 2010
51	June 2010
72	May 2010
38	April 2010
83	March 2010
48	February 2010
81	January 2010
73	December 2009
88	November 2009
58	October 2009
60	September 2009
83	August 2009
100	July 2009
132	June 2009
51	May 2009
45	April 2009
54	March 2009
58	February 2009
68	January 2009
45	December 2008
104	November 2008
43	October 2008
42	September 2008
101	August 2008
136	July 2008
120	June 2008
110	May 2008
66	April 2008
75	March 2008
165	February 2008
75	January 2008
43	December 2007
30	November 2007
100	October 2007
111	September 2007
84	August 2007
146	July 2007
175	June 2007
95	May 2007
76	April 2007
55	March 2007
94	February 2007
20	January 2007
36	December 2006
63	November 2006
84	October 2006
121	September 2006
117	August 2006
61	July 2006
286	June 2006
281	May 2006
42	April 2006
136	March 2006
32	February 2006
23	January 2006
96	December 2005
263	November 2005
50	October 2005
41	September 2005
126	August 2005
29	July 2005
59	June 2005
78	May 2005
48	April 2005
22	January 2005
5	December 2004
28	November 2004
19	October 2004
6	September 2004

Mon	Tue	Wed	Thu	Fri	Sat	Sun

1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28