[IronPython] Keyword arguments

Jim Hugunin jim at ironpython.com
Thu Aug 26 08:12:03 CEST 2004

Brian Quinlan wrote:
> Currently it appears, at least for constructors, that IronPython is
> transforming keyword arguments into attribute assignments e.g.
> I would argue strongly that this is a bad idea; keyword arguments should
> have the same semantics as they do in CPython. The most obvious reason
> that I can think of is that keyword arguments, used as in CPython, can
> clarify the meaning of various arguments. Compatibility is also an issue
> as is 3rd party tools support. I actually noticed this problem while
> writing a script to add .NET Framework intellisense support to
> ActiveState's Python IDE. If anyone is interested in either the source
> or the datafile, please let me know.

I really like this feature and it's unlikely that it will disappear in the
future without a strong argument.  I originally designed it for Jython as
the way that I could make code using swing as easy to write as TkInter code.
I think it serves that same purpose to make Windows.Forms or GTK# code
friendlier to scripting.  This is one of the ideas in Jython that the groovy
developers liked enough to borrow for their language.

This is NOT a change to CPython's semantics.  Keyword arguments are used to
allow the initialization of attributes (and fields) only for code from
standard CLR libraries that weren't designed with Python or any scripting
language in mind.  Constructors for Python classes should continue to behave
exactly as they do in CPython.

I'm not at all worried about compatibility with 3rd party tools.  Anyone who
wants to support the CLR libraries in a 3rd party IDE integration is going
to have to do some special work to understand those libraries.  It shouldn't
be very hard to modify any symbol tables to pretend that the constructors
for CLR classes include the appropriate well-defined optional keyword


More information about the Ironpython-users mailing list