offer a pure python alternative to lxml

[plq]

some users have expressed concerns towards lxml usage. it's a c module that's not trivial to deploy.

offering a pure-python xml backend support would increase soaplib adoption.

it also must be made clear that this will cause a performance penalty.

[sheilatron]

That could be a lot of effort, and might also be missing functionality such as XML Schema validation.

What about a documentation solution, to make sure that users have clear docs about how to install lxml for use with soaplib?

[plq]

I don't think it's wise to delve deeper than "easy_install -U soaplib". If lxml installation fails in this step, its causes are quite dependant on the platform.

maybe i should have said "nontrivial to impossible to deploy", especially for python code running outside of cpython.

of course, we shouldn't re-implement schema validation for the sake of it, but i think the basic functionality should be there.

[caustin]

I am guessing that If are to go down this path we would have to extract/abstract the direct calls into lxml.etree in a lot of places like the serializers. What do you folks think?

[plq]

that's no big deal, i've taken special care for those calls to be easily processed by sed.

the difficult part is to find a pure-python ElementTree api that fully supports namespaces.

[plq]

now that soft validation is implemented, some progress has been made towards this.

[caustin]

Hi Burak,

Sorry, I haven't been able to respond to some of your messages earlier; I've been traveling a bit the last several weeks. I've been thinking about the pure python alternative to lxml only because there have been a few issues with people and some buildout issues when attempting to do an isolated install... Something akin to creating an environment for each 'end user' in a SaaS model. But otherwise, I really love lxml :)

Do you think the pure python approach is valuable?

Also, I want to say the XML schema export code that you sent me looks great and in general so does rpclib. At work we are in the middle of a large deployment to multiple clients so my time has been spent fighting fires lately but I really want to contribute more as soon as I can free up some time.

Thanks for the great work.

On Fri 30 Sep 2011 07:48:18 AM CDT, Burak Arslan wrote:

now that soft validation is implemented, some progress has been made towards this.

[plq]

On 30.09.2011 17:33, caustin wrote:

Hi Burak,

Sorry, I haven't been able to respond to some of your messages earlier; I've been traveling a bit the last several weeks. I've been thinking about the pure python alternative to lxml only because there have been a few issues with people and some buildout issues when attempting to do an isolated install... Something akin to creating an environment for each 'end user' in a SaaS model. But otherwise, I really love lxml :)

Yes, me too, I have no problems with lxml itself. It's fast, robust and is chock-full of features.

Do you think the pure python approach is valuable?

I've implemented soft validation for non-xml-based protocols actually. Its helping with validaton by a non-lxml engine is just a side effect.

Also, I want to say the XML schema export code that you sent me looks great and in general so does rpclib. At work we are in the middle of a large deployment to multiple clients so my time has been spent fighting fires lately but I really want to contribute more as soon as I can free up some time.

Thanks for the great work.

Sure, I'm glad you like my work, and waiting you back to the project :)

best, burak

[hajs]

If spyne would use a pure Python module, it could also run on PyPy and Jython. PyPy would be an interesting target if you want to handle many requests.

[plq]

This is certainly an issue that merits more attention than it has so far gotten now that PyPy is emerging as a viable alternative to CPython. Our general stance so far has been that a pure-python XML parser would be slower, thus not worth our attention. But I wonder how much of that lost performance PyPy would compensate.