[IronPython] imports & .NET classes...

Michael Foord fuzzyman at voidspace.org.uk
Sat Jul 26 02:12:37 CEST 2008

Dino Viehland wrote:
> 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*:
> __doc__/__class__
> Properties/indexers
> 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.

I like your proposal for static classes. .NET only needs static classes 
because it doesn't have proper functions anyway... ;-)

I think disallowing the import of static members on non-static classes 
is a reasonable restriction, and I think being able to import instance 
members is just plain odd.

Importing static members is ok - but can be confusing in the case of 
properties. I dislike the idea of importing the property getter in this 
case as it has different semantics to accessing the property as a member 
on the class.


> ------------------------------------------------------------------------
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


More information about the Ironpython-users mailing list