[Edu-sig] Properties use case

[John Zelle]

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 at 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 at 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 at 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 at wartburg.edu          (319) 352-8360