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
_______________________________________________
Ironpython-users mailing list
Ironpython-users@python.org
http://mail.python.org/mailman/listinfo/ironpython-users
