From mike at it-loops.com  Fri Mar  2 07:44:32 2007
From: mike at it-loops.com (Michael Guntsche)
Date: Fri, 02 Mar 2007 07:44:32 +0100
Subject: [lxml-dev] lxml 1.3beta released
In-Reply-To: <a7a2b76b0702271447l4ad39b4bm7be17c2764cb031@mail.gmail.com>
References: <45E45C84.8070908@behnel.de>
	<a7a2b76b0702270859u1f4125d5l4b19fc433e04249a@mail.gmail.com>
	<es1sdv$kr3$1@sea.gmane.org>
	<a7a2b76b0702271447l4ad39b4bm7be17c2764cb031@mail.gmail.com>
Message-ID: <E1HN1VI-0000dw-BB@gibson.comsick.at>

Sidnei da Silva writes: 

> On 2/27/07, Martijn Faassen <faassen at startifact.com> wrote:
>> Sidnei da Silva wrote:
>> > Installers for Windows, for Python 2.3, 2.4 and 2.5 have been uploaded. 
>>
>> I'm really happy to see you do this, Sidnei!
> 
> Thanks everyone for your nice words! 
>

Hello Sidnei, 

What happened to the uploads on cheeseshop. I can only find the windows eggs 
for 1.2.1 the ones for 1.3 are missing. Have they been removed or is there a 
problem with cheeseshop? 

Kind regards,
Michael

From cz at gocept.com  Fri Mar  2 08:15:07 2007
From: cz at gocept.com (Christian Zagrodnick)
Date: Fri, 2 Mar 2007 08:15:07 +0100
Subject: [lxml-dev] lxml 1.3beta released
References: <45E45C84.8070908@behnel.de>
Message-ID: <es8iu2$q2e$1@sea.gmane.org>

Hoi

On 2007-02-27 17:29:56 +0100, Stefan Behnel <stefan_ml at behnel.de> said:

> Hi all,
> 
> together with 1.2.1, I released a beta version of the upcoming 1.3 series. It
> contains a number of bigger changes and enhancements over the 1.2 series. The
> main difference is a rewrite of the internal namespace cleanup code that
> should reduce the problems related to duplicated namespace declarations and
> the like.

Yey, the beta works great here.

Thanks.


-- 
Christian Zagrodnick

gocept gmbh & co. kg  ?  forsterstrasse 29 ? 06112 halle/saale
www.gocept.com ? fon. +49 345 12298894 ? fax. +49 345 12298891




From mike at it-loops.com  Fri Mar  2 08:19:28 2007
From: mike at it-loops.com (Michael Guntsche)
Date: Fri, 02 Mar 2007 08:19:28 +0100
Subject: [lxml-dev] lxml 1.3beta released
In-Reply-To: <E1HN1VI-0000dw-BB@gibson.comsick.at>
References: <45E45C84.8070908@behnel.de>
	<a7a2b76b0702270859u1f4125d5l4b19fc433e04249a@mail.gmail.com>
	<es1sdv$kr3$1@sea.gmane.org>
	<a7a2b76b0702271447l4ad39b4bm7be17c2764cb031@mail.gmail.com>
	<E1HN1VI-0000dw-BB@gibson.comsick.at>
Message-ID: <E1HN236-0000he-OW@gibson.comsick.at>

Michael Guntsche writes: 

> Hello Sidnei,  
> 
> What happened to the uploads on cheeseshop. I can only find the windows eggs 
> for 1.2.1 the ones for 1.3 are missing. Have they been removed or is there a 
> problem with cheeseshop?  
> 

To answer my own E-mail. A search on cheeseshop did not find the 1.3beta 
release. I found it under 

http://cheeseshop.python.org/pypi/lxml/1.3beta 

The obvious location of course. I do not know why the search did not return 
it, since I found it yesterday.
Nevertheless, thank you once again for providing pre-compiled binary builds 
for windows. 

Kind regards,
Michael

From sidnei at enfoldsystems.com  Fri Mar  2 14:20:44 2007
From: sidnei at enfoldsystems.com (Sidnei da Silva)
Date: Fri, 2 Mar 2007 10:20:44 -0300
Subject: [lxml-dev] lxml 1.3beta released
In-Reply-To: <E1HN1VI-0000dw-BB@gibson.comsick.at>
References: <45E45C84.8070908@behnel.de>
	<a7a2b76b0702270859u1f4125d5l4b19fc433e04249a@mail.gmail.com>
	<es1sdv$kr3$1@sea.gmane.org>
	<a7a2b76b0702271447l4ad39b4bm7be17c2764cb031@mail.gmail.com>
	<E1HN1VI-0000dw-BB@gibson.comsick.at>
Message-ID: <a7a2b76b0703020520x9a2ea79s707f3d619909d142@mail.gmail.com>

On 3/2/07, Michael Guntsche <mike at it-loops.com> wrote:
> Hello Sidnei,
>
> What happened to the uploads on cheeseshop. I can only find the windows eggs
> for 1.2.1 the ones for 1.3 are missing. Have they been removed or is there a
> problem with cheeseshop?

You mean those?

http://cheeseshop.python.org/pypi/lxml/1.3beta

-- 
Sidnei da Silva
Enfold Systems                http://enfoldsystems.com
Fax +1 832 201 8856     Office +1 713 942 2377 Ext 214

From doug at isotoma.com  Mon Mar  5 15:42:16 2007
From: doug at isotoma.com (Doug Winter)
Date: Mon, 05 Mar 2007 14:42:16 +0000
Subject: [lxml-dev] *** glibc detected *** free(): invalid pointer:
	0x086449e7 ***
Message-ID: <45EC2C48.7060900@isotoma.com>

Hi,

I'm getting this error at times using lxml:

*** glibc detected *** free(): invalid pointer: 0x086449e7 ***

Unfortunately the smallest test fixture I have that does this involves 
running all of TurboGears - when I do this without TurboGears I don't 
get the error.  However, I've got a backtrace from gdb that points it's 
finger at libxml2.  I'm trying here first in case this is really an lxml 
problem.

(gdb) bt
#0  0xb7fcd410 in ?? ()
#1  0xb4a9ac4c in ?? ()
#2  0x00000006 in ?? ()
#3  0x00007da7 in ?? ()
#4  0xb7e7c811 in raise () from /lib/tls/i686/cmov/libc.so.6
#5  0xb7e7dfb9 in abort () from /lib/tls/i686/cmov/libc.so.6
#6  0xb7eb1d3a in __fsetlocking () from /lib/tls/i686/cmov/libc.so.6
#7  0xb7eb95cf in mallopt () from /lib/tls/i686/cmov/libc.so.6
#8  0xb7eb9672 in free () from /lib/tls/i686/cmov/libc.so.6
#9  0xb729055d in xmlFreeNodeList () from /usr/lib/libxml2.so.2
#10 0xb72906a2 in xmlFreeProp () from /usr/lib/libxml2.so.2
#11 0xb729091b in xmlFreePropList () from /usr/lib/libxml2.so.2
#12 0xb72904fa in xmlFreeNodeList () from /usr/lib/libxml2.so.2
#13 0xb72902fe in xmlFreeDoc () from /usr/lib/libxml2.so.2
#14 0xb73f3cc6 in initTagMatch ()
    from 
/var/local/sites/mma.dev7.isotoma.com/lib/python2.4/site-packages/lxml/etree.so
#15 0xb73f3aec in initTagMatch ()
    from 
/var/local/sites/mma.dev7.isotoma.com/lib/python2.4/site-packages/lxml/etree.so
#16 0xb73b9826 in iteratorStoreNext ()
    from 
/var/local/sites/mma.dev7.isotoma.com/lib/python2.4/site-packages/lxml/etree.so
#17 0xb73b968c in iteratorStoreNext ()
    from 
/var/local/sites/mma.dev7.isotoma.com/lib/python2.4/site-packages/lxml/etree.so
#18 0xb73beb06 in iteratorStoreNext ()
    from 
/var/local/sites/mma.dev7.isotoma.com/lib/python2.4/site-packages/lxml/etree.so

The code that causes this is calling the html method of an instance of 
the following class (I've provided the whole thing for context):

class Weather(Entity):
     has_field('id', Integer, primary_key=True)
     has_field('url', String)
     has_field('latitude', Numeric(10, 7), nullable=False)
     has_field('longitude', Numeric(10, 7), nullable=False)
     has_field('document', Unicode)
     using_options(tablename='weather')

     xsl = etree.XSLT(etree.parse(open(os.path.join(util.datadir(), 
'xsl', 'weather.xsl'))))

     @classmethod
     def near(klass, latitude, longitude):
         return 
klass.select(order_by=func.sqrt(func.pow(klass.c.latitude-latitude, 2) +
 
func.pow(klass.c.longitude-longitude,2)),
                             limit=1)[0]

     def html(self):
         doc = etree.fromstring(self.document)
         html = self.xsl(doc)
         return unicode(html)

Can anyone point me in the right direction to help debug or fix this?

Cheers,

Doug.

-- 
Isotoma, Open Source Software Consulting - http://www.isotoma.com
Tel: 01904 567349, Mobile: 07879 423002, Fax: 020 79006980
Postal Address: Tower House, Fishergate, York, YO10 4UA, UK

Registered in England.  Company No 5171172.  VAT GB843570325.
Registered Office: 19a Goodge Street, London, W1T 2PH

From stefan_ml at behnel.de  Mon Mar  5 16:56:35 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 05 Mar 2007 16:56:35 +0100
Subject: [lxml-dev] *** glibc detected *** free(): invalid
 pointer:	0x086449e7 ***
In-Reply-To: <45EC2C48.7060900@isotoma.com>
References: <45EC2C48.7060900@isotoma.com>
Message-ID: <45EC3DB3.3040007@behnel.de>

Hi,

Doug Winter wrote:
> I'm getting this error at times using lxml:
> 
> *** glibc detected *** free(): invalid pointer: 0x086449e7 ***
> 
> Unfortunately the smallest test fixture I have that does this involves 
> running all of TurboGears - when I do this without TurboGears I don't 
> get the error.  However, I've got a backtrace from gdb that points it's 
> finger at libxml2.  I'm trying here first in case this is really an lxml 
> problem.
> 
> (gdb) bt
> #0  0xb7fcd410 in ?? ()
> #1  0xb4a9ac4c in ?? ()
> #2  0x00000006 in ?? ()
> #3  0x00007da7 in ?? ()
> #4  0xb7e7c811 in raise () from /lib/tls/i686/cmov/libc.so.6
> #5  0xb7e7dfb9 in abort () from /lib/tls/i686/cmov/libc.so.6
> #6  0xb7eb1d3a in __fsetlocking () from /lib/tls/i686/cmov/libc.so.6
> #7  0xb7eb95cf in mallopt () from /lib/tls/i686/cmov/libc.so.6
> #8  0xb7eb9672 in free () from /lib/tls/i686/cmov/libc.so.6
> #9  0xb729055d in xmlFreeNodeList () from /usr/lib/libxml2.so.2
> #10 0xb72906a2 in xmlFreeProp () from /usr/lib/libxml2.so.2
> #11 0xb729091b in xmlFreePropList () from /usr/lib/libxml2.so.2
> #12 0xb72904fa in xmlFreeNodeList () from /usr/lib/libxml2.so.2
> #13 0xb72902fe in xmlFreeDoc () from /usr/lib/libxml2.so.2
> #14 0xb73f3cc6 in initTagMatch ()
>     from 
> /var/local/sites/mma.dev7.isotoma.com/lib/python2.4/site-packages/lxml/etree.so
> #15 0xb73f3aec in initTagMatch ()
>     from 
> /var/local/sites/mma.dev7.isotoma.com/lib/python2.4/site-packages/lxml/etree.so
> #16 0xb73b9826 in iteratorStoreNext ()
>     from 
> /var/local/sites/mma.dev7.isotoma.com/lib/python2.4/site-packages/lxml/etree.so
> #17 0xb73b968c in iteratorStoreNext ()
>     from 
> /var/local/sites/mma.dev7.isotoma.com/lib/python2.4/site-packages/lxml/etree.so
> #18 0xb73beb06 in iteratorStoreNext ()
>     from 
> /var/local/sites/mma.dev7.isotoma.com/lib/python2.4/site-packages/lxml/etree.so

Hmmm, two things that leave me puzzled:

* "iteratorStoreNext" points to the external C-API of etree, however, it is
unlikely that it is used here. lxml.objectify is currently the only module
that uses it.

* if "_iteratorStoreNext" is meant instead (mind the underscore), it refers to
element iteration. And I can't see where iteration is used in your example.

Any ideas from your side where iteration comes into play in your code?

Stefan

From stefan_ml at behnel.de  Mon Mar  5 18:20:43 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 05 Mar 2007 18:20:43 +0100
Subject: [lxml-dev] *** glibc detected *** free(): invalid
 pointer:	0x086449e7 ***
In-Reply-To: <45EC4F93.7050003@isotoma.com>
References: <45EC2C48.7060900@isotoma.com> <45EC3DB3.3040007@behnel.de>
	<45EC4F93.7050003@isotoma.com>
Message-ID: <45EC516B.9000604@behnel.de>

Hi Doug,

Doug Winter wrote:
> Stefan Behnel wrote:
>> Hmmm, two things that leave me puzzled:
>>
>> * "iteratorStoreNext" points to the external C-API of etree, however,
>> it is
>> unlikely that it is used here. lxml.objectify is currently the only
>> module
>> that uses it.
>>
>> * if "_iteratorStoreNext" is meant instead (mind the underscore), it
>> refers to
>> element iteration. And I can't see where iteration is used in your
>> example.
>>
>> Any ideas from your side where iteration comes into play in your code?
> 
> Hi Stefan,
> 
> All I am doing is applying an XSL transform using etree.XSLT()().  I've
> checked that backtrace again, and there are no underscores in
> iteratorStoreNext.  I've attached the XSL stylesheet I'm using, in case
> that helps.  The only unusual thing about it, perhaps, is that I am
> using exsl:node-set.
> 
> Incidentally, I previously forgot to provide version numbers:
> 
> lxml.etree:        (1, 1, 1, 0)
> libxml used:       (2, 6, 27)
> libxml compiled:   (2, 6, 26)
> libxslt used:      (1, 1, 19)
> libxslt compiled:  (1, 1, 17)

Ah, ok. Any chance you could switch to either 1.2 or 1.3beta? There were a
number of bug fixes since 1.1.1 that might be related here.

Stefan


From doug at isotoma.com  Mon Mar  5 18:46:19 2007
From: doug at isotoma.com (Doug Winter)
Date: Mon, 05 Mar 2007 17:46:19 +0000
Subject: [lxml-dev] *** glibc detected *** free(): invalid
 pointer:	0x086449e7 ***
In-Reply-To: <45EC516B.9000604@behnel.de>
References: <45EC2C48.7060900@isotoma.com> <45EC3DB3.3040007@behnel.de>
	<45EC4F93.7050003@isotoma.com> <45EC516B.9000604@behnel.de>
Message-ID: <45EC576B.9030402@isotoma.com>

Stefan Behnel wrote:
> Ah, ok. Any chance you could switch to either 1.2 or 1.3beta? There were a
> number of bug fixes since 1.1.1 that might be related here.

I thought I'd tried this before (I've been hunting this bug a while), 
and I had, but now this is narrowed down a bit it's more interesting. 
1.3beta still abends:

*** glibc detected *** free(): invalid pointer: 0x085a8a8d ***

But the backtrace is different:

(gdb) bt
#0  0xb7fce410 in ?? ()
#1  0xb4a97c0c in ?? ()
#2  0x00000006 in ?? ()
#3  0x000044c7 in ?? ()
#4  0xb7e7d811 in raise () from /lib/tls/i686/cmov/libc.so.6
#5  0xb7e7efb9 in abort () from /lib/tls/i686/cmov/libc.so.6
#6  0xb7eb2d3a in __fsetlocking () from /lib/tls/i686/cmov/libc.so.6
#7  0xb7eba5cf in mallopt () from /lib/tls/i686/cmov/libc.so.6
#8  0xb7eba672 in free () from /lib/tls/i686/cmov/libc.so.6
#9  0xb728d55d in xmlFreeNodeList () from /usr/lib/libxml2.so.2
#10 0xb728d6a2 in xmlFreeProp () from /usr/lib/libxml2.so.2
#11 0xb728d91b in xmlFreePropList () from /usr/lib/libxml2.so.2
#12 0xb728d4fa in xmlFreeNodeList () from /usr/lib/libxml2.so.2
#13 0xb728d4d6 in xmlFreeNodeList () from /usr/lib/libxml2.so.2
#14 0xb728d4d6 in xmlFreeNodeList () from /usr/lib/libxml2.so.2
#15 0xb728d4d6 in xmlFreeNodeList () from /usr/lib/libxml2.so.2
#16 0xb728d2fe in xmlFreeDoc () from /usr/lib/libxml2.so.2
#17 0xb73ed006 in __pyx_tp_dealloc_5etree__Document (o=0xb6e2848c)
     at src/lxml/etree.c:10807
#18 0xb73f01e1 in __pyx_tp_dealloc_5etree__Element (o=0xb6e32acc)
     at src/lxml/etree.c:38083
#19 0xb73b75ec in __pyx_tp_dealloc_5etree__ElementTree (o=0xb6e32a54)
     at src/lxml/etree.c:38892
#20 0xb73bc626 in __pyx_tp_dealloc_5etree__XSLTResultTree (o=0xb6e32a54)
     at src/lxml/etree.c:47656

Just to confirm the version:

 >>> from lxml import etree
 >>> etree.LXML_VERSION
(1, 3, -1, 0)

Cheers,

Doug.

-- 
Isotoma, Open Source Software Consulting - http://www.isotoma.com
Tel: 01904 567349, Mobile: 07879 423002, Fax: 020 79006980
Postal Address: Tower House, Fishergate, York, YO10 4UA, UK

Registered in England.  Company No 5171172.  VAT GB843570325.
Registered Office: 19a Goodge Street, London, W1T 2PH

From stefan_ml at behnel.de  Mon Mar  5 19:16:30 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 05 Mar 2007 19:16:30 +0100
Subject: [lxml-dev] *** glibc detected *** free(): invalid
 pointer:	0x086449e7 ***
In-Reply-To: <45EC576B.9030402@isotoma.com>
References: <45EC2C48.7060900@isotoma.com> <45EC3DB3.3040007@behnel.de>
	<45EC4F93.7050003@isotoma.com> <45EC516B.9000604@behnel.de>
	<45EC576B.9030402@isotoma.com>
Message-ID: <45EC5E7E.3010904@behnel.de>

Doug Winter wrote:
> Stefan Behnel wrote:
>> Ah, ok. Any chance you could switch to either 1.2 or 1.3beta? There
>> were a
>> number of bug fixes since 1.1.1 that might be related here.
> 
> I thought I'd tried this before (I've been hunting this bug a while),
> and I had, but now this is narrowed down a bit it's more interesting.
> 1.3beta still abends:
> 
> *** glibc detected *** free(): invalid pointer: 0x085a8a8d ***
> 
> But the backtrace is different:
> 
> (gdb) bt
> #0  0xb7fce410 in ?? ()
> #1  0xb4a97c0c in ?? ()
> #2  0x00000006 in ?? ()
> #3  0x000044c7 in ?? ()
> #4  0xb7e7d811 in raise () from /lib/tls/i686/cmov/libc.so.6
> #5  0xb7e7efb9 in abort () from /lib/tls/i686/cmov/libc.so.6
> #6  0xb7eb2d3a in __fsetlocking () from /lib/tls/i686/cmov/libc.so.6
> #7  0xb7eba5cf in mallopt () from /lib/tls/i686/cmov/libc.so.6
> #8  0xb7eba672 in free () from /lib/tls/i686/cmov/libc.so.6
> #9  0xb728d55d in xmlFreeNodeList () from /usr/lib/libxml2.so.2
> #10 0xb728d6a2 in xmlFreeProp () from /usr/lib/libxml2.so.2
> #11 0xb728d91b in xmlFreePropList () from /usr/lib/libxml2.so.2
> #12 0xb728d4fa in xmlFreeNodeList () from /usr/lib/libxml2.so.2
> #13 0xb728d4d6 in xmlFreeNodeList () from /usr/lib/libxml2.so.2
> #14 0xb728d4d6 in xmlFreeNodeList () from /usr/lib/libxml2.so.2
> #15 0xb728d4d6 in xmlFreeNodeList () from /usr/lib/libxml2.so.2
> #16 0xb728d2fe in xmlFreeDoc () from /usr/lib/libxml2.so.2
> #17 0xb73ed006 in __pyx_tp_dealloc_5etree__Document (o=0xb6e2848c)
>     at src/lxml/etree.c:10807
> #18 0xb73f01e1 in __pyx_tp_dealloc_5etree__Element (o=0xb6e32acc)
>     at src/lxml/etree.c:38083
> #19 0xb73b75ec in __pyx_tp_dealloc_5etree__ElementTree (o=0xb6e32a54)
>     at src/lxml/etree.c:38892
> #20 0xb73bc626 in __pyx_tp_dealloc_5etree__XSLTResultTree (o=0xb6e32a54)
>     at src/lxml/etree.c:47656

Hmm... I also heavily suspect the node-set function, but that would still not
make it a clear problem in libxml2, as lxml is at least a bit involved in the
function call (although not much).

Could you check if the problem goes away if you replace the respective copy-of
that creates the result set fragment in 'stuff' by something like for-each (or
whatever)?

Personally, I would report it to the libxml2 people. It may be easier for them
to track this down.

http://bugzilla.gnome.org/buglist.cgi?product=libxml2

Stefan

From doug at isotoma.com  Tue Mar  6 10:10:38 2007
From: doug at isotoma.com (Doug Winter)
Date: Tue, 06 Mar 2007 09:10:38 +0000
Subject: [lxml-dev] *** glibc detected *** free(): invalid
 pointer:	0x086449e7 ***
In-Reply-To: <45EC5E7E.3010904@behnel.de>
References: <45EC2C48.7060900@isotoma.com> <45EC3DB3.3040007@behnel.de>
	<45EC4F93.7050003@isotoma.com> <45EC516B.9000604@behnel.de>
	<45EC576B.9030402@isotoma.com> <45EC5E7E.3010904@behnel.de>
Message-ID: <45ED300E.2080403@isotoma.com>

Stefan Behnel wrote:
> Could you check if the problem goes away if you replace the respective copy-of
> that creates the result set fragment in 'stuff' by something like for-each (or
> whatever)?

I shall try that now.

> Personally, I would report it to the libxml2 people. It may be easier for them
> to track this down.

Yep, I thought that might be the case.  To join things up, here's the bug:

http://bugzilla.gnome.org/show_bug.cgi?id=415233

Cheers,

Doug.

-- 
Isotoma, Open Source Software Consulting - http://www.isotoma.com
Tel: 01904 567349, Mobile: 07879 423002, Fax: 020 79006980
Postal Address: Tower House, Fishergate, York, YO10 4UA, UK

Registered in England.  Company No 5171172.  VAT GB843570325.
Registered Office: 19a Goodge Street, London, W1T 2PH

From doug at isotoma.com  Tue Mar  6 10:19:10 2007
From: doug at isotoma.com (Doug Winter)
Date: Tue, 06 Mar 2007 09:19:10 +0000
Subject: [lxml-dev] *** glibc detected *** free(): invalid
 pointer:	0x086449e7 ***
In-Reply-To: <45ED300E.2080403@isotoma.com>
References: <45EC2C48.7060900@isotoma.com>
	<45EC3DB3.3040007@behnel.de>	<45EC4F93.7050003@isotoma.com>
	<45EC516B.9000604@behnel.de>	<45EC576B.9030402@isotoma.com>
	<45EC5E7E.3010904@behnel.de> <45ED300E.2080403@isotoma.com>
Message-ID: <45ED320E.2030106@isotoma.com>

Doug Winter wrote:
> Stefan Behnel wrote:
>> Could you check if the problem goes away if you replace the respective copy-of
>> that creates the result set fragment in 'stuff' by something like for-each (or
>> whatever)?
> 
> I shall try that now.

Same thing happens with a for-each, again in xmlFreeNodeList :/

However, something that just occurred to me.  If I change my class a bit 
so that the xsl stylesheet is no longer instantiated as a class-level 
attribute, but instead the stylesheet is created within the method call:

     def html(self):
         xsl = etree.XSLT(etree.parse(open(os.path.join(util.datadir(), 
'xsl', 'weather.xsl'))))
         doc = etree.fromstring(self.document)
         html = xsl(doc)
         return unicode(html)

It works ok.

Previously it was like:

     xsl = etree.XSLT(etree.parse(open(os.path.join(util.datadir(), 
'xsl', 'weather.xsl'))))

     def html(self):
         doc = etree.fromstring(self.document)
         html = self.xsl(doc)
         return unicode(html)


I think this must be a multi-threading issue.  Does this help?

Cheers,

Doug.

-- 
Isotoma, Open Source Software Consulting - http://www.isotoma.com
Tel: 01904 567349, Mobile: 07879 423002, Fax: 020 79006980
Postal Address: Tower House, Fishergate, York, YO10 4UA, UK

Registered in England.  Company No 5171172.  VAT GB843570325.
Registered Office: 19a Goodge Street, London, W1T 2PH

From stefan_ml at behnel.de  Tue Mar  6 11:32:07 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Tue, 06 Mar 2007 11:32:07 +0100
Subject: [lxml-dev] *** glibc detected *** free(): invalid
 pointer:	0x086449e7 ***
In-Reply-To: <45ED320E.2030106@isotoma.com>
References: <45EC2C48.7060900@isotoma.com>	<45EC3DB3.3040007@behnel.de>	<45EC4F93.7050003@isotoma.com>	<45EC516B.9000604@behnel.de>	<45EC576B.9030402@isotoma.com>	<45EC5E7E.3010904@behnel.de>
	<45ED300E.2080403@isotoma.com> <45ED320E.2030106@isotoma.com>
Message-ID: <45ED4327.1090403@behnel.de>

Hi Doug,

Doug Winter wrote:
> Doug Winter wrote:
>> Stefan Behnel wrote:
>>> Could you check if the problem goes away if you replace the respective copy-of
>>> that creates the result set fragment in 'stuff' by something like for-each (or
>>> whatever)?
>> I shall try that now.
> 
> Same thing happens with a for-each, again in xmlFreeNodeList :/

I only understood now what your script is actually doing. I meant to eliminate
the call to node-set, but I guess for-each will not even work here.

What about a plain copy-of with an XPath expression like this:

  /.../description/*[count(preceding-sibling::br) &gt; 5 and
                     count(preceding-siblings::br) &lt;= 7]

Could that do what you want (without requiring the node-set function)?


> However, something that just occurred to me.  If I change my class a bit 
> so that the xsl stylesheet is no longer instantiated as a class-level 
> attribute, but instead the stylesheet is created within the method call:
> 
>      def html(self):
>          xsl = etree.XSLT(etree.parse(open(os.path.join(util.datadir(), 
> 'xsl', 'weather.xsl'))))
>          doc = etree.fromstring(self.document)
>          html = xsl(doc)
>          return unicode(html)
> 
> It works ok.
> 
> Previously it was like:
> 
>      xsl = etree.XSLT(etree.parse(open(os.path.join(util.datadir(), 
> 'xsl', 'weather.xsl'))))
> 
>      def html(self):
>          doc = etree.fromstring(self.document)
>          html = self.xsl(doc)
>          return unicode(html)
> 
> 
> I think this must be a multi-threading issue.  Does this help?

Sounds like it. Is the class instantiated from the main thread (the one that
imports etree) or from a different thread? Sadly, that makes a difference in
etree - the latter will not work. Normally, this should be caught in XSLT(),
but maybe this is a special case somehow...

Stefan


From doug at isotoma.com  Tue Mar  6 11:38:56 2007
From: doug at isotoma.com (Doug Winter)
Date: Tue, 06 Mar 2007 10:38:56 +0000
Subject: [lxml-dev] *** glibc detected *** free(): invalid
 pointer:	0x086449e7 ***
In-Reply-To: <45ED4327.1090403@behnel.de>
References: <45EC2C48.7060900@isotoma.com>	<45EC3DB3.3040007@behnel.de>	<45EC4F93.7050003@isotoma.com>	<45EC516B.9000604@behnel.de>	<45EC576B.9030402@isotoma.com>	<45EC5E7E.3010904@behnel.de>
	<45ED300E.2080403@isotoma.com> <45ED320E.2030106@isotoma.com>
	<45ED4327.1090403@behnel.de>
Message-ID: <45ED44C0.1030504@isotoma.com>

Stefan Behnel wrote:
> Sounds like it. Is the class instantiated from the main thread (the one that
> imports etree) or from a different thread? Sadly, that makes a difference in
> etree - the latter will not work. Normally, this should be caught in XSLT(),
> but maybe this is a special case somehow...

Frankly I don't know, but it does sound like the latter.  I am creating 
the XSL instance each time now in the method, and that does resolve it.

Can you explain why this makes a difference, or point me to some docs? 
I'd like to understand this if I can :)

Cheers,

Doug.

-- 
Isotoma, Open Source Software Consulting - http://www.isotoma.com
Tel: 01904 567349, Mobile: 07879 423002, Fax: 020 79006980
Postal Address: Tower House, Fishergate, York, YO10 4UA, UK

Registered in England.  Company No 5171172.  VAT GB843570325.
Registered Office: 19a Goodge Street, London, W1T 2PH

From mike at it-loops.com  Sat Mar 10 08:39:37 2007
From: mike at it-loops.com (Michael Guntsche)
Date: Sat, 10 Mar 2007 08:39:37 +0100
Subject: [lxml-dev] Compilation problem with current trunk
Message-ID: <97DB26F2-B555-4DD3-8E0A-C985B6C573BC@it-loops.com>

Hello,

I updated to the latest trunk today and tried compiling.
I got the following error.

building 'lxml.etree' extension
lxml/src/lxml/xpath.pxi:146:27: C method can only be called
lxml/src/lxml/xpath.pxi:146:27: Cannot convert 'PyObject *((struct  
__pyx_obj_5etree__BaseContext *,PyObject *,PyObject *))' to Python  
object

I went through the last changes and found out that the brake happened  
between 39965 and 39966. I revertet the change in extensions.pxi that  
changed
	
def addNamespace
to
cdef addNamespace

and it compiled again. I am not sure if this is the correct fix,  
since my pyrex knowledge is almost non-existant, but it compiled for me.

Kind regards,
Michael


From mike at it-loops.com  Sat Mar 10 12:20:01 2007
From: mike at it-loops.com (Michael Guntsche)
Date: Sat, 10 Mar 2007 12:20:01 +0100
Subject: [lxml-dev] Compilation problem with current trunk
In-Reply-To: <97DB26F2-B555-4DD3-8E0A-C985B6C573BC@it-loops.com>
References: <97DB26F2-B555-4DD3-8E0A-C985B6C573BC@it-loops.com>
Message-ID: <5B14D28F-EDCB-42B0-96A9-12B5AD7E8F00@it-loops.com>


On Mar 10, 2007, at 8:39, Michael Guntsche wrote:

> def addNamespace
> to
> cdef addNamespace
>

Ok, looking at this some more, I think the correct solution for this  
problem would be changing the registerNamespaces method in xpath.xpi.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: xpath.patch
Type: application/octet-stream
Size: 574 bytes
Desc: not available
Url : http://codespeak.net/pipermail/lxml-dev/attachments/20070310/50556e13/attachment.obj 
-------------- next part --------------

This works for me.

Kind regards,
Michael

From stefan_ml at behnel.de  Sat Mar 10 16:57:06 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 10 Mar 2007 16:57:06 +0100
Subject: [lxml-dev] Compilation problem with current trunk
In-Reply-To: <5B14D28F-EDCB-42B0-96A9-12B5AD7E8F00@it-loops.com>
References: <97DB26F2-B555-4DD3-8E0A-C985B6C573BC@it-loops.com>
	<5B14D28F-EDCB-42B0-96A9-12B5AD7E8F00@it-loops.com>
Message-ID: <45F2D552.4060709@behnel.de>

Hi,

Michael Guntsche wrote:
>> def addNamespace
>> to
>> cdef addNamespace
> 
> Ok, looking at this some more, I think the correct solution for this
> problem would be changing the registerNamespaces method in xpath.xpi.

Right. Sorry for the incomplete commit. I was in the middle of a rewrite of
the internal extension function setup in XPath. Here's the patch.

Regards,
Stefan


Index: src/lxml/xpath.pxi
===================================================================
--- src/lxml/xpath.pxi  (Revision 39804)
+++ src/lxml/xpath.pxi  (Arbeitskopie)
@@ -143,9 +180,8 @@
     def registerNamespaces(self, namespaces):
         """Register a prefix -> uri dict.
         """
-        add = self._context.addNamespace
         for prefix, uri in namespaces.items():
-            add(prefix, uri)
+            self._context.addNamespace(prefix, uri)

     def __call__(self, _path, **_variables):
         """Evaluate an XPath expression on the document.


From sidnei at enfoldsystems.com  Wed Mar 14 18:32:06 2007
From: sidnei at enfoldsystems.com (Sidnei da Silva)
Date: Wed, 14 Mar 2007 14:32:06 -0300
Subject: [lxml-dev] Deferred XInclude/Resolvers
Message-ID: <a7a2b76b0703141032o57e6811du51ed0d952618d62f@mail.gmail.com>

One of the projects I'm dealing with uses XInclude and Resolvers a
lot. Some of the resources being included can potentially be large or
just slow to fetch (usually using httplib).

I was wondering if lxml could be modified in such a way that a
resolver could return some sort of 'deferred node/node set' so that
resolving multiple resources could happen in parallel.

-- 
Sidnei da Silva
Enfold Systems                http://enfoldsystems.com
Fax +1 832 201 8856     Office +1 713 942 2377 Ext 214

From edreamleo at charter.net  Wed Mar 14 21:51:07 2007
From: edreamleo at charter.net (Edward K. Ream)
Date: Wed, 14 Mar 2007 15:51:07 -0500
Subject: [lxml-dev] Errors while building from trunk
Message-ID: <1173905467.20698.4.camel@edreamleo-laptop>

I've been getting errors when trying to build after downloading from
svn.  I'm running Ubuntu on an 86 laptop.
I think I've installed Pyrex correctly, but maybe not.
Can anyone explain what I should do next?  Thanks.

edreamleo at edreamleo-laptop:~$ cd lxml
edreamleo at edreamleo-laptop:~/lxml$ sudo python2.4 setup.py build
Building lxml version 1.3.beta-40177
running build
running build_py
running build_ext
building 'lxml.etree' extension
/home/edreamleo/lxml/src/lxml/parser.pxi:642:30: Invalid operand types
for '|' (xmlParserOption; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:494:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:527:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:556:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:581:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:684:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:686:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:689:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:692:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:694:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:696:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:698:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:700:42: Invalid operand types
for '^' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:718:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:738:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:811:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:813:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:815:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:817:42: Invalid operand types
for '^' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:16:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:18:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:20:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:22:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:60: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:58: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterso maybe not. parse.pxi:118:32: Type
'<error>' not acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterso maybe not. parse.pxi:130:34: Type
'<error>' not acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterso maybe not. parse.pxi:137:30:
Invalid operand types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:253:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:255:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:258:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:261:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:263:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Type '<error>'
notedreamleo at edreamleo-laptop:~$ cd lxml
edreamleo at edreamleo-laptop:~/lxml$ sudo python2.4 setup.py build
Building lxml version 1.3.beta-40177
running build
running build_py
running build_ext
building 'lxml.etree' extension
/home/edreamleo/lxml/src/lxml/parser.pxi:642:30: Invalid operand types
for '|' (xmlParserOption; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:494:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:527:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:556:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:581:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:684:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:686:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:689:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:692:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:694:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:696:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:698:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:700:42: Invalid operand types
for '^' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:718:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:738:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:811:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:813:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:815:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:817:42: Invalid operand types
for '^' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:16:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:18:36: Invalid operand
typesedreamleo at edreamleo-laptop:~$ cd lxml
edreamleo at edreamleo-laptop:~/lxml$ sudo python2.4 setup.py build
Building lxml version 1.3.beta-40177
running build
running build_py
running build_ext
building 'lxml.etree' extension
/home/edreamleo/lxml/src/lxml/parser.pxi:642:30: Invalid operand types
for '|' (xmlParserOption; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:494:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:527:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:556:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:581:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:684:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:686:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:689:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:692:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:694:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:696:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:698:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:700:42: Invalid operand types
for '^' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:718:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:738:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:811:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:813:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:815:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:817:42: Invalid operand types
for '^' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:16:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:18:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:20:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:22:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:60: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:58: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:253:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:255:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:258:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:261:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:263:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Invalid operand
types for '&' (int;
__pyx_t_5etree_IterparseEventFilter)edreamleo at edreamleo-laptop:~$ cd
lxml
edreamleo at edreamleo-laptop:~/lxml$ sudo python2.4 setup.py build
Building lxml version 1.3.beta-40177
running build
running build_py
running build_ext
building 'lxml.etree' extension
/home/edreamleo/lxml/src/lxml/parser.pxi:642:30: Invalid operand types
for '|' (xmlParserOption; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:494:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:527:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:556:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:581:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:684:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:686:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:689:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:692:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:694:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:696:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:698:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:700:42: Invalid operand types
for '^' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:718:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:738:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:811:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:813:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:815:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:817:42: Invalid operand types
for '^' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:16:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:18:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:20:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:22:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:60: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:58: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:253:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:255:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:258:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:261:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:263:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Invalid operand
types for '&' (int;
__pyx_t_5etree_IterparseEventFilter)edreamleo at edreamleo-laptop:~$ cd
lxml
edreamleo at edreamleo-laptop:~/lxml$ sudo python2.4 setup.py build
Building lxml version 1.3.beta-40177
running build
running build_py
running build_ext
building 'lxml.etree' extension
/home/edreamleo/lxml/src/lxml/parser.pxi:642:30: Invalid operand types
for '|' (xmlParserOption; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:494:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:527:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:556:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:581:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:684:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:686:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:689:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:692:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:694:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:696:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:698:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:700:42: Invalid operand types
for '^' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:718:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:738:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:811:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:813:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:815:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:817:42: Invalid operand types
for '^' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:16:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:18:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:20:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:22:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:60: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:58: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:253:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:255:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:258:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:261:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:263:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Invalid
operandedreamleo at edreamleo-laptop:~$ cd lxml
edreamleo at edreamleo-laptop:~/lxml$ sudo python2.4 setup.py build
Building lxml version 1.3.beta-40177
running build
running build_py
running build_ext
building 'lxml.etree' extension
/home/edreamleo/lxml/src/lxml/parser.pxi:642:30: Invalid operand types
for '|' (xmlParserOption; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:494:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:527:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:556:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:581:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:684:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:686:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:689:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:692:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:694:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:696:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:698:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:700:42: Invalid operand types
for '^' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:718:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:738:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:811:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:813:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:815:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:817:42: Invalid operand types
for '^' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:16:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:18:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:20:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:22:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:60: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:58: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:253:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:255:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:258:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:261:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:263:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Invalid
operandedreamleo at edreamleo-laptop:~$ cd lxml
edreamleo at edreamleo-laptop:~/lxml$ sudo python2.4 setup.py build
Building lxml version 1.3.beta-40177
running build
running build_py
running build_ext
building 'lxml.etree' extension
/home/edreamleo/lxml/src/lxml/parser.pxi:642:30: Invalid operand types
for '|' (xmlParserOption; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:494:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:527:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:556:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:581:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:684:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:686:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:689:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:692:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:694:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:696:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:698:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:700:42: Invalid operand types
for '^' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:718:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:738:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:811:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:813:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:815:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:817:42: Invalid operand types
for '^' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:16:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:18:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:20:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:22:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:60: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:58: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:253:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:255:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:258:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:261:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:263:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Type '<error>'
notedreamleo at edreamleo-laptop:~$ cd lxml
edreamleo at edreamleo-laptop:~/lxml$ sudo python2.4 setup.py build
Building lxml version 1.3.beta-40177
running build
running build_py
running build_ext
building 'lxml.etree' extension
/home/edreamleo/lxml/src/lxml/parser.pxi:642:30: Invalid operand types
for '|' (xmlParserOption; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:494:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:527:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:556:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:581:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:684:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:686:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:689:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:692:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:694:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:696:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:698:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:700:42: Invalid operand types
for '^' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:718:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:738:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:811:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:813:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:815:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:817:42: Invalid operand types
for '^' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:16:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:18:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:20:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:22:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:60: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:58: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:253:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:255:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:258:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:261:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:263:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Type '<error>' not
acceptable as a boolean
edreamleo at edreamleo-laptop:~/lxml$ 
 acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Type '<error>' not
acceptable as a boolean
edreamleo at edreamleo-laptop:~/lxml$ 
 types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Type '<error>' not
acceptable as a boolean
edreamleo at edreamleo-laptop:~/lxml$ 
 types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Type '<error>' not
acceptable as a boolean
edreamleo at edreamleo-laptop:~/lxml$ 

/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Type '<error>' not
acceptable as a boolean
edreamleo at edreamleo-laptop:~/lxml$ 

/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Type '<error>' not
acceptable as a boolean
edreamleo at edreamleo-laptop:~/lxml$ 
 for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:20:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:22:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:60: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:58: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:253:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:255:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:258:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:261:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:263:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Type '<error>' not
acceptable as a booleanedreamleo at edreamleo-laptop:~$ cd lxml
edreamleo at edreamleo-laptop:~/lxml$ sudo python2.4 setup.py build
Building lxml version 1.3.beta-40177
running build
running build_py
running build_ext
building 'lxml.etree' extension
/home/edreamleo/lxml/src/lxml/parser.pxi:642:30: Invalid operand types
for '|' (xmlParserOption; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:494:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:527:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:556:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:581:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:684:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:686:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:689:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:692:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:694:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:696:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:698:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:700:42: Invalid operand types
for '^' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:718:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:738:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:811:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:813:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:815:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:817:42: Invalid operand types
for '^' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:16:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:18:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:20:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:22:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:60: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:58: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:253:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:255:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:258:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:261:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:263:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Type '<error>' not
acceptable as a booleanedreamleo at edreamleo-laptop:~$ cd lxml
edreamleo at edreamleo-laptop:~/lxml$ sudo python2.4 setup.py build
Building lxml version 1.3.beta-40177
running build
running build_py
running build_ext
building 'lxml.etree' extension
/home/edreamleo/lxml/src/lxml/parser.pxi:642:30: Invalid operand types
for '|' (xmlParserOption; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:494:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:527:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:556:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:581:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:684:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:686:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:689:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:692:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:694:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:696:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:698:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:700:42: Invalid operand types
for '^' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:718:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:738:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:811:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:813:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:815:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:817:42: Invalid operand types
for '^' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:16:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:18:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:20:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:22:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:60: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:58: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:253:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:255:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:258:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:261:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:263:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Type '<error>'
notedreamleo at edreamleo-laptop:~$ cd lxml
edreamleo at edreamleo-laptop:~/lxml$ sudo python2.4 setup.py build
Building lxml version 1.3.beta-40177
running build
running build_py
running build_ext
building 'lxml.etree' extension
/home/edreamleo/lxml/src/lxml/parser.pxi:642:30: Invalid operand types
for '|' (xmlParserOption; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:494:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:527:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:556:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:581:42: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:684:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:686:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:689:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:692:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:694:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:696:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:698:42: Invalid operand types
for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:700:42: Invalid operand types
for '^' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:718:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:738:26: Invalid operand types
for '&' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:811:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:813:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:815:42: Invalid operand types
for '|' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/parser.pxi:817:42: Invalid operand types
for '^' (int; htmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:16:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:18:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:20:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:22:36: Invalid operand types
for '|' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:60: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:81:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:58: Invalid operand types
for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:89:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:116:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:118:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:120:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:128:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:130:34: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:137:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:140:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:152:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:253:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:255:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:258:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:261:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:263:42: Invalid operand
types for '|' (int; xmlParserOption)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:64: Invalid operand
types for '|' (__pyx_t_5etree_IterparseEventFilter;
__pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:398:38: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:401:40: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:411:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Type '<error>' not
acceptable as a boolean
edreamleo at edreamleo-laptop:~/lxml$ 
 acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:413:32: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:417:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Type '<error>' not
acceptable as a boolean
edreamleo at edreamleo-laptop:~/lxml$ 

/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Type '<error>' not
acceptable as a boolean
edreamleo at edreamleo-laptop:~/lxml$ 

/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Type '<error>' not
acceptable as a boolean
edreamleo at edreamleo-laptop:~/lxml$ 
 acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:426:30: Type '<error>' not
acceptable as a boolean
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Invalid operand
types for '&' (int; __pyx_t_5etree_IterparseEventFilter)
/home/edreamleo/lxml/src/lxml/iterparse.pxi:430:30: Type '<error>' not
acceptable as a boolean
edreamleo at edreamleo-laptop:~/lxml$ 



From mike at it-loops.com  Wed Mar 14 22:50:30 2007
From: mike at it-loops.com (Michael Guntsche)
Date: Wed, 14 Mar 2007 22:50:30 +0100
Subject: [lxml-dev] Errors while building from trunk
In-Reply-To: <1173905467.20698.4.camel@edreamleo-laptop>
References: <1173905467.20698.4.camel@edreamleo-laptop>
Message-ID: <CFAB1904-35FF-4D19-A181-21E4463091CC@it-loops.com>


On Mar 14, 2007, at 21:51, Edward K. Ream wrote:

> I've been getting errors when trying to build after downloading from
> svn.  I'm running Ubuntu on an 86 laptop.
> I think I've installed Pyrex correctly, but maybe not.
> Can anyone explain what I should do next?  Thanks.
>
<snip>

Ok, this is a "works-for-me"-recipe since I had problems with Pyrex  
as well.

* Remove every installation of Pyrex you already installed just to be  
on the save side
* Create an external definition in your repository and link it to the  
Pyrex version on codespeak.net

	In your lxml checkout directory call

		svn propedit svn:externals .

	and add the following line

		Pyrex http://codespeak.net/svn/lxml/pyrex/Pyrex

* Do a "svn up" again to checkout the Pyrex version to your local  
repository
* Try building lxml again.

I hope this helps.

Kind regards,
Michael

From stefan_ml at behnel.de  Thu Mar 15 15:05:40 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 15 Mar 2007 15:05:40 +0100
Subject: [lxml-dev] Errors while building from trunk
In-Reply-To: <1173905467.20698.4.camel@edreamleo-laptop>
References: <1173905467.20698.4.camel@edreamleo-laptop>
Message-ID: <45F952B4.4030607@behnel.de>


Edward K. Ream wrote:
> I've been getting errors when trying to build after downloading from
> svn.  I'm running Ubuntu on an 86 laptop.
> I think I've installed Pyrex correctly, but maybe not.
> Can anyone explain what I should do next?  Thanks.

Hi,

the problem is: the current official Pyrex release (0.9.5.1a) is both a)
broken and b) not capable of building lxml. Most likely, the next version will
be fixed wrt. a) but b) will stay for a while.

Please use the patched Pyrex as Michael suggests.

Stefan

From srichter at cosmos.phy.tufts.edu  Thu Mar 15 19:42:14 2007
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Thu, 15 Mar 2007 14:42:14 -0400
Subject: [lxml-dev] Parsing Information
Message-ID: <200703151442.15024.srichter@cosmos.phy.tufts.edu>

Hi all,

I have recently reimplemented RML (Reportlab's XML format to generate PDFs) 
using lxml. All works well.

Now, I would like to give my users some more information when an error occurs. 
For a pure XML parsing error, everything is fine (though I found the failure 
points hard to interpret at times). But what if the XML parses correctly, but 
while working with the element tree an error occurs? In this case I would 
like to tell the user not only the error message, but also the line/column 
and filename of point of failure.

Ideally I would have the filename, start row and start column of each element 
available as part of the etree Element. I have tried to find this information 
or hooks for it.unsuccessfully.

Could someone help me out here?

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From stefan_ml at behnel.de  Fri Mar 16 16:49:58 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 16 Mar 2007 16:49:58 +0100
Subject: [lxml-dev] finding the line number of a parsed element
In-Reply-To: <200703151442.15024.srichter@cosmos.phy.tufts.edu>
References: <200703151442.15024.srichter@cosmos.phy.tufts.edu>
Message-ID: <45FABCA6.7030700@behnel.de>

Hi,

Stephan Richter wrote:
> I have recently reimplemented RML (Reportlab's XML format to generate PDFs) 
> using lxml. All works well.

Interesting. Any chance you could provide a link?


> Now, I would like to give my users some more information when an error occurs. 
> For a pure XML parsing error, everything is fine (though I found the failure 
> points hard to interpret at times). But what if the XML parses correctly, but 
> while working with the element tree an error occurs? In this case I would 
> like to tell the user not only the error message, but also the line/column 
> and filename of point of failure.

This sounds a lot like a problem you could try to solve with validation.


> Ideally I would have the filename, start row and start column of each element 
> available as part of the etree Element. I have tried to find this information 
> or hooks for it.unsuccessfully.

There is no API for it, but internally, we have this information for parsed
trees, at least the line number - note that exceptions contain the line number
already. So we could easily add a property "_line" to elements that returns
the line number at which the element was parsed (*if* it was parsed). I don't
like the fact so much that libxml2 puts a zero there if the node was created
by hand, but I assume that is not too much of a problem either.

I personally prefer "_line" over "line", as this only applies to parsed
elements, not all of them, so this is more of a half-working API.
Additionally, any additional attribute there goes off the list of children
accessible in objectify.

We could also consider adding an external utility module to provide helpers
like this that are not really worth poluting the API. Something like

lxml.tools.lineof(element)

But maybe that's just overkill...

Any comments?

Stefan


From srichter at cosmos.phy.tufts.edu  Fri Mar 16 20:08:41 2007
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Fri, 16 Mar 2007 15:08:41 -0400
Subject: [lxml-dev] finding the line number of a parsed element
In-Reply-To: <45FABCA6.7030700@behnel.de>
References: <200703151442.15024.srichter@cosmos.phy.tufts.edu>
	<45FABCA6.7030700@behnel.de>
Message-ID: <200703161508.41811.srichter@cosmos.phy.tufts.edu>

On Friday 16 March 2007 11:49, Stefan Behnel wrote:
> Hi,
>
> Stephan Richter wrote:
> > I have recently reimplemented RML (Reportlab's XML format to generate
> > PDFs) using lxml. All works well.
>
> Interesting. Any chance you could provide a link?

Sure: http://svn.zope.org/z3c.rml/trunk/src/z3c/rml/

> > Now, I would like to give my users some more information when an error
> > occurs. For a pure XML parsing error, everything is fine (though I found
> > the failure points hard to interpret at times). But what if the XML
> > parses correctly, but while working with the element tree an error
> > occurs? In this case I would like to tell the user not only the error
> > message, but also the line/column and filename of point of failure.
>
> This sounds a lot like a problem you could try to solve with validation.

No, I cannot, since some stuff cannot be decided until I do Python calls. For 
example, I look up colors by names, but this is not a static list.

> > Ideally I would have the filename, start row and start column of each
> > element available as part of the etree Element. I have tried to find this
> > information or hooks for it.unsuccessfully.
>
> There is no API for it, but internally, we have this information for parsed
> trees, at least the line number - note that exceptions contain the line
> number already. So we could easily add a property "_line" to elements that
> returns the line number at which the element was parsed (*if* it was
> parsed). I don't like the fact so much that libxml2 puts a zero there if
> the node was created by hand, but I assume that is not too much of a
> problem either.

I think a zero is no problem. None would be better. :-)

> I personally prefer "_line" over "line", as this only applies to parsed
> elements, not all of them, so this is more of a half-working API.

That would be perfect.

> Additionally, any additional attribute there goes off the list of children
> accessible in objectify.

I don't understand this sentence. :-)

> We could also consider adding an external utility module to provide helpers
> like this that are not really worth poluting the API. Something like
>
> lxml.tools.lineof(element)

That would be icing on the cake; either way is fine, If you consider such a 
tool, I would probably call it "parseInfo" or so, where maybe the filename, 
endline, and column info is available too.

> Any comments?

How fast can you do this? :-)

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From stefan_ml at behnel.de  Fri Mar 16 20:29:13 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 16 Mar 2007 20:29:13 +0100
Subject: [lxml-dev] finding the line number of a parsed element
In-Reply-To: <200703161508.41811.srichter@cosmos.phy.tufts.edu>
References: <200703151442.15024.srichter@cosmos.phy.tufts.edu>
	<45FABCA6.7030700@behnel.de>
	<200703161508.41811.srichter@cosmos.phy.tufts.edu>
Message-ID: <45FAF009.3020709@behnel.de>

Hi,

Stephan Richter wrote:
>>> Ideally I would have the filename, start row and start column of each
>>> element available as part of the etree Element. I have tried to find this
>>> information or hooks for it.unsuccessfully.
>> There is no API for it, but internally, we have this information for parsed
>> trees, at least the line number - note that exceptions contain the line
>> number already. So we could easily add a property "_line" to elements that
>> returns the line number at which the element was parsed (*if* it was
>> parsed). I don't like the fact so much that libxml2 puts a zero there if
>> the node was created by hand, but I assume that is not too much of a
>> problem either.
> 
> I think a zero is no problem. None would be better. :-)

Problem is: how would you distinguish 'parsed in line 0' from 'not parsed at
all' in this case?


>> Additionally, any additional attribute there goes off the list of children
>> accessible in objectify.
> 
> I don't understand this sentence. :-)

I was talking about lxml.objectify that uses Python object attributes to
access XML element children (sort of like data binding to an object tree).
Every name that is used as a Python attribute of the _Element class shadows
XML children that would otherwise be accessible under that name. Check out the
objectify docs to see what I mean.


>> We could also consider adding an external utility module to provide helpers
>> like this that are not really worth poluting the API. Something like
>>
>> lxml.tools.lineof(element)
> 
> That would be icing on the cake; either way is fine, If you consider such a 
> tool, I would probably call it "parseInfo" or so, where maybe the filename, 
> endline, and column info is available too.

The filename would be available from documents, I don't know what you mean
with "endline" (the last line number?) and the parser column is not available
from libxml2 (at least not once the parser has passed the element...)

So, what about an 'lxml.docinfo' module then that provides this kind of info
helper functions? I was never really happy with the DocInfo class, so it might
be a good idea to just move this kind of information to a separate module that
people can use if they need it.

I'm pretty confident that there is even more that we could provide at that
level. And it would help us in keeping the already bigger-than-big-enough API
of lxml at least a little smaller.

Stefan

From nathan at yergler.net  Sat Mar 17 01:31:13 2007
From: nathan at yergler.net (Nathan R. Yergler)
Date: Fri, 16 Mar 2007 20:31:13 -0400
Subject: [lxml-dev] Overriding whitespace normalization under XSLT
Message-ID: <bf7b44d50703161731g3fc789ao8db51564987f1ead@mail.gmail.com>

I'm not sure this is really the right list for this, but we're using
lxml, and I'm hoping that someone will have the requisite expertise to
enlighten me.

Creative Commons has an XSLT transformation we use for generating
license engine output; it's divided into a few templates, and one
final template that assembles the pieces.  The problem is with respect
to the "img" tag in the human readable copy-n-paste output.  Here's an
excerpt from the transform:

	<xsl:template name="html">
		<xsl:param name="license-uri"/>
		<xsl:param name="license-name"/>
		<xsl:param name="rdf"/>
		<xsl:variable name="license-button">
			<xsl:choose>
				<xsl:when test="contains($license-uri,'GPL')">http://i.creativecommons.org/l<xsl:value-of
select="substring-after($license-uri,'http://creativecommons.org/licenses')"/>88x62.png</xsl:when>
				<xsl:otherwise>http://i.creativecommons.org/l<xsl:value-of
select="substring-after($license-uri,'http://creativecommons.org/licenses')"/>88x31.png</xsl:otherwise>
			</xsl:choose>
		</xsl:variable>
		<a rel="license" href="{$license-uri}"><img alt="Creative Commons
License" style="border-width:0" src="{$license-button}" /></a><br/>
		<xsl:call-template name="thiswork">
			<xsl:with-param name="license_name"
					select="$license-name" />
			<xsl:with-param name="license_url"
					select="$license-uri" />
		</xsl:call-template>

	</xsl:template>

The part that's problematic is this line:

		<a rel="license" href="{$license-uri}"><img alt="Creative Commons
License" style="border-width:0" src="{$license-button}" /></a><br/>

Note that there is a space between the closing quote of the src
attribute on the image tag and the "/>" closing bracket.  When we
process the transform, we consistently end up with

		<a rel="license" href="..."><img alt="Creative Commons License"
style="border-width:0" src="..."/></a><br/>

(note the space has been removed)

I've done some experiments and it seems any amount of whitespace
(including carriage returns) is collapsed during processing.  This may
be valid markup (I'm not certain), but some consumers of our
copy-and-paste markup barf when that space doesn't exist.

I feel like I've reached the end of my XSLT expertise, so does anyone
have any idea a) how to maintain that whitespace or b) whom to ask who
might know?

Thanks, and thanks for lxml,

Nathan

-----
Nathan R. Yergler
Senior Software Engineer
Creative Commons

http://wiki.creativecommons.org/User:NathanYergler

From stefan_ml at behnel.de  Sat Mar 17 06:33:10 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 17 Mar 2007 06:33:10 +0100
Subject: [lxml-dev] Overriding whitespace normalization under XSLT
In-Reply-To: <bf7b44d50703161731g3fc789ao8db51564987f1ead@mail.gmail.com>
References: <bf7b44d50703161731g3fc789ao8db51564987f1ead@mail.gmail.com>
Message-ID: <45FB7D96.8080908@behnel.de>

Hi,

CC, hum? We should start writing up a hall of fame of organisations using lxml. :)


Nathan R. Yergler wrote:
> I'm not sure this is really the right list for this, but we're using
> lxml, and I'm hoping that someone will have the requisite expertise to
> enlighten me.

It looks a bit more like an XSLT question to me.


> Creative Commons has an XSLT transformation we use for generating
> license engine output; it's divided into a few templates, and one
> final template that assembles the pieces.  The problem is with respect
> to the "img" tag in the human readable copy-n-paste output.

You did not say what you are actually generating. XHTML? HTML? I assume it's
unindented XHTML from your problem statement. Would generating indented HTML
solve it?

  <xsl:output method="html" indent="yes" />


> The part that's problematic is this line:
> 
> 		<a rel="license" href="{$license-uri}"><img alt="Creative Commons
> License" style="border-width:0" src="{$license-button}" /></a><br/>
> 
> Note that there is a space between the closing quote of the src
> attribute on the image tag and the "/>" closing bracket.  When we
> process the transform, we consistently end up with
> 
> 		<a rel="license" href="..."><img alt="Creative Commons License"
> style="border-width:0" src="..."/></a><br/>
> 
> (note the space has been removed)

That's perfectly well-formed XHTML. But rumour has it that some browsers can't
handle that. It's just not old-style HTML-ish enough.

If you feel like it, you can also target UTF-8 as encoding in XSLT, then
serialise it to a string and do the replacement by hand ('/>' -> ' />') before
sending the result somewhere else. That's a hands-on approach, but if you want
to generate backwards compatible XHTML, that's one way to get closer.

Stefan

From faassen at startifact.com  Sat Mar 17 11:19:02 2007
From: faassen at startifact.com (Martijn Faassen)
Date: Sat, 17 Mar 2007 11:19:02 +0100
Subject: [lxml-dev] finding the line number of a parsed element
In-Reply-To: <45FABCA6.7030700@behnel.de>
References: <200703151442.15024.srichter@cosmos.phy.tufts.edu>
	<45FABCA6.7030700@behnel.de>
Message-ID: <45FBC096.8030802@startifact.com>

Stefan Behnel wrote:
[snip]
> I personally prefer "_line" over "line", as this only applies to parsed
> elements, not all of them, so this is more of a half-working API.
> Additionally, any additional attribute there goes off the list of children
> accessible in objectify.

I really don't like _line. The underscore in a strong Python convention 
indicates "implementation details", and code external to a class should 
*not* be touching attributes which start with an underscore unless it 
knows it's going to do something evil. Initial underscores are not meant 
to indicate half-working APIs or something.

Accessing _line is not evil, it's just not guaranteed to be correct if 
you manipulate a parsed tree, or create a tree from scratch. This should 
simply be documented.

(Are we sure it's half-working, anyway? Does libxml2 start counting 
lines at 0 or at 1? If at 1 then 0 is entirely unambiguous and we may be 
able to return None instead reliably)

Anyway, to conclude, I think 'line' is just fine - I believe that's a 
complete API, if only not a great one if we can't distinguish between 
line 0 and "no line known".

Regards,

Martijn


From faassen at startifact.com  Sat Mar 17 11:24:29 2007
From: faassen at startifact.com (Martijn Faassen)
Date: Sat, 17 Mar 2007 11:24:29 +0100
Subject: [lxml-dev] finding the line number of a parsed element
In-Reply-To: <45FAF009.3020709@behnel.de>
References: <200703151442.15024.srichter@cosmos.phy.tufts.edu>	<45FABCA6.7030700@behnel.de>	<200703161508.41811.srichter@cosmos.phy.tufts.edu>
	<45FAF009.3020709@behnel.de>
Message-ID: <etgfkt$p8g$1@sea.gmane.org>

Stefan Behnel wrote:
[snip]
>>> We could also consider adding an external utility module to provide helpers
>>> like this that are not really worth poluting the API. Something like
>>>
>>> lxml.tools.lineof(element)
>> That would be icing on the cake; either way is fine, If you consider such a 
>> tool, I would probably call it "parseInfo" or so, where maybe the filename, 
>> endline, and column info is available too.
> 
> The filename would be available from documents, I don't know what you mean
> with "endline" (the last line number?) and the parser column is not available
> from libxml2 (at least not once the parser has passed the element...)
> 
> So, what about an 'lxml.docinfo' module then that provides this kind of info
> helper functions? I was never really happy with the DocInfo class, so it might
> be a good idea to just move this kind of information to a separate module that
> people can use if they need it.
> 
> I'm pretty confident that there is even more that we could provide at that
> level. And it would help us in keeping the already bigger-than-big-enough API
> of lxml at least a little smaller.

I really think this is overkill. I think an attribute 'line' is fine. 
lxml has an explicit mission to take ElementTree and expand its API with 
more functionality. We do this with namespaces, we do this with xpath, 
and why wouldn't we do this with line numbers? I don't understand how 
line numbers are different.

By the way, even if 0 is both used for line 0 and elements that have an 
unknown line number, it seems actually possible to distinguish between 
the two! What would be required if 'line 0' is found is to go backwards 
in document order, until a textnode is found that contains a newline. If 
so, the answer is None. If not (and this can be done quickly), the 
answer is 0. Oh, possibly even more efficient would be to look for 
*another* node. If this node contains a line number that's non-0, you 
know you can return None. That would make the 'line' API pretty reliable.

Regards,

Martijn


From nathan at yergler.net  Sat Mar 17 13:01:07 2007
From: nathan at yergler.net (Nathan R. Yergler)
Date: Sat, 17 Mar 2007 08:01:07 -0400
Subject: [lxml-dev] Overriding whitespace normalization under XSLT
In-Reply-To: <45FB7D96.8080908@behnel.de>
References: <bf7b44d50703161731g3fc789ao8db51564987f1ead@mail.gmail.com>
	<45FB7D96.8080908@behnel.de>
Message-ID: <bf7b44d50703170501g4a2446c0k2ce79fbb629783c3@mail.gmail.com>

On 3/17/07, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Hi,
>
> CC, hum? We should start writing up a hall of fame of organisations using lxml. :)
>
>
> Nathan R. Yergler wrote:
> > I'm not sure this is really the right list for this, but we're using
> > lxml, and I'm hoping that someone will have the requisite expertise to
> > enlighten me.
>
> It looks a bit more like an XSLT question to me.
>

It absolutely is; I just wasn't finding anything in the spec to guide
me, and hoped someone on here had more experience with it than I.

>
> > Creative Commons has an XSLT transformation we use for generating
> > license engine output; it's divided into a few templates, and one
> > final template that assembles the pieces.  The problem is with respect
> > to the "img" tag in the human readable copy-n-paste output.
>
> You did not say what you are actually generating. XHTML? HTML? I assume it's
> unindented XHTML from your problem statement. Would generating indented HTML
> solve it?
>
>   <xsl:output method="html" indent="yes" />
>

We're actually generating it with method="xml", indent="yes"; the XSLT
that handles this generates a chunk of XML, one element of which is
the copy-and-paste HTML that the user sees when they choose a license.

>
> > The part that's problematic is this line:
> >
> >               <a rel="license" href="{$license-uri}"><img alt="Creative Commons
> > License" style="border-width:0" src="{$license-button}" /></a><br/>
> >
> > Note that there is a space between the closing quote of the src
> > attribute on the image tag and the "/>" closing bracket.  When we
> > process the transform, we consistently end up with
> >
> >               <a rel="license" href="..."><img alt="Creative Commons License"
> > style="border-width:0" src="..."/></a><br/>
> >
> > (note the space has been removed)
>
> That's perfectly well-formed XHTML. But rumour has it that some browsers can't
> handle that. It's just not old-style HTML-ish enough.
>
> If you feel like it, you can also target UTF-8 as encoding in XSLT, then
> serialise it to a string and do the replacement by hand ('/>' -> ' />') before
> sending the result somewhere else. That's a hands-on approach, but if you want
> to generate backwards compatible XHTML, that's one way to get closer.
>

Thanks; I had sort of stopped myself from thinking about how to do it
that way, hoping there was just a setting to tweak or attribute to set
to bend it to my will.  But I may be forced down that road...

> Stefan
>

From faassen at startifact.com  Sat Mar 17 11:19:02 2007
From: faassen at startifact.com (Martijn Faassen)
Date: Sat, 17 Mar 2007 11:19:02 +0100
Subject: [lxml-dev] finding the line number of a parsed element
In-Reply-To: <45FABCA6.7030700@behnel.de>
References: <200703151442.15024.srichter@cosmos.phy.tufts.edu>
	<45FABCA6.7030700@behnel.de>
Message-ID: <45FBC096.8030802@startifact.com>

Stefan Behnel wrote:
[snip]
> I personally prefer "_line" over "line", as this only applies to parsed
> elements, not all of them, so this is more of a half-working API.
> Additionally, any additional attribute there goes off the list of children
> accessible in objectify.

I really don't like _line. The underscore in a strong Python convention 
indicates "implementation details", and code external to a class should 
*not* be touching attributes which start with an underscore unless it 
knows it's going to do something evil. Initial underscores are not meant 
to indicate half-working APIs or something.

Accessing _line is not evil, it's just not guaranteed to be correct if 
you manipulate a parsed tree, or create a tree from scratch. This should 
simply be documented.

(Are we sure it's half-working, anyway? Does libxml2 start counting 
lines at 0 or at 1? If at 1 then 0 is entirely unambiguous and we may be 
able to return None instead reliably)

Anyway, to conclude, I think 'line' is just fine - I believe that's a 
complete API, if only not a great one if we can't distinguish between 
line 0 and "no line known".

Regards,

Martijn

From leebrown at leebrown.org  Sat Mar 17 14:10:19 2007
From: leebrown at leebrown.org (Lee Brown)
Date: Sat, 17 Mar 2007 09:10:19 -0400
Subject: [lxml-dev] Overriding whitespace normalization under XSLT
In-Reply-To: <45FB7D96.8080908@behnel.de>
References: <bf7b44d50703161731g3fc789ao8db51564987f1ead@mail.gmail.com>
	<45FB7D96.8080908@behnel.de>
Message-ID: <012001c76895$9d4662c0$0301a8c0@uberbox>

Greetings!

With regards to the snippet below, the "missing" space is valid XHTML but
not valid HTML according specifications preceding HTML 4.01.
Provided that it won't break your consumer's browser agents, setting the
DOCTYPE to HTML 4.01 Strict or to XHTML 1.0 Strict and omitting the leading
XML declaration should cause this to render correctly in most modern
browsers.

If you must support older browsers, try adding a closing </img> tag.
Technically, that's invalid HTML as well, but most of the older browsers
will parse it anyway.

Best Regards,
Lee E. Brown
(leebrown at leebrown.org)

-----Original Message-----
From: lxml-dev-bounces at codespeak.net [mailto:lxml-dev-bounces at codespeak.net]
On Behalf Of Stefan Behnel
Sent: Saturday, March 17, 2007 1:33 AM
To: Nathan R. Yergler
Cc: lxml-dev at codespeak.net
Subject: Re: [lxml-dev] Overriding whitespace normalization under XSLT

Nathan R. Yergler wrote:
> The part that's problematic is this line:
> 
> 		<a rel="license" href="{$license-uri}"><img alt="Creative
Commons 
> License" style="border-width:0" src="{$license-button}" /></a><br/>
> 
> Note that there is a space between the closing quote of the src 
> attribute on the image tag and the "/>" closing bracket.  When we 
> process the transform, we consistently end up with
> 
> 		<a rel="license" href="..."><img alt="Creative Commons
License"
> style="border-width:0" src="..."/></a><br/>
> 
> (note the space has been removed)

That's perfectly well-formed XHTML. But rumour has it that some browsers
can't handle that. It's just not old-style HTML-ish enough.

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


From nathan at yergler.net  Tue Mar 20 20:34:14 2007
From: nathan at yergler.net (Nathan R. Yergler)
Date: Tue, 20 Mar 2007 15:34:14 -0400
Subject: [lxml-dev] Overriding whitespace normalization under XSLT
In-Reply-To: <012001c76895$9d4662c0$0301a8c0@uberbox>
References: <bf7b44d50703161731g3fc789ao8db51564987f1ead@mail.gmail.com>
	<45FB7D96.8080908@behnel.de> <012001c76895$9d4662c0$0301a8c0@uberbox>
Message-ID: <bf7b44d50703201234k51296031nd8a34ed062bf2551@mail.gmail.com>

Thanks to everyone for their suggestions.  Sounds like there's not
some secret knob to turn (or at least not one that the group knows
about).  I did find that passing the result through tidy formats it
correctly, so that's the interim fix for me.

Thanks,

Nathan


On 3/17/07, Lee Brown <leebrown at leebrown.org> wrote:
> Greetings!
>
> With regards to the snippet below, the "missing" space is valid XHTML but
> not valid HTML according specifications preceding HTML 4.01.
> Provided that it won't break your consumer's browser agents, setting the
> DOCTYPE to HTML 4.01 Strict or to XHTML 1.0 Strict and omitting the leading
> XML declaration should cause this to render correctly in most modern
> browsers.
>
> If you must support older browsers, try adding a closing </img> tag.
> Technically, that's invalid HTML as well, but most of the older browsers
> will parse it anyway.
>
> Best Regards,
> Lee E. Brown
> (leebrown at leebrown.org)
>
> -----Original Message-----
> From: lxml-dev-bounces at codespeak.net [mailto:lxml-dev-bounces at codespeak.net]
> On Behalf Of Stefan Behnel
> Sent: Saturday, March 17, 2007 1:33 AM
> To: Nathan R. Yergler
> Cc: lxml-dev at codespeak.net
> Subject: Re: [lxml-dev] Overriding whitespace normalization under XSLT
>
> Nathan R. Yergler wrote:
> > The part that's problematic is this line:
> >
> >               <a rel="license" href="{$license-uri}"><img alt="Creative
> Commons
> > License" style="border-width:0" src="{$license-button}" /></a><br/>
> >
> > Note that there is a space between the closing quote of the src
> > attribute on the image tag and the "/>" closing bracket.  When we
> > process the transform, we consistently end up with
> >
> >               <a rel="license" href="..."><img alt="Creative Commons
> License"
> > style="border-width:0" src="..."/></a><br/>
> >
> > (note the space has been removed)
>
> That's perfectly well-formed XHTML. But rumour has it that some browsers
> can't handle that. It's just not old-style HTML-ish enough.
>
> Stefan
> _______________________________________________
> lxml-dev mailing list
> lxml-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/lxml-dev
>
>

From srichter at cosmos.phy.tufts.edu  Tue Mar 20 23:20:00 2007
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Tue, 20 Mar 2007 18:20:00 -0400
Subject: [lxml-dev] Custom Elements
Message-ID: <200703201820.01738.srichter@cosmos.phy.tufts.edu>

Hi everyone,

I did some initial trials with creating custom elements and the following 
script works as expected:

from lxml import etree

class Directive1(etree.ElementBase):
    foo = '1'

class Directive2(etree.ElementBase):
    foo = '2'

class DirectiveLookup(etree.CustomElementClassLookup):

    def lookup(self, type, doc, namespace, name):
        import pdb; pdb.set_trace()
        if name == 'foo1':
            return Directive1
        elif name == 'foo2':
            return Directive2
        return None

parser = etree.XMLParser()
parser.setElementClassLookup(DirectiveLookup())

elm = etree.fromstring(
    '<bar><foo1 /><foo2 /><foo /></bar>', parser)
# Do inspection
import pdb; pdb.set_trace()

However, in my case, the lookup also depends on the parent element in my case, 
because a tag with the same name can have different meanings in different 
contexts. (Don't ask, this is a specification requirement of RML. ;-)

So here my question: How do I access the parent element?

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From stefan_ml at behnel.de  Tue Mar 20 23:14:33 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Tue, 20 Mar 2007 23:14:33 +0100
Subject: [lxml-dev] finding the line number of a parsed element
In-Reply-To: <45FABCA6.7030700@behnel.de>
References: <200703151442.15024.srichter@cosmos.phy.tufts.edu>
	<45FABCA6.7030700@behnel.de>
Message-ID: <46005CC9.9010803@behnel.de>

Hi everyone,

Stefan Behnel wrote:
> There is no API for it, but internally, we have this information for parsed
> trees, at least the line number - note that exceptions contain the line number
> already. So we could easily add a property "_line" to elements that returns
> the line number at which the element was parsed (*if* it was parsed). I don't
> like the fact so much that libxml2 puts a zero there

Sorry for the FUD. I just checked and found that libxml2 is actually smarter
than I remembered from the last time I looked at this. It gives you a 1 for
the first line in the parser. So it's actually easy to distinguish between "no
line known" and "parsed in line x".

That makes "el.line" a perfectly working API. I called it "el.sourceline"
though, to make it clearer that only parsing XML source produces it, not
creating Elements in any other way. I also made it writable, just in case
someone wants to add line numbers to generated trees or something.

I'll commit it to the trunk. Note that it's not yet supported in objectify for
now, which requires explicit special casing.

Have fun,
Stefan


From stefan_ml at behnel.de  Wed Mar 21 09:13:42 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 21 Mar 2007 09:13:42 +0100
Subject: [lxml-dev] Overriding whitespace normalization under XSLT
In-Reply-To: <I00253j2KJWoep.1.RZmta@mi-ob.rzone.de>
References: <bf7b44d50703161731g3fc789ao8db51564987f1ead@mail.gmail.com>	
	<45FB7D96.8080908@behnel.de>
	<012001c76895$9d4662c0$0301a8c0@uberbox>
	<I00253j2KJWoep.1.RZmta@mi-ob.rzone.de>
Message-ID: <4600E936.7010103@behnel.de>



Nathan R. Yergler schrieb:
> Thanks to everyone for their suggestions.  Sounds like there's not
> some secret knob to turn (or at least not one that the group knows
> about).  I did find that passing the result through tidy formats it
> correctly, so that's the interim fix for me.

The suggestion by Lee Brown could be implemented by canonicalising
(c14n_write) the XML output, in case you want to drop a dependency here.

Stefan


> On 3/17/07, Lee Brown <leebrown at leebrown.org> wrote:
>> Greetings!
>>
>> With regards to the snippet below, the "missing" space is valid XHTML but
>> not valid HTML according specifications preceding HTML 4.01.
>> Provided that it won't break your consumer's browser agents, setting the
>> DOCTYPE to HTML 4.01 Strict or to XHTML 1.0 Strict and omitting the
>> leading
>> XML declaration should cause this to render correctly in most modern
>> browsers.
>>
>> If you must support older browsers, try adding a closing </img> tag.
>> Technically, that's invalid HTML as well, but most of the older browsers
>> will parse it anyway.
>>
>> Best Regards,
>> Lee E. Brown
>> (leebrown at leebrown.org)
>>
>> -----Original Message-----
>> From: lxml-dev-bounces at codespeak.net
>> [mailto:lxml-dev-bounces at codespeak.net]
>> On Behalf Of Stefan Behnel
>> Sent: Saturday, March 17, 2007 1:33 AM
>> To: Nathan R. Yergler
>> Cc: lxml-dev at codespeak.net
>> Subject: Re: [lxml-dev] Overriding whitespace normalization under XSLT
>>
>> Nathan R. Yergler wrote:
>> > The part that's problematic is this line:
>> >
>> >               <a rel="license" href="{$license-uri}"><img alt="Creative
>> Commons
>> > License" style="border-width:0" src="{$license-button}" /></a><br/>
>> >
>> > Note that there is a space between the closing quote of the src
>> > attribute on the image tag and the "/>" closing bracket.  When we
>> > process the transform, we consistently end up with
>> >
>> >               <a rel="license" href="..."><img alt="Creative Commons
>> License"
>> > style="border-width:0" src="..."/></a><br/>
>> >
>> > (note the space has been removed)
>>
>> That's perfectly well-formed XHTML. But rumour has it that some browsers
>> can't handle that. It's just not old-style HTML-ish enough.
>>
>> Stefan
>> _______________________________________________
>> lxml-dev mailing list
>> lxml-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/lxml-dev
>>
>>

From stefan_ml at behnel.de  Wed Mar 21 09:23:00 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 21 Mar 2007 09:23:00 +0100
Subject: [lxml-dev] Custom Elements
In-Reply-To: <9011dbj2KMJL1X.1.RZmta@mi-ob.rzone.de>
References: <9011dbj2KMJL1X.1.RZmta@mi-ob.rzone.de>
Message-ID: <4600EB64.4070107@behnel.de>


Stephan Richter wrote:
> class DirectiveLookup(etree.CustomElementClassLookup):
> 
>     def lookup(self, type, doc, namespace, name):
>         import pdb; pdb.set_trace()
>         if name == 'foo1':
>             return Directive1
>         elif name == 'foo2':
>             return Directive2
>         return None
> 
> However, in my case, the lookup also depends on the parent element in my case, 
> because a tag with the same name can have different meanings in different 
> contexts. (Don't ask, this is a specification requirement of RML. ;-)
> 
> So here my question: How do I access the parent element?

That's a tricky one. Providing the parent at the Python level would require
its instantiation as Element, i.e. another lookup of the target class. So we
end up with a recursive chicken-and-egg problem.

Providing its tag name might be enough, but then, others might need to check
its attributes or other parts of the tree, too - no end in sight.

So, all I can suggest is to write a separate Pyrex module against etree's
public C-API to provide a C-implemented lookup mechanism that works on the
libxml2 tree. You can take a look at objectify's ObjectifyElementClassLookup
implementation to see how this can be done. It's actually not difficult at
all, but you'd have to write it in Pyrex.

Another possible solution is to actually use the same class, but with a
different configuration based on its parent. You can do the setup in
Element._init().

Hope it helps,
Stefan

From srichter at cosmos.phy.tufts.edu  Wed Mar 21 16:30:59 2007
From: srichter at cosmos.phy.tufts.edu (Stephan Richter)
Date: Wed, 21 Mar 2007 11:30:59 -0400
Subject: [lxml-dev] finding the line number of a parsed element
In-Reply-To: <46005CC9.9010803@behnel.de>
References: <200703151442.15024.srichter@cosmos.phy.tufts.edu>
	<45FABCA6.7030700@behnel.de> <46005CC9.9010803@behnel.de>
Message-ID: <200703211130.59939.srichter@cosmos.phy.tufts.edu>

On Tuesday 20 March 2007 18:14, Stefan Behnel wrote:
> I'll commit it to the trunk. Note that it's not yet supported in objectify
> for now, which requires explicit special casing.

Cool, I'll check out the trunk then.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training

From stefan_ml at behnel.de  Wed Mar 21 20:22:24 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 21 Mar 2007 20:22:24 +0100
Subject: [lxml-dev] Custom Elements
In-Reply-To: <4011c2j2L8LK8n.1.RZmta@mi-ob.rzone.de>
References: <9011dbj2KMJL1X.1.RZmta@mi-ob.rzone.de>
	<4011c2j2L8LK8n.1.RZmta@mi-ob.rzone.de>
Message-ID: <460185F0.7070001@behnel.de>

Hi again,

Stefan Behnel wrote:
> Stephan Richter wrote:
>> class DirectiveLookup(etree.CustomElementClassLookup):
>>
>>     def lookup(self, type, doc, namespace, name):
>>         import pdb; pdb.set_trace()
>>         if name == 'foo1':
>>             return Directive1
>>         elif name == 'foo2':
>>             return Directive2
>>         return None
>>
>> However, in my case, the lookup also depends on the parent element in my case, 
>> because a tag with the same name can have different meanings in different 
>> contexts. (Don't ask, this is a specification requirement of RML. ;-)
>>
>> So here my question: How do I access the parent element?
> 
> That's a tricky one.

Correcting myself: wasn't that tricky after all. The trunk now has a new
module called "lxml.pyclasslookup" that provides a new lookup mechanism:

PythonElementClassLookup

You can subclass it and implement the method "lookup(self, doc, element)" to
find a suitable element class for "element". This last argument is an instance
of a lightweight Element proxy that implements most of the API of the standard
Element class of lxml.etree. The main differences are the lack of iteration
support and the bigger things like XPath etc. Just take that object, traverse
and analyse the tree as you see fit and return the element class that suits
your needs.

Have fun,
Stefan


From lee.brown at elecdev.com  Thu Mar 22 15:22:42 2007
From: lee.brown at elecdev.com (Lee Brown)
Date: Thu, 22 Mar 2007 09:22:42 -0500
Subject: [lxml-dev] Overriding whitespace normalization under XSLT
In-Reply-To: <4600E936.7010103@behnel.de>
Message-ID: <200703221322.l2MDMd0e028979@mail.elecdev.com>

Greetings!

There's one problem with using write_c14n(): it strips the DOCTYPE declaration
if present.

I've run into a problem similar to Nathan's when using AJAX to dump preformatted
XHTML into the innerHTML property of a document element.  The preformatted XHTML
must already be in the cannonical form; if not, bad things happen.

In my Apache/ModPython setup, I have an output filter that transforms all
outbound XML into XHTML using XSLT (all with lxml, of course).  So I tried using
write_c14n on the XSLT result tree to solve the above problem, but the missing
DOCTYPE declaration breaks my web pages.

Just for grins and giggles, here's how to force a closing tag on any HTML
element in XSLT:

	<tagname><xsl:text> </xsl:text><tagname>

Using the <xsl:text> element forces non-ignorable whitespace between the
element's opening and closing tags, thus preserving the closing tag in the
output.  Yes, it's rude, crude, and ugly, but it gets the job done without
adding any dependencies to my code.

-----Original Message-----
From: lxml-dev-bounces at codespeak.net [mailto:lxml-dev-bounces at codespeak.net] On
Behalf Of Stefan Behnel
Sent: Wednesday, March 21, 2007 3:14 AM
To: Nathan R. Yergler
Cc: lxml-dev at codespeak.net
Subject: Re: [lxml-dev] Overriding whitespace normalization under XSLT



Nathan R. Yergler schrieb:
> Thanks to everyone for their suggestions.  Sounds like there's not 
> some secret knob to turn (or at least not one that the group knows 
> about).  I did find that passing the result through tidy formats it 
> correctly, so that's the interim fix for me.

The suggestion by Lee Brown could be implemented by canonicalising
(c14n_write) the XML output, in case you want to drop a dependency here.

Stefan




From lee.brown at elecdev.com  Thu Mar 22 20:43:32 2007
From: lee.brown at elecdev.com (Lee Brown)
Date: Thu, 22 Mar 2007 14:43:32 -0500
Subject: [lxml-dev] Adding a Stylesheet PI when creating new XML documents
Message-ID: <200703221843.l2MIhS0e002648@mail.elecdev.com>

Greetings!

Parsing an XSLT stylesheet from an xml-stylesheet PI is working just fine, but
now I'm trying to add an xml-stylesheet PI to a new XML tree created from within
lxml.  I've looked back through the list traffic and done some code
introspection but I can't find anything.

Did we ever decide upon / create an API for adding a stylesheet PI to a new
tree?

Best Regards,
Lee E. Brown
Electronics Development Corporation
9055-F Guilford Road
Columbia MD 21046
410-312-6678
lee.brown at elecdev.com
www.elecdev.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/lxml-dev/attachments/20070322/a94190af/attachment.htm 

From stefan_ml at behnel.de  Thu Mar 22 20:22:35 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 22 Mar 2007 20:22:35 +0100
Subject: [lxml-dev] Adding a Stylesheet PI when creating new XML
	documents
In-Reply-To: <7074e2j2MIc0hE.1.RZmta@mi-ob.rzone.de>
References: <7074e2j2MIc0hE.1.RZmta@mi-ob.rzone.de>
Message-ID: <4602D77B.60303@behnel.de>

Hi!

Lee Brown wrote:
> Parsing an XSLT stylesheet from an xml-stylesheet PI is working just
> fine, but now I'm trying to add an xml-stylesheet PI to a new XML tree
> created from within lxml.  I've looked back through the list traffic and
> done some code introspection but I can't find anything.
> 
> Did we ever decide upon / create an API for adding a stylesheet PI to a
> new tree?

No, not yet. :)

I see two possibilities: add a "prependPI(pi)" method to ElementTree, or add a
method "addToTree(tree)" method to ProcessingInstruction. We might then also
need a way to get rid of them again - although, well, you could always move
them to a different tree, which would obviously remove them from the current one.

Ok, so any preferences?

Stefan

From lee.brown at elecdev.com  Thu Mar 22 21:31:08 2007
From: lee.brown at elecdev.com (Lee Brown)
Date: Thu, 22 Mar 2007 15:31:08 -0500
Subject: [lxml-dev] Adding a Stylesheet PI when creating new XML
	documents
In-Reply-To: <200703221843.l2MIhS0e002648@mail.elecdev.com>
Message-ID: <200703221931.l2MJV30e003685@mail.elecdev.com>

Greetings!
 
As a work-around, I tried creating my XML document from a prototype string that
contained a stylesheet PI and an empty root element.  That part worked O.K.
(tree.getroot().getprevious() returned the PI) but then the PI was promptly
discarded upon reserialization by etree.tostring()!!!
 
I'm currently running lxml 1.2.1.  Is there any way around this problem?

  _____  

From: lxml-dev-bounces at codespeak.net [mailto:lxml-dev-bounces at codespeak.net] On
Behalf Of Lee Brown
Sent: Thursday, March 22, 2007 2:44 PM
To: lxml-dev at codespeak.net
Subject: [lxml-dev] Adding a Stylesheet PI when creating new XML documents



Greetings! 

Parsing an XSLT stylesheet from an xml-stylesheet PI is working just fine, but
now I'm trying to add an xml-stylesheet PI to a new XML tree created from within
lxml.  I've looked back through the list traffic and done some code
introspection but I can't find anything.

Did we ever decide upon / create an API for adding a stylesheet PI to a new
tree? 

Best Regards, 
Lee E. Brown 
Electronics Development Corporation 
9055-F Guilford Road 
Columbia MD 21046 
410-312-6678 
lee.brown at elecdev.com 
 <file://www.elecdev.com> www.elecdev.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/lxml-dev/attachments/20070322/58e0a9c7/attachment.htm 

From lee.brown at elecdev.com  Thu Mar 22 21:42:02 2007
From: lee.brown at elecdev.com (Lee Brown)
Date: Thu, 22 Mar 2007 15:42:02 -0500
Subject: [lxml-dev] Adding a Stylesheet PI when creating new XML
	documents
In-Reply-To: <4602D77B.60303@behnel.de>
Message-ID: <200703221941.l2MJfv0e003913@mail.elecdev.com>

Greetings!

I think the prependPI() is slightly better, as it is reminiscent of the append()
method.

Here's a silly thought:

Couldn't we just save any PIs preceeding the root element as members of docinfo?
That's where the doctype, xml version, and other "pre-root" stuff lives.
Doesn't "tree.docinfo.stylesheet" or "tree.docinfo.PI['stylesheet']" make more
sense than the way we're doing it now?

(And wouldn't it have been nice if I'd thought of this several months ago?)

-----Original Message-----
From: Stefan Behnel [mailto:stefan_ml at behnel.de] 
Sent: Thursday, March 22, 2007 2:23 PM
To: Lee Brown
Cc: lxml-dev at codespeak.net
Subject: Re: [lxml-dev] Adding a Stylesheet PI when creating new XML documents

Hi!

Lee Brown wrote:
> Parsing an XSLT stylesheet from an xml-stylesheet PI is working just 
> fine, but now I'm trying to add an xml-stylesheet PI to a new XML tree 
> created from within lxml.  I've looked back through the list traffic 
> and done some code introspection but I can't find anything.
> 
> Did we ever decide upon / create an API for adding a stylesheet PI to 
> a new tree?

No, not yet. :)

I see two possibilities: add a "prependPI(pi)" method to ElementTree, or add a
method "addToTree(tree)" method to ProcessingInstruction. We might then also
need a way to get rid of them again - although, well, you could always move them
to a different tree, which would obviously remove them from the current one.

Ok, so any preferences?

Stefan


From stefan_ml at behnel.de  Fri Mar 23 08:37:35 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 23 Mar 2007 08:37:35 +0100
Subject: [lxml-dev] Adding a Stylesheet PI when creating new XML
	documents
In-Reply-To: <H011e1j2MJZqGf.1.RZmta@mi-ob.rzone.de>
References: <H011e1j2MJZqGf.1.RZmta@mi-ob.rzone.de>
Message-ID: <460383BF.5030005@behnel.de>

Hi Lee,

Lee Brown wrote:
> I think the prependPI() is slightly better, as it is reminiscent of the append()
> method.

I personally liked the "addToTree()" method better as it allows us to
accompany it with a "copyToTree()" method that would not remove the PI from
its current location. Maybe "prependToTree()" and "prependCopyToTree()" would
be even more descriptive names.


> Here's a silly thought:
> 
> Couldn't we just save any PIs preceeding the root element as members of docinfo?
> That's where the doctype, xml version, and other "pre-root" stuff lives.
> Doesn't "tree.docinfo.stylesheet" or "tree.docinfo.PI['stylesheet']" make more
> sense than the way we're doing it now?
> 
> (And wouldn't it have been nice if I'd thought of this several months ago?)

Not that silly at all, and not too late either, since we do not yet have an
API for this (apart from the generic 'getprevious()' method).

So, regarding your proposal: it will not quite work as nothing prevents an XML
document from having 20 processing instructions of the same type. The meme
above sort of suggests that there can be only one (note that we are talking
about etree here, not objectify, which has a very different look-and-feel).

Is there any obvious way that would allow us to handle the normal case of zero
or one PIs per type as nicely as possible, while allowing us to deal with the
possible case of having an arbitrary number of them?

I mean, since PIs can be accessed with the normal API, the main problem we are
facing is that we currently cannot append or prepend siblings - only children.
 And the API is pretty much geared towards child handling (because that's how
things work in ET), which is usually enough - except for document level
processing instructions that *are* siblings.

I already said it was time to think a bit more about the docinfo property. I'm
still not sure it is the best way of accessing this information. The main
problem with docinfo is that it currently is read-only. If we start using it
for adding processing instructions (i.e. for modifying trees), it would be
hard to explain why you can't change or add a DOCTYPE declaration the same way
(e.g. by throwing in a DTD object). So, starting work here implies a complete
rewrite of the DocInfo class - and I would prefer having a good idea about the
way it should look afterwards before wasting my time.

As usual, any patches are welcome and I'm very much open for suggestions here.
I just won't be the one fighting this through as I'm not too interested in
getting this in. (it's not something that can't currently be done, just
something that could need a good API to make it's usage a bit more efficient
and a lot more obvious).

Regards,
Stefan

From lee.brown at elecdev.com  Fri Mar 23 17:07:07 2007
From: lee.brown at elecdev.com (Lee Brown)
Date: Fri, 23 Mar 2007 11:07:07 -0500
Subject: [lxml-dev] Adding a Stylesheet PI when creating new XML
	documents
In-Reply-To: <460383BF.5030005@behnel.de>
Message-ID: <200703231507.l2NF710e017599@mail.elecdev.com>

Greetings! 

> -----Original Message-----
> From: Stefan Behnel [mailto:stefan_ml at behnel.de] 
> Sent: Friday, March 23, 2007 2:38 AM
> To: Lee Brown
> Cc: lxml-dev at codespeak.net
> Subject: Re: [lxml-dev] Adding a Stylesheet PI when creating 
> new XML documents
> 
> Hi Lee,
> 
> Lee Brown wrote:
> > I think the prependPI() is slightly better, as it is reminiscent of 
> > the append() method.
> 
> I personally liked the "addToTree()" method better as it 
> allows us to accompany it with a "copyToTree()" method that 
> would not remove the PI from its current location. Maybe 
> "prependToTree()" and "prependCopyToTree()" would be even 
> more descriptive names.

Fair enough.  I like "addToTree" and "copyToTree."  "prependCopyToTree" is
starting to look too much like JavaScript :-)

> 
> > Here's a silly thought:
> > 
> > Couldn't we just save any PIs preceeding the root element 
> as members of docinfo?
> > That's where the doctype, xml version, and other "pre-root" 
> stuff lives.
> > Doesn't "tree.docinfo.stylesheet" or 
> "tree.docinfo.PI['stylesheet']" 
> > make more sense than the way we're doing it now?
> > 
> > (And wouldn't it have been nice if I'd thought of this 
> several months 
> > ago?)
> 
> Not that silly at all, and not too late either, since we do 
> not yet have an API for this (apart from the generic 
> 'getprevious()' method).
> 
> So, regarding your proposal: it will not quite work as 
> nothing prevents an XML document from having 20 processing 
> instructions of the same type. The meme above sort of 
> suggests that there can be only one (note that we are talking 
> about etree here, not objectify, which has a very different 
> look-and-feel).
> 
> Is there any obvious way that would allow us to handle the 
> normal case of zero or one PIs per type as nicely as 
> possible, while allowing us to deal with the possible case of 
> having an arbitrary number of them?

Well, we could do what the Xpath method does: Always return a list object, even
if it contains zero members.  If multiple elements are returned, it would be up
to the consumer to determine which one to use.

> I mean, since PIs can be accessed with the normal API, the 
> main problem we are facing is that we currently cannot append 
> or prepend siblings - only children.
>  And the API is pretty much geared towards child handling 
> (because that's how things work in ET), which is usually 
> enough - except for document level processing instructions 
> that *are* siblings.
> 
> I already said it was time to think a bit more about the 
> docinfo property. I'm still not sure it is the best way of 
> accessing this information. The main problem with docinfo is 
> that it currently is read-only. If we start using it for 
> adding processing instructions (i.e. for modifying trees), it 
> would be hard to explain why you can't change or add a 
> DOCTYPE declaration the same way (e.g. by throwing in a DTD 
> object). So, starting work here implies a complete rewrite of 
> the DocInfo class - and I would prefer having a good idea 
> about the way it should look afterwards before wasting my time.

It seems that this problem is inherent in the way XML has historically been
handled, and maybe somewhat inherent in the XML specifications themselves -
Every document has a root element, but the root element isn't always the "start"
of the document itself.

I think that in the XML community, we may have made a mistake in our conceptual
semantics by calling the "Root Element" the "Document Root."  To my mind, they
are different concepts; the Root Element is the start of the encapsulated,
heirarchical data set but the Document Root is the beginning of the document
itself.

So, how can we get at the document as a whole without breaking a whole lot of
existing code?

One possible way might be to give the ElementTree object a means to encapsulate
the entire document in a "phantom" element when needed.  Tree.getroot(),
tree.xpath(), and tree.docinfo could still work the way they've always worked,
but a call to, say, document.something() could encapsulate the entire document
in a phantom <document> element and then all the child and sibling oriented
methods could be applied to the phantom element (document.getchildren(),
document.firstchild(), etc.)  Validating parsers would want to mark any DOCTYPE
declaration as read-only, but non-validating parsers wouldn't care.

For all I know, this might be a complete programming nightmare.  But it would
give us a very nice, clean, API.

> As usual, any patches are welcome and I'm very much open for 
> suggestions here.
> I just won't be the one fighting this through as I'm not too 
> interested in getting this in. (it's not something that can't 
> currently be done, just something that could need a good API 
> to make it's usage a bit more efficient and a lot more obvious).

I'd love to contribute patches, but I'm C-illiterate.  Can LXML be ported over
into FORTRAN77? :-)

> Regards,
> Stefan
> 


From stefan_ml at behnel.de  Fri Mar 23 17:27:08 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 23 Mar 2007 17:27:08 +0100
Subject: [lxml-dev] Adding a Stylesheet PI when creating new XML
	documents
In-Reply-To: <80425fj2NEvNwg.1.RZmta@mi-ob.rzone.de>
References: <80425fj2NEvNwg.1.RZmta@mi-ob.rzone.de>
Message-ID: <4603FFDC.6000800@behnel.de>

Hi,

Lee Brown wrote:
>> From: Stefan Behnel [mailto:stefan_ml at behnel.de] 
>> I personally liked the "addToTree()" method better as it 
>> allows us to accompany it with a "copyToTree()" method that 
>> would not remove the PI from its current location. Maybe 
>> "prependToTree()" and "prependCopyToTree()" would be even 
>> more descriptive names.
> 
> Fair enough.  I like "addToTree" and "copyToTree."  "prependCopyToTree" is
> starting to look too much like JavaScript :-)

:) sure. Still time to find a better alternative, though.


>>> Doesn't "tree.docinfo.stylesheet" or 
>> "tree.docinfo.PI['stylesheet']" 
>>> make more sense than the way we're doing it now?
>>
>> So, regarding your proposal: it will not quite work as 
>> nothing prevents an XML document from having 20 processing 
>> instructions of the same type. The meme above sort of 
>> suggests that there can be only one (note that we are talking 
>> about etree here, not objectify, which has a very different 
>> look-and-feel).
>>
>> Is there any obvious way that would allow us to handle the 
>> normal case of zero or one PIs per type as nicely as 
>> possible, while allowing us to deal with the possible case of 
>> having an arbitrary number of them?
> 
> Well, we could do what the Xpath method does: Always return a list object, even
> if it contains zero members.  If multiple elements are returned, it would be up
> to the consumer to determine which one to use.

Sure, that's the obvious solution.
(not quite like xpath() though, which can return loads of stuff, not only lists)


> One possible way might be to give the ElementTree object a means to encapsulate
> the entire document in a "phantom" element when needed.  Tree.getroot(),
> tree.xpath(), and tree.docinfo could still work the way they've always worked,
> but a call to, say, document.something() could encapsulate the entire document
> in a phantom <document> element and then all the child and sibling oriented
> methods could be applied to the phantom element (document.getchildren(),
> document.firstchild(), etc.)  Validating parsers would want to mark any DOCTYPE
> declaration as read-only, but non-validating parsers wouldn't care.

Something like a "ET.gettoplevelelements()" method. Which sounds like it would
rather return a list than an object, I'd say.


> For all I know, this might be a complete programming nightmare.  But it would
> give us a very nice, clean, API.

Well, "clean" looks different in my eyes. Having a special object 'above' the
normal objects you'd use in the ET API sounds a bit fishy. But then, from the
point of view of the API, PIs are kinda fishy, too.


> I'd love to contribute patches, but I'm C-illiterate.  Can LXML be ported over
> into FORTRAN77? :-)

Have you actually looked at the code? It's written in Pyrex - most of it is
still looking rather Python-like, so if you know Python, you should at least
be able to read it.

Stefan


From stefan_ml at behnel.de  Mon Mar 26 22:59:32 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 26 Mar 2007 22:59:32 +0200
Subject: [lxml-dev] Adding a Stylesheet PI when creating new XML
	documents
In-Reply-To: <B0022cj2MJKgJh.1.RZmta@mi-ob.rzone.de>
References: <B0022cj2MJKgJh.1.RZmta@mi-ob.rzone.de>
Message-ID: <46083434.3000205@behnel.de>

Hi Lee,

Lee Brown wrote:
> As a work-around, I tried creating my XML document from a prototype
> string that contained a stylesheet PI and an empty root element.  That
> part worked O.K. (tree.getroot().getprevious() returned the PI) but then
> the PI was promptly discarded upon reserialization by etree.tostring()!!!

Right, I noticed this also. It's not as simple as "here's the fix", though.
The right way to deal with this would be to use the "xmlsave" API in libxml2.
However, this API had a couple of problems with serialisation in the past, so
this would require us to depend on a rather recent version of libxml2 (I think
it was at least 2.6.24). I'm actually quite happy that we currently have lxml
working across the last ten versions of libxml2 without major problems. You
can see the current behaviour as a compromise between the targeted behaviour
of Fredrik's ElementTree (which, for example, avoids XML declarations wherever
possible) and the backwards compatibility required to work around libxml2's
bugs. We could drop either of the two, i.e., serialise different (though
equivalent) XML or start requiring libxml2 2.6.24. Given these two
possibilities, I'd personally vote for keeping it the way it is.

Still, I admit that this is annoying. While you can serialise to a StringIO
object by using ET.write() - which should not suffer from this problem - it
would definitely be better to provide the same behaviour for string
serialisation, too.

Maybe I could try to fix it at least for more recent libxml2 versions - if I
find the time.

Stefan




From jwashin at vt.edu  Tue Mar 27 13:06:50 2007
From: jwashin at vt.edu (Jim Washington)
Date: Tue, 27 Mar 2007 07:06:50 -0400
Subject: [lxml-dev] A bit of oddness in the HTML parser
Message-ID: <4608FACA.1050806@vt.edu>

I'm seeing that the HTML parser is doing something undesirable.

If I have (note, the script tag is not closed):

>>> s = '<div>d_txt<script src="blah">s_tail</div>'

and I use the HTML parser on that string, I get the ending div
html-escaped in the script's text.

>>> r = HTML(s)
>>> tostring(r)
'<html><body><div>d_txt<script
src="blah">s_tail&lt;/div&gt;</script></div></body></html>'

I'm guessing this is upstream behavior?  I was hoping to get

'<html><body><div>d_txt<script
src="blah">s_tail</script></div></body></html>'

I think I can live with this behavior if nobody else thinks this is a
bug.  Yes, I realize that tag-soup parsers are hard to do. :)

-Jim Washington


From stefan_ml at behnel.de  Tue Mar 27 13:42:24 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Tue, 27 Mar 2007 13:42:24 +0200
Subject: [lxml-dev] A bit of oddness in the HTML parser
In-Reply-To: <7032a0j2RB6wYz.1.RZmta@mi-ob.rzone.de>
References: <7032a0j2RB6wYz.1.RZmta@mi-ob.rzone.de>
Message-ID: <46090320.1020408@behnel.de>



Jim Washington wrote:
>>>> s = '<div>d_txt<script src="blah">s_tail</div>'
> 
> and I use the HTML parser on that string, I get the ending div
> html-escaped in the script's text.
> 
>>>> r = HTML(s)
>>>> tostring(r)
> '<html><body><div>d_txt<script
> src="blah">s_tail&lt;/div&gt;</script></div></body></html>'
> 
> I'm guessing this is upstream behavior?

Definitely. There is always an end to what a machine can fix in tag soup. Feel
free to file a request for enhancement on libxml2's HTML parser.

Stefan


From rampeters at gmail.com  Wed Mar 28 23:13:24 2007
From: rampeters at gmail.com (Ram Peters)
Date: Wed, 28 Mar 2007 17:13:24 -0400
Subject: [lxml-dev] newb: How to create a simple xml file?
Message-ID: <81b45360703281413w37148833k5a65f9ba540a7ee0@mail.gmail.com>

How to create a simple xml file like the one below in lxml?

<?xml version="1.0" encoding="UTF-8"?>
<weatherNow xmlns="http://example.com/weatherNow/">
<temperature>57</temperature>
<pressure>29.97</pressure>
<pressureChange>rising</pressureChange>
</weatherNow>

Thank you.

From stefan_ml at behnel.de  Thu Mar 29 09:26:25 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 29 Mar 2007 09:26:25 +0200
Subject: [lxml-dev] newb: How to create a simple xml file?
In-Reply-To: <B00535j2SKvRkc.1.RZmta@mi-ob.rzone.de>
References: <B00535j2SKvRkc.1.RZmta@mi-ob.rzone.de>
Message-ID: <460B6A21.9010109@behnel.de>


Ram Peters wrote:
> How to create a simple xml file like the one below in lxml?
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <weatherNow xmlns="http://example.com/weatherNow/">
> <temperature>57</temperature>
> <pressure>29.97</pressure>
> <pressureChange>rising</pressureChange>
> </weatherNow>

Hi,

what about reading some of the documentation?

http://codespeak.net/lxml/#documentation

Given your target XML above (which is data style, not document style XML), you
might especially be interested in the objectify API.

http://codespeak.net/lxml/objectify.html
http://codespeak.net/lxml/objectify.html#creating-objectify-trees

Hope it helps,
Stefan

From sidnei at enfoldsystems.com  Thu Mar 29 16:01:27 2007
From: sidnei at enfoldsystems.com (Sidnei da Silva)
Date: Thu, 29 Mar 2007 11:01:27 -0300
Subject: [lxml-dev] Expose _assertHasRoot as part of the API?
Message-ID: <a7a2b76b0703290701i7ccf51d2j10b84dd1aeb57dc8@mail.gmail.com>

Hi,

I'm facing an issue here, that if applying a XSLT the resulting
document is empty, the only way to check that is to call
_assertHasRoot and catch the AssertionError apparently. Obviously
catching AssertionError's is not very recommended, specially because
they tend to not be raised when running with -O. Can we add a public
API to check if a element tree is empty? Maybe isEmpty()?

-- 
Sidnei da Silva
Enfold Systems                http://enfoldsystems.com
Fax +1 832 201 8856     Office +1 713 942 2377 Ext 214

From stefan_ml at behnel.de  Thu Mar 29 18:47:21 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 29 Mar 2007 18:47:21 +0200
Subject: [lxml-dev] Problem with lxml-1.1.2 and binary text nodes
In-Reply-To: <45CA2067.2020809@behnel.de>
References: <loom.20070206T172858-927@post.gmane.org>
	<45CA2067.2020809@behnel.de>
Message-ID: <460BED99.7090203@behnel.de>



Stefan Behnel wrote:
> Narayan Desai wrote:
>> I seem to recall that Lxml used to raise an exception if binary data was put
>> into a text node of an xml element. Was this change intentional? Is there any
>> way to use lxml to check for document well-formedness before sending out xml?
> 
> With 'binary' you mean 'containing 0-bytes', right?
> 
> It looks like we have a general problem with passing such strings to libxml2:
> 
>   >>> from lxml.etree import *
>   >>> r = XML("<test/>")
>   >>> r.text = "a\0b"
>   >>> tostring(r)
>   'a'

This is now caught by lxml. You will get an AssertionError if you pass strings
containing "\0" bytes to any of the API functions. You also get an
XMLSyntaxError if you pass such a string to the parser (which was already the
case before).

I think that's reasonable behaviour.

Have fun,
Stefan


From stefan_ml at behnel.de  Thu Mar 29 20:56:24 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 29 Mar 2007 20:56:24 +0200
Subject: [lxml-dev] Expose _assertHasRoot as part of the API?
In-Reply-To: <a7a2b76b0703290701i7ccf51d2j10b84dd1aeb57dc8@mail.gmail.com>
References: <a7a2b76b0703290701i7ccf51d2j10b84dd1aeb57dc8@mail.gmail.com>
Message-ID: <460C0BD8.5040604@behnel.de>



Sidnei da Silva wrote:
> I'm facing an issue here, that if applying a XSLT the resulting
> document is empty, the only way to check that is to call
> _assertHasRoot and catch the AssertionError apparently. Obviously
> catching AssertionError's is not very recommended, specially because
> they tend to not be raised when running with -O. Can we add a public
> API to check if a element tree is empty? Maybe isEmpty()?

Hi Sidnei,

doesn't "tree.getroot() is not None" work for you?

Stefan

From sidnei at enfoldsystems.com  Thu Mar 29 22:06:56 2007
From: sidnei at enfoldsystems.com (Sidnei da Silva)
Date: Thu, 29 Mar 2007 17:06:56 -0300
Subject: [lxml-dev] Expose _assertHasRoot as part of the API?
In-Reply-To: <460C0BD8.5040604@behnel.de>
References: <a7a2b76b0703290701i7ccf51d2j10b84dd1aeb57dc8@mail.gmail.com>
	<460C0BD8.5040604@behnel.de>
Message-ID: <a7a2b76b0703291306h1e07bf55j6e7fb5b448192180@mail.gmail.com>

> Hi Sidnei,
>
> doesn't "tree.getroot() is not None" work for you?

Duh. How could I have missed that. Sorry.

-- 
Sidnei da Silva
Enfold Systems                http://enfoldsystems.com
Fax +1 832 201 8856     Office +1 713 942 2377 Ext 214

From stefan_ml at behnel.de  Fri Mar 30 07:00:05 2007
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 30 Mar 2007 07:00:05 +0200
Subject: [lxml-dev] newb: How to create a simple xml file?
In-Reply-To: <81b45360703291343o38a15965hd3bbb02797609457@mail.gmail.com>
References: <B00535j2SKvRkc.1.RZmta@mi-ob.rzone.de>	
	<460B6A21.9010109@behnel.de>
	<81b45360703291343o38a15965hd3bbb02797609457@mail.gmail.com>
Message-ID: <460C9955.6000402@behnel.de>



Ram Peters wrote:
> I needed to know how to create xml headers, using lxml like this:
> <?xml version="1.0" encoding="UTF-8"?> ?

Hmm, why? By specification, there is no difference between this

 <?xml version="1.0" encoding="UTF-8"?>
 <weatherNow xmlns="http://example.com/weatherNow/">
 <temperature>57</temperature>
 <pressure>29.97</pressure>
 <pressureChange>rising</pressureChange>
 </weatherNow>

and this

 <weatherNow xmlns="http://example.com/weatherNow/">
 <temperature>57</temperature>
 <pressure>29.97</pressure>
 <pressureChange>rising</pressureChange>
 </weatherNow>

However, if you really need to output the header, pass the
"xml_declaration=True" keyword argument to tostring() or write().

Hope it helps,
Stefan



> On 29/03/07, Stefan Behnel <stefan_ml at behnel.de> wrote:
>>
>> > How to create a simple xml file like the one below in lxml?
>> >
>> > <?xml version="1.0" encoding="UTF-8"?>
>> > <weatherNow xmlns="http://example.com/weatherNow/">
>> > <temperature>57</temperature>
>> > <pressure>29.97</pressure>
>> > <pressureChange>rising</pressureChange>
>> > </weatherNow>
>>
>> Hi,
>>
>> what about reading some of the documentation?
>>
>> http://codespeak.net/lxml/#documentation
>>
>> Given your target XML above (which is data style, not document style
>> XML), you
>> might especially be interested in the objectify API.
>>
>> http://codespeak.net/lxml/objectify.html
>> http://codespeak.net/lxml/objectify.html#creating-objectify-trees
>>
>> Hope it helps,
>> Stefan
>>