A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2004-August/046815.html below:

[Python-Dev] Re: 2.4a2, and @decorators

[Python-Dev] Re: 2.4a2, and @decoratorsPhillip J. Eby pje at telecommunity.com
Wed Aug 4 18:36:09 CEST 2004
At 06:09 PM 8/4/04 +0200, Heiko Wundram wrote:
>Am Mittwoch, 4. August 2004 17:17 schrieb Batista, Facundo:
> > So, all that said, I'm +1 to take this out from 2.4.
>
>-1000 to take it out from 2.4... And +1 on Guido's intuition for choosing the
>@ syntax (it goes easily for me). I'd love to see something of the following
>form:
>
>class x:
>         synchronized = threading.Synchronizer()
>
>         @synchronized
>         def y(self):
>                 <do something>
>
>When's threading.Synchronizer coming (just a threading.(R)Lock with an extra
>__call__ which prepares a method for synchronization with this lock)? I
>already have some patches which implement module/class/instance locking using
>just a simple RLock and the decorator syntax, and I'd gladly sign over the
>patches to the PSF. ;)

Note that your example, if I understand it correctly, creates a single lock 
for all instances of class 'x', rather than for individual instances of 
'x'.  This is not what I'd normally expect from a 'synchronized' method.

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4