Jeff wrote: > On Mon, Jun 20, 2011 at 9:35 AM, Jimmy Schementi > <[email protected]> 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?
I think events were an oversight - of course we could just make the decision to relax this and bring in the value of the property at the time of import *. If it changes you lose. > > 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 > _______________________________________________ > Ironpython-users mailing list > [email protected] > http://mail.python.org/mailman/listinfo/ironpython-users _______________________________________________ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
