Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Dev

Issue #10278 -- why not just an attribute?

 

 

Python dev RSS feed   Index | Next | Previous | View Threaded


jimjjewett at gmail

Mar 19, 2012, 8:51 PM

Post #1 of 3 (115 views)
Permalink
Issue #10278 -- why not just an attribute?

In http://mail.python.org/pipermail/python-dev/2012-March/117762.html
Georg Brandl posted:

>> + If available, a monotonic clock is used. By default, if *strict* is False,
>> + the function falls back to another clock if the monotonic clock failed or is
>> + not available. If *strict* is True, raise an :exc:`OSError` on error or
>> + :exc:`NotImplementedError` if no monotonic clock is available.

> This is not clear to me. Why wouldn't it raise OSError on error even with
> strict=False? Please clarify which exception is raised in which case.

Passing strict as an argument seems like overkill since it will always
be meaningless on some (most?) platforms. Why not just use a function
attribute? Those few users who do care can check the value of
time.steady.monotonic before calling time.steady(); exceptions raised
will always be whatever the clock actually raises.

-jJ

--

If there are still threading problems with my replies, please
email me with details, so that I can try to resolve them. -jJ

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Mar 20, 2012, 2:25 AM

Post #2 of 3 (110 views)
Permalink
Re: Issue #10278 -- why not just an attribute? [In reply to]

2012/3/20 Jim J. Jewett <jimjjewett [at] gmail>:
>
>
> In http://mail.python.org/pipermail/python-dev/2012-March/117762.html
> Georg Brandl posted:
>
>>> +   If available, a monotonic clock is used. By default, if *strict* is False,
>>> +   the function falls back to another clock if the monotonic clock failed or is
>>> +   not available. If *strict* is True, raise an :exc:`OSError` on error or
>>> +   :exc:`NotImplementedError` if no monotonic clock is available.
>
>> This is not clear to me.  Why wouldn't it raise OSError on error even with
>> strict=False?  Please clarify which exception is raised in which case.
>
> Passing strict as an argument seems like overkill since it will always
> be meaningless on some (most?) platforms.  Why not just use a function
> attribute?  Those few users who do care can check the value of
> time.steady.monotonic before calling time.steady(); exceptions raised
> will always be whatever the clock actually raises.

The clock is chosen at runtime. You might use a different clock at
each call. In most cases, Python should chose a clock at the first
call and reuse it for next calls.

For example, on Linux the following clocks are tested:
- clock_gettime(CLOCK_MONONOTIC_RAW)
- clock_gettime(CLOCK_MONONOTIC)
- gettimeofday()
- ftime()

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


nas at arctrix

Mar 23, 2012, 1:21 PM

Post #3 of 3 (96 views)
Permalink
Re: Issue #10278 -- why not just an attribute? [In reply to]

Jim J. Jewett <jimjjewett [at] gmail> wrote:
> Passing strict as an argument seems like overkill since it will always
> be meaningless on some (most?) platforms.

A keyword argument that gets passed as a constant in the caller is
usually poor API. Why not have two different functions?

Neil

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

Python dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.