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
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 origin
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
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
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.
> >
> > Sh
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
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
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.
>>
>> Shoul
> (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:
> 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
chosechu wrote:
> 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. Exte
"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:
> 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=
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']
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
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-w
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
17 matches
Mail list logo
