[Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Cameron Simpson]

On 05Apr2012 09:56, Guido van Rossum <guido at python.org> wrote:
| On Thu, Apr 5, 2012 at 9:48 AM, PJ Eby <pje at telecommunity.com> wrote:
| > What's missing is that if you're using a monotonic clock for timeouts, then
| > a monotonically-adjusted system clock can do that, subject to the polling
| > frequency -- it does not break just because the system clock is set
| > backwards; it simply loses time proportional to the frequency with which it
| > is polled.
| 
| Depending on the polling frequency sounds like a bad idea, since you
| can't know that you're the only user of the clock.

You can if you're handed a shiny new "clock" object in some way, with a
not-a-singleton guarrentee. Of course, such a clock is immediately
_less_ reliable to synchornisation with other clock users:-)

| Also depending on
| the use case, too short a timeout may be worse than too long a
| timeout. [...]
|
| > For timeout purposes in a single process, such a clock is useful.  It just
| > isn't suitable for benchmarks, or for interprocess coordination.
| 
| I think it would be better if the proposed algorithm (or whatever
| algorithm to "fix" timeouts) was implemented by the
| application/library code using the timeout (or provided as a separate
| library function), rather than by the clock, since the clock can't
| know what fallback behavior the app/lib needs.

Absolutely. I for one would be happy with a clocktools module or
something offering a bunch of synthetic clocks. Especially if they were
compatible in API with whatever clock objects the core time module
clocks used, so that a user _could_ add them into the pick-a-clock
decision easily.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

I'd be careful who you call smart or not smart. Smart isn't knowing how to
save six bytes. Smart is knowing WHEN. - Peter Cherna, Amiga O.S. Development