Showing content from http://mail.python.org/pipermail/python-dev/attachments/20120402/70587611/attachment-0001.html below:
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#330033">
On 4/2/2012 4:37 AM, Victor Stinner wrote:
<blockquote
cite="mid:CAMpsgwYnTYyu=XXfysgq5bTeVY5UAxNimOpVz3qzbsOyPcYMDg@mail.gmail.com"
type="cite">
<pre wrap="">The API looks much more complex than the API proposed in PEP 418 just
to get the time. You have to call a function to get a function, and
then call the function, instead of just calling a function directly.
Instead of returning an object with a now() method, I would prefer to
get directly the function getting time, and another function to get
"metadata" of the clock.</pre>
</blockquote>
<br>
If there are more than two clocks, with different characteristics,
no API is going to be both simple to use and fast to call.<br>
<br>
If there are more than two clocks, with different characteristics,
then having an API to get the right API to call to get a time seems
very natural to me.<br>
<br>
One thing I don't like about the idea of fallback being buried under
some API is that the efficiency of that API on each call must be
less than the efficiency of directly calling an API to get a single
clock's time. For frequently called high resolution clocks, this is
more burdensome than infrequently called clocks.... yet those seem
to be the ones for which fallbacks are proposed, because of
potential unavailability.<br>
<br>
Having properties on each of various different clock functions is
cumbersome... the user code must know about each clock, how to
obtain the properties, and then how to choose one for use... And how
will one be chosen for use? Under the assumption that all return
some sort of timestamp and take no parameters, a local name will be
assigned to the clock of interest:<br>
<br>
if ...:<br>
    myTime = os.monotonous<br>
elif ...:<br>
   myTime = os.evenhigherres<br>
...<br>
elif ...:<br>
    myTime = time. time<br>
<br>
so that myTime can be use throughout. Cameron's API hides all the
names of the clocks, and instead offers to do the conditional logic
for you, and the resultant API returned can be directly assigned to
myTime, and the logic for choosing a clock deals only with the
properties of the clock, not the names of the APIs, which is a nice
abstraction. There would not even be a need to document the actual
names of the APIs for each individual clock, except that probably
some folks would want to directly code them, especially if they are
not interested in cross-platform work.<br>
<br>
The only thing I'm not so sure about: can the properties be
described by flags? Might it not be better to have an API that
allows specification of minimum resolution, in terms of fractional
seconds? Perhaps other properties suffice as flags, but perhaps not
resolution.<br>
</body>
</html>
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