[Ironpython-users] How can IronPython access a public static value defined in C#?

Keith Rome rome at Wintellect.com
Mon Jun 20 20:59:04 CEST 2011


Evaluating a property could potentially introduce unexpected side effects. Best practices in OOP says that a property getter should never alter state, but it happens enough in the wild that I would think it to be dangerous to blindly invoke any getters during an import.

Also, presence of a property (as opposed to a field) implies that the code in the getter will be invoked each time the property is accessed. A consumer of such a construct expects this behavior, and might even depend on it.

If the auto import of properties is added, then it needs to at least be an opt-in feature.


Keith Rome
Senior Consultant and Architect
MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS
Wintellect | 770.617.4016 | krome at wintellect.com
www.wintellect.com

-----Original Message-----
From: ironpython-users-bounces+rome=wintellect.com at python.org [mailto:ironpython-users-bounces+rome=wintellect.com at python.org] On Behalf Of Dino Viehland
Sent: Monday, June 20, 2011 2:28 PM
To: Jeff Hardy; Jimmy Schementi
Cc: ironpython-users at python.org
Subject: Re: [Ironpython-users] How can IronPython access a public static value defined in C#?

Jeff wrote:
> On Mon, Jun 20, 2011 at 9:35 AM, Jimmy Schementi 
> <jschementi at 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?

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

_______________________________________________
Ironpython-users mailing list
Ironpython-users at python.org
http://mail.python.org/mailman/listinfo/ironpython-users




More information about the Ironpython-users mailing list