[Python-Dev] New PEP: 319

[Roman Suzi]

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.
> 
> -Michel
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> 

Sincerely yours, Roman A.Suzi
-- 
 - Petrozavodsk - Karelia - Russia - mailto:rnd@onego.ru -