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/2003-July/036684.html below:

[Python-Dev] release candidate rules and timeit API question

[Python-Dev] release candidate rules and timeit API question [Python-Dev] release candidate rules and timeit API questionGuido van Rossum guido@python.org
Tue, 01 Jul 2003 11:50:49 -0400
>     Guido> I wonder if the right refactoring wouldn't be to add an acquire
>     Guido> with timeout method to the built-in lock type?

[Sjoerd]
> In my case I use await_condition() to gracefully empty a Queue of database
> connection objects at termination time.
[...]
> It's a bit clunky, but I wouldn't be able to use an acquire() with a
> timeout directly.  I'd need a Queue.get with a timeout as well.

Yes, but that API change would be useful anyway.

> Besides, wouldn't there be places where this progressive backoff
> would be useful in non-threaded contexts?

Unclear, but it's unclear to me if it really is more readable with a
helper function to express the condition passed in rather than just
written out explicitly (everyone writes these a little different, and
that's just fine with me).

--Guido van Rossum (home page: http://www.python.org/~guido/)



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