[IronPython] Writing new modules

[Jim Hugunin]

Curt Hagenlocher wrote:

> Nick Bastin <nbastin at opnet.com> writes:
>
> > There are a lot of extra names in each built-in module that don't
> > exist in CPython, like 'Equals', 'GetHashCode', etc.  What are
> > these, and where do they come from?
> 
> These are members of the Object class that are supposed to be
> overridden by derived classes.  It's a CLR thing.

There's an interesting question whether or not these sorts of CLR things
should be exposed to Python programmers.  These particular methods will
disappear when IronPython moves to the CLR-2.0 (Whidbey) release.  For that
release, C# includes a new feature called static classes that let's you
declare a class has only static members.  In this case, none of these weird
methods from object would be inherited.

A more interesting question is what to do about standard Python objects.
Here are a couple of things that you can write in IronPython, but that will
fail in CPython:
>>> l = [1,2]
>>> l.Add(3)
2
>>> l
[1, 2, 3]
>>> l.GetObjectArray()
System.Object[](1, 2, 3)
>>> l.Clear()
>>> l
[]

This is using the fact that list objects also implement the standard CLR
IList interface.  This is great for interoperating with other CLR languages
(C#, VB, ...); however, it is incompatible with CPython.

I've talked about this briefly with Guido, and he's not very happy about
adding methods to the standard Python objects.  This is a recipe for
incompatible code.  On the other hand, these methods are very valuable to
C#/VB programmers who already know how lists work in their world and who are
just getting started in Python.

Guido suggested a per-module flag much like the way that floor vs. true
division is selected in the current CPython could be used to control whether
or not non-Python methods were exposed on standard Python types.  I always
hate adding flags like this, but it might be the best compromise between the
two positions.

> > Where are doc strings supposed to be put?  I notice that none of the
> > modules seem to have them.
> 
> This doesn't look like it's been worked out yet.  It looks like
> an ideal place to create a custom attribute.

I agree that doc strings would be well captured in a custom attribute.
However, I'd like to see a solution that is as compatible with C# and other
CLR languages as possible.  In that case, it would be great to capture the
doc information in the XML doc comments that are standard in that world.  I
don't have any ideas yet for how to expose that kind of doc information
dynamically as the __doc__ attribute.

-Jim