[spyne] Testing 2.10 code with 2.11
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
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.
More information about the people