[IronPython] Plans for overloads?

[Jonathan Jacobs]

Martin Maly wrote:
> The overloaded function resolution (when IronPython calls .Net) is
> currently being worked on. You probably read the original code in which
> IronPython chooses the first callable alternative. The new code does
> better finds out all methods that can be called and tries to choose the
> 'best fit'.

At the moment "out" parameters are not really taken into account when 
matching up signatures, if I'm not mistaken, is this going to be addressed?

> This solution is still not perfect because Python's binding ruls are
> inherently different than for example C#'s and IronPython can still
> arrive at an ambiguous binding. As of this very moment we are looking
> into the solution that would allow program(-mer) to pinpoint the very
> overloaded method to be called.

Something that crossed my mind (and I know it's not really very 
"Pythonic") regarding "out" parameters was: What about passing a type in 
the place of an out object, so that you can match up exactly which 
overload the programmer wants to use?

> I hope this helps. The code will be available in the upcoming release.

I'm looking forward to it!

A little off-topic, I was wondering about kwargs support for reflected 
methods. I noticed that there is some code that deals with reflected 
method kwargs, but basically excludes them from the function call and 
then uses them to try and set attributes on the object. I realise that 
C# doesn't really have anything like Python's default arguments (I 
think...I'm no C# programmer) so kwargs aren't *quite* that useful, but 
it's handy to be able to use dictionary unpacking syntax, or just to 
"reorder" the arguments, more handy than having the code (try to) set 
random attributes. I did hack support in, before realising that kwargs 
weren't quite as useful for reflected methods, as I'd initially thought, 
but it's not really something pretty.

--
Jonathan