On Mon, 16 Jun 2003, Michel Pelletier wrote:
def __init__(self): self.counter = 0 def increment(self): synchronize: self.counter += 1
What about just adding a parameter to try operator?
def increment(self): try self.counter_lock: self.counter += 1
- this will save from keyword and could also be used with except part with, for example, se-syncronization outcomes for some kinds of locks:
def increment(self): try self.counter_lock: self.counter += 1 except SomeLockError: bla-bla-bla
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.
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
Sincerely yours, Roman A.Suzi