[IronPython] imports & .NET classes...
fuzzyman at voidspace.org.uk
Sat Jul 26 02:12:37 CEST 2008
Dino Viehland wrote:
> We’ve recently been discussing a bug (
> ) 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.
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
More information about the Ironpython-users