On Jun 20, 2011, at 1:16 PM, Jeff Hardy wrote: > On Mon, Jun 20, 2011 at 9:35 AM, Jimmy Schementi <jscheme...@gmail.com> wrote: >> If we chose to map .NET property imports to module variables, then we'd have >> to execute the getter when imported, which would break this example (random >> numbers). We could do some magic of exposing the PropertyInfo itself as the >> variable, making an getter call look like: >> SomeStaticProperty() >> ... and a setter call look like: >> SomeStaticProperty(val) > > It's really just a convenience, right? You can still do > import Color > print Color.White > > with no issues? If so, I'm also inclined to say we don't support it, > because Python has no concept like that at the module level, OTOH, if > events are importable, why not properties? > > If so, they should retain their property nature; otherwise it would be > too surprising. > > I would strongly prefer they still look like fields as well (x = > SomeStaticProperty; SomeStaticProperty = y) but I don't know if that's > possible. Otherwise I'd prefer .get/.set methods to overloading (). > (Too bad descriptors only work as class members ... although we could > always change the rules) > > - Jeff
This behavior is already documented here: http://ironpython.net/documentation/dotnet/dotnet.html#importing-net-members-from-a-type. Since this is "from x import *" behavior, I say we just make this low-pri feature. ~Jimmy
_______________________________________________ Ironpython-users mailing list Ironpython-users@python.org http://mail.python.org/mailman/listinfo/ironpython-users
