A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2012-April/118471.html below:

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

[Python-Dev] PEP 418 is too divisive and confusing and should be postponed [Python-Dev] PEP 418 is too divisive and confusing and should be postponedAntoine Pitrou solipsis at pitrou.net
Wed Apr 4 11:52:24 CEST 2012
On Wed, 4 Apr 2012 18:09:40 +1000
Steven D'Aprano <steve at pearwood.info> wrote:
> > Python 3.3 has already time.clock_gettime() and time.clock_getres() with 
> > CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW, CLOCK_HIGHRES.
> 
> Why does it already have these things when the PEP is not accepted? 
> 
> (This is not a rhetorical question, perhaps there is a good reason why 
> these have been added independently of the PEP.)

Because these are thin (low-level) wrappers around the corresponding
POSIX APIs, so there is no reason not to add them.

I know you were asking for such wrappers to be in the "os" module, but
my understanding is that time-related functions should preferably go
into the "time" module. "os" is already full of very diverse stuff, and
documentation-wise it is better if time-related functions end up in a
time-related module. Otherwise we'll end up having to cross-link
manually, which is always cumbersome (for us) and less practical (for
the reader).

Regards

Antoine.


More information about the Python-Dev mailing list

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