> Just my 2cents: I just decided after some research to use lxml in all of my > projects, > and I guess my decission tree is comparable to that many other Python > developers out > there. I would bet lxml is the emerging standard.
I hope so too, but it's C-dependency is not the best for mass deployment > But AFAIK does lxml mimick the ElementTree API. Maybe a "workaround" for the > time beeing > would be that Pylons itself uses only API features common in both packages, > and let the > users/developers decide what package (and additional features) they want. I think sticking with cElementTree (ElementTree as fallback) is the way to go. lxml depends on libxml2. The drawback is that elementtree has a very minimal xpath support. > So maybe the best approach would be: > - allow ElementTree or lxml > - use the common API set inside Pylons > - switch fully to lxml at a later stage (Pylons 1.5, Pylons 2) as soon as > lxml > provides precompiled C-libs both for Windows and Linux for the various > distros. It can be doable. It depends on how much work the team should put into supporting both -- Lawrence, stacktrace.it - oluyede.org - neropercaso.it "It is difficult to get a man to understand something when his salary depends on not understanding it" - Upton Sinclair --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en -~----------~----~----~----~------~----~------~--~---
