Alexander Belopolsky added the comment:
See also discussion in #9079, #14127 and #14180. At some point there was some
resistance to use capsule mechanism to share code within stdlib and the
functions that were shared between time and datetime modules were moved to the
core.
I am -1 on adding struct_timespec type.
POSIX defines [1] the following functions that take struct timespec:
int clock_getres(clockid_t, struct timespec *);
int clock_gettime(clockid_t, struct timespec *);
int clock_settime(clockid_t, const struct timespec *);
int nanosleep(const struct timespec *, struct timespec *);
and a pair of timer functions that take timespec indirectly through itimerspec
struct:
int timer_gettime(timer_t, struct itimerspec *);
int timer_settime(timer_t, int, const struct itimerspec *,
struct itimerspec *);
In addition, struct stat provides timespec members on some systems.
There was a long discussion on how to represent high precession time in Python.
PEP 410 proposed using the decimal type and it was rejected.
Nanosecond support was ultimately added to os.struct() by adding integer
st_{a,m,c}time_ns members. See #14127.
Interface to nanosleep is already available via time.sleep() function. If we
ever need higher precision sleep we can add time.nanosleep() that takes time in
nanoseconds. We have a similar story with time.clock().
Overall, the proposed type is much less convenient than integer nanoseconds
because it does not support arithmetics.
In any case, I think it is premature to discuss adding a new type before some
functions are proposed that would produce or consume instances of this type.
[1] http://pubs.opengroup.org/onlinepubs/7908799/xsh/time.h.html
----------
nosy: +haypo
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23084>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
