Marc-Andre Lemburg <m...@egenix.com> added the comment:
STINNER Victor wrote:
>
> STINNER Victor <victor.stin...@gmail.com> added the comment:
>
>> I think you need to reconsider the time.steady() name you're using
>> in the PEP. For practical purposes, it's better to call it
>> time.monotonic()
>
> I opened a new thread on python-dev to discuss this topic.
>
>> and only make the function available if the OS provides
>> a monotonic clock.
>
> Oh, I should explain this choice in the PEP. Basically, the idea is to
> provide a best-effort portable function.
>
>> The fallback to time.time() is not a good idea, since then the programmer
>> has to check whether the timer really provides the features she's after
>> every time it gets used.
>
> Nope, time.get_clock_info('steady') does not change at runtime. So it
> can only be checked once.
With "every time" I meant: in every application you use the function.
That pretty much spoils the idea of a best effort portable function.
It's better to use a try-except to test for availability of
functions than to have to (remember to) call a separate function
to find out the characteristics of the best effort approach.
>> Instead of trying to tweak all the different clocks and timers into
>> a single function, wouldn't it be better to expose each kind as a
>> different function and then let the programmer decide which fits
>> best ?!
>
> This is a completly different approach. It should be discussed on
> python-dev, not in the bug tracker please. I think that Python can
> help the developer to write portable code by providing high-level
> functions because clock properties are well known (e.g. see
> time.get_clock_info).
Fair enough.
BTW: Are aware of the existing systimes.py module in pybench,
which already provides interfaces to high resolution timers usable
for benchmarking in a portable way ? Perhaps worth mentioning in
the PEP.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14428>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
