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
chosechu wrote:
Is it possible to force dictionary creation in these case to use
my own dict class instead of the default one?
No
I guess we can formulate this as a more generic question: if I
want to modify the behaviour of the dictionary class, is there
any way to do it interpreter-wide
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 the
chosechu wrote:
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
.
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
chosechu wrote:
Yes, if I could simply modify myfunc() I would have workarounds.
This would mean me modifying SOAPpy and specializing it for
my needs.
maybe you could fake it:
class fakedict(dict):
def __init__(self, *data):
self.data = list(data)
for k, v in data:
. Extending the base dict class to support ordering
was one possible idea.
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
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 this
(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
chosechu wrote:
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
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
Fredrik Lundh wrote:
chosechu wrote:
Yes, if I could simply modify myfunc() I would have workarounds.
This would mean me modifying SOAPpy and specializing it for
my needs.
maybe you could fake it:
No you cannot fake it, because the ** form of passing arguments
constructs a new
chosechu wrote:
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
Tim N. van der Leeuw wrote:
maybe you could fake it:
No you cannot fake it, because the ** form of passing arguments
constructs a new dictionary (and that dictionary is the standard
built-in type of dictionary, not your own fake-dictionary).
yeah, I thought he was passing a dictionary to a
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
chosechu wrote:
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
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
17 matches
Mail list logo
