Re: [Edu-sig] Properties use case
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
Then it is the language implementor's headache to make the locking mechanism work.
"from threading import Lock" generally works for me. Arthur is not implementing a general purpose thread-safe language, so like him I continue to be confused as to the relevance of this conversation to his project. This conversation has indeed been interesting. In particular I appreciate the explanation of what Oz is about. However, one should make clear whether one is musing or offering advice. It's my impression that the advice now boils down either to None, or to abandon Python for Oz, neither of which is very helpful. Did I miss something? mt
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
If I were Arthur and trying to ensure my PyGeo source was "camera ready" from a code teaching point of view, I'd probably open source it on sourceforge, making the checkin/checkout process easy, and recruit apprentice PyGeo coders into the fold. They'd learn the ropes and propose enhancements or refactorings. There'd be more than one pair of eyes, more than one brain, working on the code. Design patterns such as we've been discussing, would get hashed out among insiders, less so in a generic public forum like edu-sig. As long as it's just Arthur writing everything, and soliciting advice from people who haven't made a concerted study of his work, I don't have any confidance that the code will be camera ready as some showcase for beautiful code. If this were Gerald de Jong, or Guido, or Tim Peters we were talking about, I might have a different assessment. But Arthur didn't grow up in computer world, is a johnny come lately, bearing much cultural baggage. He needs professional help, in my estimation. In my own case, I've posted working code, e.g. for a presentation manager using PyGame, that's obviously idiosyncratic, not peer-reviewed let alone peer-enhanced. I've been up front with my corresponding expectation: this source code won't be very useful to others -- except maybe in the case of the OSCON 2005 source wherein I buried some notes of historical interest, but that's a different notion of utility. Kirby
Thank you for the advice, Mr. Urner. Happy Dethe? Art If I were Arthur and trying to ensure my PyGeo source was "camera ready" from a code teaching point of view, I'd probably open source it on sourceforge, making the checkin/checkout process easy, and recruit apprentice PyGeo coders into the fold. They'd learn the ropes and propose enhancements or refactorings. There'd be more than one pair of eyes, more than one brain, working on the code. Design patterns such as we've been discussing, would get hashed out among insiders, less so in a generic public forum like edu-sig. As long as it's just Arthur writing everything, and soliciting advice from people who haven't made a concerted study of his work, I don't have any confidance that the code will be camera ready as some showcase for beautiful code. If this were Gerald de Jong, or Guido, or Tim Peters we were talking about, I might have a different assessment. But Arthur didn't grow up in computer world, is a johnny come lately, bearing much cultural baggage. He needs professional help, in my estimation. In my own case, I've posted working code, e.g. for a presentation manager using PyGame, that's obviously idiosyncratic, not peer-reviewed let alone peer-enhanced. I've been up front with my corresponding expectation: this source code won't be very useful to others -- except maybe in the case of the OSCON 2005 source wherein I buried some notes of historical interest, but that's a different notion of utility. Kirby _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
participants (5)
-
ajsiegel＠optonline.net -
John Zelle -
kirby urner -
Laura Creighton -
Michael Tobis