[IronPython] imports & .NET classes...

Dino Viehland dinov at exchange.microsoft.com
Sat Jul 26 01:39:58 CEST 2008

We've recently been discussing a bug ( http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=16323 ) internally and thought we'd get some broader input on it.  Just so you don't have to click on this link this bug is all about how properties get imported and additionally how we deal with static classes in the face of import.

There's several different aspects to this.  First we have whether the class you're doing an import from is a static class or an instance class.  Next we have whether the user is doing an import * or from import.  And finally we have whether the members being extracted are properties/methods and whether they're instance or static members.  Let's take a look at each of those...

First if the class is a static class life is pretty good.  A .NET static class is much like a Python module.  For example consider the class System.Math.  This contains a bunch of static methods and some read-only fields.  Doing from System.Math import * seems perfectly reasonable in this case.  We're currently thinking about treating these types much like a module with __all__ defined on it - and we'll even add __all__ to the type.  The current thoughts on what goes into __all__ is:

__all__ contains all members except:
                Non-const/read-only fields
                Built-in methods/functions inherited from non-static types (really just object unless you use ilasm to create your static type)

Next we have import * vs. from import.  Import * should naturally respect __all__ so for static classes it will follow the above rules.  From staticClass import x should allow importing of anything from a module as long as it exists - so it'll work the same way for static classes as well.  That will allow "from System.Environment import CommandLine" to work will bring in the value for the command line.  Because non-static types won't have __all__ we will disallow from System.DateTime import *.

Now it starts to get tricky when you have a non-static class because we have instance vs static members.  To enable a better story w/ .NET we would like to enable from System.DateTime import Parse - supporting the import of static functions.  But the interesting question then becomes should we allow from System.DateTime import Now - a static property?  Finally, should we allow from System.DateTime import AddMonths - an instance method?

So in summary the static classes seem to be straight forward.  Instance members and non-static classes make the story much more complicated.  We'd love to hear what everyone thinks about the trickier cases or the plan in general.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080725/2b66d6d7/attachment.html>

More information about the Ironpython-users mailing list