[IronPython] Array Access Problem
drew at astro.pas.rochester.edu
Sat May 7 05:59:59 CEST 2005
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 = Point(0, apt.Y)
>p = apt
>p.X = 42
>apt = 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
(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?
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.
More information about the Ironpython-users