Since my name was invoked recently on this thread (albeit with a question mark), let me try to summarize: We all agree that mutability introduces interesting issues, particularly in the face of true concurrency. Language designers are very interested in languages with semantics that avoid or minimize these problems. As a Prologer at heart, I'm a big fan of unification semantics myself. I think we all also agree that Python is an OO language, and as such it institutionalizes side-effects. OO is not functional, it is not single assignment, it is not dataflow. It is a different computational model, and one that makes use of mutable objects as an inherent feature of design. We use objects to enacpsulate changeable state. When designing a system using OO, I as the designer make choices about what types (mutable vs. immutable) make the most sense for my design. That evaluation involves issues such as efficiency, maintainablility, and elegance. I understand Arthur to be saying: "In my design, a container for a complex that masquerades as a complex is a good and useful type." Without taking a detailed look at his code and the design ramifications of that choice, I personally have no basis for saying it's a bad decision (or a good one, for that matter). He is aware of the risks of mutability and has decided his design criteria still calls for it. Even though I'm a CS type (sometimes that's a pejorative here, I know), Arthur has my blessing to use the tools of his chosen paradigm (OOP) to solve his problem in an elegant way. If that's all he's looking for, then we can close the thread :-). BTW, I have also found this discussion very interesting, if not particularly helpful for Arthur. --John On Thursday 23 March 2006 10:00, Laura Creighton wrote:
In a message of Thu, 23 Mar 2006 16:24:39 +0100, Grégoire Dooms writes:
Arthur wrote:
-----Original Message----- From: Laura Creighton [mailto:lac@strakt.com]
And I think he will like tens of thousands of threads, too, though if these just means tens of thousands of chances to modify only part of your complex number, when you wanted an atomic action guaranteed to modify both parts as one, then he may hate it before he likes it. :-)
Sorry - I suspect everyone else is quite done with this, but I'm still bothered by mixed signals.
I would like to be able to present PyGeo as good, sensible code. Not M
useum
Quality, to be sure. But good and responsible.
There is an implication in what you are saying that I am still off the
mark.
Perhaps I am. But its not fair, in my mind, to throw that at me knowin
g
that it still has not gotten through to me (and Zelle ?) in what way I
am
off the mark.
For the life of me I don't see the problem. My class has 2 __slots__ - .real and .imag. It does with them the kind of things that classes do.
How is this class different and less thread safe than an infinite numbe
r of
other classes that do with attributes the kinds of things that classes
do
with attributes?
This is a complex matter and I'll try to give a very short (hence a little categoric) answer. First of all, IMO Laura was referring to several thousands of lightweight thread such as those found in the Oz/Mozart language (http://www.mozart-oz.org). And that is because we have had a PyPy/Oz sprint two weeks ago where we made plans and prototypes for the integration of some ideas of Mozart into PyPy (mostly logic variables, "search", and constraint programming, micro-threads were already on the g o).
In that language stateful datatypes such as mutable objects are an exception. By default the variable store is a single assignment store. That means when you create a variable (e.g. with this statement X=_ ) it is uninitialized (called unbound). Then when you assign it you cannot rebind it to an other value: X=4 works but if you do X=5 later you get a sort of exception (failure). In a sense = does not do assignment but true mathematical equality (called unification). So you can do 4=X as well as 1+X = 5. The language supports very lightweight threads (having a million of those is no problem), when they try to "use" the value of a variable , they block if the variable is unbound. So you can launch inter-dependant threads accessing values computed by each others without wondering about the synchronization. That is called dataflow concurrency.
In a sense, your mutable complex object is opposite to that approach where (almost) all variables never ever change their value.
I have unintentionally stimulated a CS nerve, apparently. But would s
till
love to get to the bottom of issue.
HTH :-)
Or get an official CS - proper use case aside - bill of health.
I would refer you to the CTM book: http://www2.info.ucl.ac.be/people/PVR/book.html You will find there lots of interresting ideas about computer language semantics.
Best, -- Grégoire Dooms
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Thank you Grégoire for writing that. Much better than I could.
Arthur, classes are not safe either. Say you have class that has two attributes, myclass.price and myclass.tax, and an update method that first assigns a new value to the price, and then, sometime later, even the very next line, assigns tax to be 7% of the price, unless the tax is over 300,000 in which case the tax is 300,000
very simple. And if you only have 1 thread, you are guaranteed that nobody is going to get a hold of an instance of myclass where the price has been changed, but that tax hasn't yet. Only one thing gets to run at all, so there is nobody else, to get a hold of things.
Now add threading. Ooops, one thread could be using an instance while the other was updating it. Very bad for you. You need a way to lock' the object and say 'nobody gets to use this thing until I am done with it'.
You can implement your own locking mechanism. Or you could use a language type that comes with the language -- a tuple, for instance -- which guarantees this atomicity you want. Then it is the language implementor's headache to make the locking mechanism work.
Laura _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
-- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle@wartburg.edu (319) 352-8360