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?
CPython does it "correctly." The "strong invariant' behavior described, in CPython does the right thing, yes?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:
.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
_______________________________________________ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
