[IronPython] Array Access Problem

Drew Moore drew at astro.pas.rochester.edu
Sun May 8 05:45:54 CEST 2005


Bob Ippolito wrote:

> There are ways you *could* fix the issue:
>
> (1) Don't have mutable value types, use a reference type that points 
> to a value type (some kind of proxy)
> (2) Make value types immutable (or at least the ones you grab from 
> collections)
>
I kinda like both of these options. Darn dual paradigm.
One Pythonic phrase that comes to mind is "explicit is better than 
implicit."
On #1 above, if the Python side required the user to write
myobj = BoxedValue.Proxy()
it would be obvious that the object is a proxy (perhaps an expensive 
performance-killing one) into the underlying struct.
likewise
myobj = BoxedValue.Copy()
would make it obvious that you have a copy of the object, and you 
shouldn't be alarmed that modifications are not reflected in the 
underlying struct.
(immutable value types would save the wall from your head.. the right 
spirit, but a wee bit harsh. Enforcing readability and expression in 
source code is the more Pythonic way isnt it, hmm?)

Oh, "In the face of ambiguity, refuse the temptation to guess." How's 
that one grab ya?

I'm still not sure exactly how to apply this to the collections issue, 
etc, but perhaps the spirit here is going in the right direction.

Goal:
Implement the Python/.NET interface such that it forces the code to 
express proxy or copy, then nobody gets confused when they look at the 
code. Other .NET languages might benefit from this Pythonic approach 
too... If a little more typing saves a lot of confusion, it is worth it.

Details:
??? (margins not big enough, you know..)

Drew

PS: Bob, that threadedselectreactor in twisted2 is neat stuff! thanks 
again! I'm still trying to digest how it made a tricky problem so easy, 
'cause it's a parallel to a problem I've been wrestling with at QVII.




More information about the Ironpython-users mailing list