[Python-Dev] New PEP: 319

[Michel Pelletier]

>> You need to be *much* clearer about the proposed interface between the
>> ``synchronize`` keyword and Python objects.
>
> I agree with Aahz; especially the scope of the lock used by an
> anonymous synchronize block is ambiguous in the current PEP.  In one
> example it appears that there is a lock associated with each
> unqualified use of the synchronize keyword; in another, it seems that
> unqualified uses in the same class share a lock.
>
> Please try to explain the semantics of named and unnamed synchronize
> calls entirely in terms of code that would work in current Python,
> without using English (other than "this code is equivalent to that
> code").

Here is a (hopefully) clearer snippet I am working on in the revision:

        class SynchronizedCounter:

            def __init__(self):
                self.counter = 0
                self.counter_lock = thread.allocate_lock()

            def increment(self):
                self.counter_lock.acquire()
                try:
                    self.counter += 1
                finally:
                    self.counter_lock.release()

in my mind I wanted to replace with:

        class SynchronizedCounter:

            def __init__(self):
                 self.counter = 0

            def increment(self):
                synchronize:
                    self.counter += 1

Is your question, What is the unqualified lock associated with, the
instance, the class, the method, the counter, or something else?  If it is
your question then the answer is I'm not sure now that I've thought about
it deeper.  Clearly the concept of the synchronization is around the
counter, although now I can see no way to associate that implicitly. 
Perhaps this is why Java does not have unqualified synchronized blocks and
maybe I should remove it in which case the previous code would be:

        class SynchronizedCounter:

            def __init__(self):
                 self.counter = 0

            def increment(self):
                synchronize self.counter:
                    self.counter += 1

> I'd also like to see how 'asynchronize' works with condition
> variables, which seem to be the most common use for temporarily
> unlocking.

I will look into that.

> (Your example of how code would do this without
> asynchronize has a bug, by the way; if the I/O operation raises an
> exception, the finally clause will attempt to release an already
> released lock.)

Yes I need another try/finally in there.  Thanks.

> I think the PEP would be clearer if it was considerably shorter and to
> the point, with fewer examples and a more exact specification.

Thanks for the advice, I will move my thinking in this direction.

-Michel