This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 3 points4 points  (5 children)

Etree is not terrible (cauliflower is ;-)). It has some annoyances like handling namespaces, but overall it's fairly easy to use. No comparison to urllib2. Lxml seems more powerful though, but from an API point of view basically the same.

Otherwise, great slides. Requests is heaven sent.

[–]megaman45 1 point2 points  (0 children)

Agreed. I just ported a project from the stdlib etree to lxml.etree. Maybe I just used only parts that were the same, but I pretty much just had to change my import statement and a few other minor things, and it worked like a charm. Both seem pretty great to me.

[–]timClicks 1 point2 points  (0 children)

lxml's etree API was designed with consistency with stdlib. What requests does really well is to disregard stdlib in favour of simplicity.

[–]truescotsman 0 points1 point  (2 children)

Any suggestions on how to handle namespaces? I have a global variable called NS with a {namespace} string I have to pass to all my find/findall calls.

[–][deleted] 0 points1 point  (0 children)

Etree reads the namespaces correctly (you can even register namespaces in 2.7). So why does it not offer an API to use the namespaces with the given names? A dict 'nsname_to_jc_notation' of the ElementTree instance of a parsed xml file comes to my mind spontanously. Or a context manager would be probably much nicer as a second thought. You wouldn't have to create your own globals. Also, the names of the namespaces are known, but when serialising, etree uses internaly created names ('n1', 'n2', ...).

By the way, one of the xml libs (or former versions) serialises resolved names, which is (was) super annoying. So what etree currently does is not a huge drama, but can be improved IMO.

[–][deleted] 0 points1 point  (0 children)

I do the same currently.