I've been working on a blog entry that tries to cover this in great
detail. Rather than go silent until I find time to complete that, I
thought I should chime in a little here.
<Assume a big prelude about the fact that IronPython tries to do the
right conversions to make it easy and natural for Python programmers to
work with CLS libraries. This will explain numeric types, strings, and
delegates which all work pretty naturally today.>
When working with CLS libraries, IronPython tries first to ensure that
nothing is impossible and second to make interactions as natural and
convenient when possible. This is why Martin's answer below is an
important one showing how this method can be called from IronPython
today. There will always be cases where some CLS methods will require
techniques such as explicitly creating typed arrays in order to work
with them effectively. I would expect that an experienced IronPython
user will never be able to completely get away from the occasional need
to create a typed array.
Arrays are probably the hardest type of all to get right. They're a
special type to the runtime without an interface or even a standard
class which leaves much less design room to improve their interaction
with IronPython. Unfortunately, arrays are also probably the most
commonly used collection type because they are easy to create. Just
like Python has special syntax for building lists and tuples, C# has
special syntax for easily building arrays.
The key challenge with arrays is that they are mutable. That means that
you can change the contents of an array after creating it. Some methods
that accept an array need to mutate its contents and expect the caller
to be able to see that mutated array. Most methods that take an array
treat it as read-only input and won't make any changes to the contents.
This second set of methods would be better specified with an immutable
type such as Python's tuples; however, the ease of use of arrays over
other types means that this is rare. Unfortunately, it is hard or
impossible to automatically tell the difference between these two types
of methods. Here are two examples from System.String:
public string Trim(char[] trimChars);
- Ideally, this should accept any sequence of chars, including a Python
string
public void CopyTo(int sourceIndex, char[] destination,
int destinationIndex, int count);
- Needs an array for its destination because it is counting on mutating
the array
Because we can't tell the difference between these two signatures, it's
impossible have different rules for the two cases. I'm very
uncomfortable accepting a list of chars for the second method.
A third method on System.String shows that things aren't always this
grim. The format method uses the params keyword to indicate that it
takes 0 or more args. This means that programming languages can support
dynamically building this array at the call site from a variable-length
argument list. As a result, we can infer that this array is not used as
an out parameter. In fact, this maps directly to Python's *args
support. I'd claim that Python has a slightly better design for this
feature because it uses the immutable Tuple type here rather than a
theoretically mutable array.
public static string Format(string format, params object[] args);
- The use of params here gives us great support
History - Jython doesn't automatically convert between Python
collections and arrays. It added a special jarray class for building
Java style arrays that could be used in the same way as
System.Array.CreateInstance. Jython's jarray did have several
convenience constructors that made it easier to go from a list to an
array that we might want to consider here.
If I recall correctly, Numeric Python which is an even older CPython
extension of mine that supports working with numeric arrays does do
automatic conversions from Python sequences to numeric arrays in order
to make some vector math operations easier to write. This conversion
would make sense in that case because it could be known that the
operands to the arithmetic function wouldn't ever be mutated.
Some thoughts - Jim
Richard Monson-Haefel wrote:
> It might be better if IronPython auto converted the list of real
number
> to an array in this case. If, that is, all the types in the list can
be
> widened to the correct type, or if the parameter is an array of
> objects. That way you don't have to call an explicit method to set the
> list to an array of Double types.
>
> The reason, I think this is important, is that in Python developers
> will avoid explicit typed of arrays in favor of loose typed lists
> because its more Pythonic. Since interaction with general purpose
> languages (strongly typed) will require more strict typing, the
> interpreter or compiler should make that transformation (from List to
> array of doubles) implicitly, or if it can't be done throw an
> exception. Otherwise, you are forcing IronPython developers to adhere
> to strict typing whenever they script interactions of objects defined
> by general purpose languages like C#.
>
> richard
>
> On Apr 19, 2005, at 6:36 PM, Martin Maly wrote:
>
> >
> >
> >>>> John A. Tenney Wrote:
> >>>>
> >>>> 1. I'd like to pass an array of 6 doubles to a method, but get an
> > error message.
> >>>> For example, the "myMethod" call below fails when it requires a
> > double array.
> >>>> array=[1, 2, 3.5, 4]
> >>>> myObject.myMethod(array)
> >
> > If you create the array using the syntax above, you end up with
object
> > of type list.
> > To create .Net array, you can do the following:
> >
> >>>> import System
> >>>> array = System.Array.CreateInstance(System.Double, 5)
> >>>> array[0]=1.3
> >>>> array
> > System.Double[](1.3, 0, 0, 0, 0)
> >
> > And call:
> >
> > myObject.MyMethod(array)
_______________________________________________
users-ironpython.com mailing list
users-ironpython.com@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
