[IronPython] Writing new modules

[Jim Hugunin]

Nick Bastin wrote:
> I'd like to take a hack at implementing _random, but I am a bit
> confused as to how it works, so I have a few questions.  Keep in mind

You should look at the existing modules such as math and re for some
examples of how this can be done.  I believe this is a VERY simple process.

> It seems as if a module is available to the interpreter merely by
> existing in IronPython.Modules.  Is this correct?

This is mostly correct; however, the module also needs to be visible to the
interpreter, which for now probably means building it as part of
IronPython.dll.  This is a configuration issue that will be resolved moving
forward.

> sys.modules appears to be completely non-functional.  Is this a matter
> of just not having an implementation, or is there a technical hurdle
> here?

I believe that sys.modules is only being used today for imports from Python
source code to avoid the circular import danger.  It's probably completely
non-functional for "builtin" modules.

> Similarly, simple errors generate long CLR stacks instead of the normal
> python error messages.  Is this just unimplemented, or is it somewhat
> complicated to get right?

This mainly reflects the current stage of development.  Those long stack
traces do include all of your Python stack trace information PLUS all of the
implementation details of the C# code.  Right now it can be helpful to have
all of that information to understand when something goes wrong.  As things
get more stable, this will have to be revisited and some efforts made to
simplify these stack traces.

There's an issue here as to how much of the CLR stack trace to elide.
Consider this silly program:

>>> def cmp(a,b): raise Exception()
>>> [1,2,3].sort(cmp)

When I run this with CPython, I see this:

  Traceback (most recent call last):
    File "<pyshell#2>", line 1, in -toplevel-
      [1,2,3].sort(cmp)
    File "<pyshell#1>", line 1, in cmp
      def cmp(a,b): raise Exception()
  Exception

This can confusing because it doesn't show the internal C code that is
calling the cmp function.  The 'sort' method doesn't appear anywhere in the
stack trace.  IronPython's result is currently much too long, but I think
that it's a good thing that it includes the sort method in its stack trace.
We want to be sure not to lose that benefit when shortening the result for
readability.

-Jim