Bob Ippolito wrote:
I kinda like both of these options. Darn dual paradigm.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)
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.
_______________________________________________ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
