This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients Tamas.K, csernazs, grahamd, jcea, ncoghlan, neologix, pitrou, python-dev, tim.peters
Date 2013-09-06.06:31:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1378449102.2487.4.camel@fsol>
In-reply-to <1378426766.78.0.328967780995.issue18808@psf.upfronthosting.co.za>
Content
Le vendredi 06 septembre 2013 à 00:19 +0000, Tim Peters a écrit :
> Tim Peters added the comment:
> 
> So you're not concerned about a now-private API (which used to be
> advertised), but are concerned about a user mucking with a new private
> lock in an exceedingly unlikely (in the absence of malice) way.  That
> clarifies things ;-)

:-)
The only reason I'm concerned about the user mucking with the private
lock is that it's a new opportunity that's opened. But, yeah, I could
remove the weakref and only keep the lock. The code would only be ~10
lines shorter, though. What do other people think?

> in its end-of-life code.  Essentially rolling their own clumsy variant
> of a Semaphore.

I guess they spell it like:

  import clumsy_threading as threading

> I've seen code like that "in the wild".

Well, I've sure seen my share of sleep() calls as a synchronization
measure too (and removed a number of them)... :-)
That's one of the reasons I added the timeout arguments, actually.
History
Date User Action Args
2013-09-06 06:31:48pitrousetrecipients: + pitrou, tim.peters, jcea, csernazs, ncoghlan, grahamd, neologix, python-dev, Tamas.K
2013-09-06 06:31:48pitroulinkissue18808 messages
2013-09-06 06:31:47pitroucreate