Hello Pythoneers:
I need to pass a list of named arguments to a function in a given
order,
and make sure these named arguments are retrieved using keys() in the
same order they were given. Example:
keyargs={}
keyargs['one']=1
keyargs['two']=2
keyargs['three']=3
myfunc(**keyargs)
-> myfunc would
Duncan Booth wrote:
> > Is it possible to force dictionary creation in these case to use
> > my own dict class instead of the default one?
>
> No
Ouch. I was expecting something like that, thanks for confirming it.
If I may: this seems inconsistent to me. I have created an augmented
version of t
> 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=
Duncan Booth wrote:
> If the order of the argument names matters, then it seems to me that should
> be handled by the SOAP library, not pushed onto the end user whoch should
> just be calling the function with the named arguments in the most
> convenient order.
>
> Shouldn't SOAPpy be able to get
> (the exact set of methods you need to override depends on how SOAPpy
> fetches the members).
[fakedict class]
This I did. And checking out the source it seems SOAPpy retrieves named
parameters through keys(), which is the method I tried to overload.
Trouble is:
something happens to my fakedict
Duncan Booth wrote:
> No, you weren't able to extend the builtin dict class nor touch any its
> constructor.
Yes, sorry. Forgot the negation.
> All you did was to create a subclass with its own constructor and hide the
> name for the builtin dictionary type. The original type was still unchanged
Tim N. van der Leeuw wrote:
> Anyways, modifiying SOAPpy might not be a bad idea: submit your changes
> to the project, and you can write on your CV that you have contributed
> to open-source projects! ;-)
Been there, done that. Don't worry, my contributions
to open-source projects is largely pos
Bruno Desthuilliers wrote:
> It's usually possible to modify third-parts classes behaviour on the fly
> (googling for 'monkey-patching' should get you started). But true, this
> doesn't work with builtins.
I guess this stems from the fact that Python dictionaries
are C creatures and they are them
