[Python-ideas] Fwd: Concurrent safety?

[Mike Meyer]

On Tue, Nov 1, 2011 at 1:01 AM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> Mike Meyer writes:
>  > I've identified the problem I want to solve: I want to make
>  > concurrent use of python objects "safe by default",
> But that's not what you've proposed, AIUI.  You've proposed making
> concurrent use *safer*, but not yet *safe*.  That's quite different
> from the analogy with automatic memory management, where the
> programmer can't do anything dangerous with pointers (because they
> can't do anything at all).  The analogous model for concurrency is
> processes, it seems to me.  (I don't have a desperate need for high-
> performance concurrency, so I take no position on processes + message
> passing vs. threads + shared resources.)
>

No, the proposal does make things "safe by default". The default behavior
disallows all mutation. You have to do something explicit to allow it -
because "explicit is better than implicit."


>  > so that doing unsafe things causes the programmer to have to do
>  > something explicit about making things safe.
> This is un-Pythonic, IMO[1].  Python generally permits dangerous (and
> even ugly) things when done by "consenting adults", on the theory that
> the programmer knows more about her problem than Python does.  It
> seems to me that a more Pythonic approach to this would be to provide
> something like STM as a metaclass, mixin class, or decorator.  (Don't
> ask me how.)
>

Adding STM would make concurrency easier to deal with, but wouldn't address
the fundamental problem.

The proposed change doesn't prevent users from doing dangerous (and even
ugly things). It just forces them to *think* about what they're doing
beforehand. I can even see allowing immutable objects to change their
attributes, with the caveat that this shouldn't change the externally
visible behavior of the object.


>  > I believe this can be done at the mutation points (again, clojure
>  > shows that it can be done).
> But clojure is a Lisp-derived language.  Lisp was designed as a pure
> functional language (although AFAIK it pretty much immediately
> acquired "set"), and a very large number of Lisp algorithms are
> designed around conses which are (like Python tuples) basically
> immutable (yes, I know about setcar and setcdr, but use of those
> functions is generally considered a bug).  Whether that orientation
> toward immutable objects continues in Clojure I don't know, but if it
> does, the problem of designing a "write barrier" for mutations may be
> (a) simpler and (b) have less performance impact than the analogous
> task applied to Python.


Um, yeah, I did point out  later in the paragraph that preserving pythons
data types may make this assumption false.


> While Python-the-language does have some immutable objects like tuples
> and strings, it's really kind of hard to avoid use of containers like
> lists and dictionaries and classes with mutable objects.
>

And I also pointed out that this may be to much of a change to be palatable
to Python users. For that matter, if it requires losing pythons primitive
container types, it's probably to much of a change to be palatable to me.

    <mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20111101/a97c161e/attachment.html>