Extending the dict class

[chosechu]

> I'm not sure to understand why you want to do so - perhaps you could
> tell more about your real use case ?

Without diving into too many details: I am calling SOAPpy to build
SOAP requests. When calling a proxy, named arguments are used
to build up the corresponding XML like:

proxy.call(alpha=1, beta=2, gamma=3)
would end up like:
<alpha>1</alpha> <beta>2</beta> <gamma>3</gamma>

Unfortunately, since the arguments as retrieved with **k
their order is lost in the call. The corresponding XML file
re-arranges the parameter order randomly and the final
XML request is unordered, which is not supported by a
number of braindead SOAP servers (including one produced
by a well-known software company I will not name here).

SOAPpy cannot know in advance the argument names since
they are server-dependent and SOAPpy is generic, so retrieving
named arguments with **k seems like the sensible thing to do.
Unfortunately this gets converted to a dict so looses all ordering
when being received. Extending the base dict class to support ordering
was one possible idea.

> Anyway, and since it's not directly possible, a possible workaround
> could be to pass a sequence of (key, value) tuples instead (possibly as
> *args). This of course requires that you can modify the implementation
> of myfunc().

Yes, if I could simply modify myfunc() I would have workarounds.
This would mean me modifying SOAPpy and specializing it for
my needs.

There are other ways to implement SOAP clients anyway so
no real need. Just wanted to try out some metaclass stuff.