On Mar 26, 2012, at 6:31 PM, Zooko Wilcox-O'Hearn wrote: > On Fri, Mar 23, 2012 at 11:27 AM, Victor Stinner > <victor.stin...@gmail.com> wrote: >> >> time.steady(strict=False) is what you need to implement timeout. > > No, that doesn't fit my requirements, which are about event > scheduling, profiling, and timeouts. See below for more about my > requirements. > > I didn't say this explicitly enough in my previous post: > > Some use cases (timeouts, event scheduling, profiling, sensing) > require a steady clock. Others (calendaring, communicating times to > users, generating times for comparison to remote hosts) require a wall > clock. > > Now here's the kicker: each use case incur significant risks if it > uses the wrong kind of clock. > > If you're implementing event scheduling or sensing and control, and > you accidentally get a wall clock when you thought you had a steady > clock, then your program may go seriously wrong -- events may fire in > the wrong order, measurements of your sensors may be wildly incorrect. > This can lead to serious accidents. On the other hand, if you're > implementing calendaring or display of "real local time of day" to a > user, and you are using a steady clock for some reason, then you risk > displaying incorrect results to the user. > > So using one kind of clock and then "falling back" to the other kind > is a choice that should be rare, explicit, and discouraged. The > provision of such a function in the standard library is an attractive > nuisance -- a thing that people naturally think that they want when > they haven't though about it very carefully, but that is actually > dangerous. > > If someone has a use case which fits the "steady or else fall back to > wall clock" pattern, I would like to learn about it.
I feel that this should be emphasized. Zooko knows what he's talking about here. Listen to him :). (Antoine has the right idea. I think it's well past time for a PEP on this feature.) -glyph _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
