[spyne] Testing 2.10 code with 2.11

Burak Arslan burak.arslan at arskom.com.tr
Thu May 8 14:07:39 UTC 2014

Hello all and welcome to the Spyne mailing list :)

As I said earlier, if everything goes according to plan, I'm planning to 
make a Spyne release in around a month.

While I'd prefer to make sure that updating Spyne won't break already 
working code, with almost 1300 commits spanning a year of active 
development, my impression is that this has very low probability of 
happening, especially because Spyne 2.11 is way stricter in terms of 
object definition consistency.

Even though the changelog is supposed to summarize 
https://github.com/arskom/spyne/compare/2_10...master even that is 
getting too long to be wieldy.

So here's a list of possible things that can break existing code:

1) Schema non-determinism due to inheritance: Spyne now adds all child 
classes of a given parent class to the xml schema document, regardless 
of whether it's used in service definitions. This is a first step 
towards implementing polymorphic responses. When a subclass contains a 
field that is also present in the parent class, you will see a "content 
model not determinist" error and the server will refuse to boot. 
Cleaning duplicate fields will fix this issue.

2) Unequal number of parameters in @rpc and function definition: Spyne 
2.10 did not care when @rpc had more arguments than the actual function 
definition. Spyne 2.11 won't tolerate this.

3) Spyne 2.11 uses a proper topological sorting algorithm for generating 
the xml schema. So the order of object declarations will certainly be 
different from what 2.10 generates. This is not supposed to cause any 
issues though.

4) The field order within the object definitions should *in theory* stay 
the same, but we never know as CPython offers no guarantees about the 
element order consistency in its hashmap implementation. Some folks 
found this so unacceptable that they dared to submit this horrendous 
hack: https://github.com/arskom/spyne/pull/343. As it seemed to work OK 
and after making sure that it's strictly opt-in, I chose to merge it. 
It's been in the tree for a couple of weeks now and seems to be working 
OK with CPython 2.6-3.3 and PyPy. Please test it with your environment 
and report back as it's relying, as far as I can tell, on some 
implementation details of CPython.

Even though these are technically backwards-incompatible changes, 
they're also bug fixes that detect broken code. I don't want to allow 
broken code solely on backwards-compatibility grounds, so I intend make 
sure these changes go into Spyne 2.11.

Anything else that breaks existing code, please let me know.

This post was about changes to the stable parts of Spyne. As you might 
have guessed, a lot of effort also went to adding new functionality to 
Spyne but I'll talk about these in a separate post that focuses on new 

Thanks for using Spyne. I hope you find the new version useful.

Best regards,

More information about the people mailing list