[IronPython] Array Access Problem

[Drew Moore]

Jim Hugunin wrote:

>This is a known problem, but we don't have a good fix to it in IronPython.  Here's how to set just the X value of a Point in an array today:
>
>apt[0] = Point(0, apt[0].Y)
>
>OR
>
>p = apt[0]
>p.X = 42
>apt[0] = p
>  
>
It is a known problem in other .NET languages, correct? Not just Python?

>I suspect that you're not very excited by either of these options.  The problem is that Point is a value type/struct and thus needs to be boxed to be passed out to IronPython as an object.  When it is boxed a new copy of the data in the Point is created and changes to this new copy won't change the original back in the array.
>
>This same problem also shows up when value types are stored in fields and you want to change them.  Point is probably far and away the most common instance of this.
>
>I can't come up with any elegant ways to make this experience better.  There are some inelegant ideas floating around in my head, but I keep hoping for an inspiration here...
>
>In case you're wondering why it's hard, Python has a strong invariant that:
>  
>
CPython does it "correctly." The "strong invariant' behavior described, 
in CPython does the right thing, yes?

.NET, which tries to support both value types and reference types is the 
souce of the trouble, with the "boxing" and what-not. In .NET, the 'tmp' 
is not a reference to the original, it is a new boxed object.. an 
unexpected deep copy.
I don't think its a weakness of Python, it is just a consequence of .NET 
trying to support two type paradigms. The dual paradigm mode enables 
value types, and also leads to such confusion. I'd say this is a pretty 
deep one, don't step into it or you'll never get out again. Just say, 
"that's what happens when you mix paradigms. Python doesn't do that." 
Me, I prefer C (pure value type paradigm) and/or Python (pure reference 
type paradigm) but languages that try to do both simultaneously confuse 
me --- of course, I am a bear of very little brain; I just have a hard 
time juggling both simultaneously.

Python can't map onto both paradigms, and that is a GoodThing. Accept 
these ugly consequences of boxing which are consistent with other .NET 
languages and move on. Consistency is a GoodThing too. Python can't 
expose all of the confusion of the dual-paradigm .NET framework? oh 
well, it isn't the only one that can't. If the implementation is hard to 
explain..
(On the other hand, practicality beats purity, touche. but this topic 
makes me nervous too.)

hey, doesn't this mean .NET is a terrible platform for dynamic languages?
shouldn't someone write a "short, pithy article" about this?

wait, no....
Maybe if we had an insider at Microsoft who could make the CLR a little 
more "Pythonic" and get rid of those darn value types altogether?

;-)

my two cents.

tongue-somewhat-in-cheekly-yours

Drew