Python11/12 doesn't have time.CLOCK_BOOTTIME on Mac

Python Help
1

Hey folks,

My first post as a new python.org account holder. I’ve been programming in Python for several years, and maybe I’m an average Python programmer by now.

The products I work on are all Linux-based. Over the years those products have used Python 3.5, 3.11 and 3.12. I’ve done a fair amount of Python dev on my Macbook Pro, using the same Python version on my Mac that our products use.

Currently my Mac is running 15.3.2 and I have Python 3.11.3 and 3.12.8 installed. These have been installed using pip (currently version 25.0.1).

My dilemma: I had just written some code and ran pylint 3.3.6 against it, and got an error because I made use of time.CLOCK_BOOTTIME.

escan.py:2741:35: E1101: Module 'time' has no 'CLOCK_BOOTTIME' member (no-member)

That struck me as odd, since time.CLOCK_BOOTTIME dates back to Python 3.7. But a quick test proved that on my Mac neither 3.11.3 nor 3.12.8 have time.CLOCK_BOOTTIME. In contrast, if I perform the same test on our products that run those versions of Python (on Linux) then there’s no problem, it’s present.

Here’s the failure on my Mac with Python 3.12.8:

$ python3.12
Python 3.12.8 (v3.12.8:2dc476bcb91, Dec  3 2024, 14:43:20) [Clang 13.0.0 (clang-1300.0.29.30)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.CLOCK_BOOTTIME
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'time' has no attribute 'CLOCK_BOOTTIME'. Did you mean: 'CLOCK_REALTIME'?
>>>

On the product that uses 3.12 I get the expected value of 7.

Can anybody please help me understand how a built-in such as time could be different for the same Python version but different target OSes (Linux vs Macos)?

I have done quite a few internet searches about this and come up empty so far. I’ll keep searching, and welcome any URLs that have addressed this.

Thanks so much for any thoughts/ideas/tips/links.

Blessings,
Doug

2

See the note about the availability for Linux. I read this as meaning that it’s not available for Mac (nor Windows).

2 Likes
3

Dear André,

Thank you so much for the reply. I saw that note about 3.6.39 and later on Linux, but I probably misinterpreted it to mean it showed up early on Linux and was generally available on all platforms starting in 3.7. It seems to me unportable for these members to only be available on a single platform. But perhaps it’s a case where some platforms do not have the functionality to support certain members.

I suppose I can change to time.MONOTONIC, which will probably service the necessary purpose. Or, I can ignore the pylint error on my Mac and leave it as is.

Thank you for suggesting a different (and probably best) interpretation of that note.

Blessings,
Doug

4

Ah, it’s a little confusing, but that’s actually talking about the Linux version, not the Python version. It was added in Python version 3.7, but the number you’re reading there is Linux >= 2.6.39, which is a kernel version. (You can basically read this as just saying “Linux” for the most part - version 2.6.39 was released in 2011 so you’ll be unlikely to see anything older.) Since it doesn’t have any indication of availability on any other platform, it’s not going to be supported on a Mac. Sorry.

1 Like
5

Dear Chris,

Perfect. You’ve corrected another mistake I made interpreting the spec. I’m very thankful.

So now I understand both the specifics about time.CLOCK_BOOTTIME and the more general aspect of Python that I must take great care when using even the standard library that portability is not guaranteed.

I’m so thankful for the excellent, informative help. And so quick too!

Thanks so much!

Blessings,
Doug

6

That is true, but there are only a few modules where portability is uncertain. Other than those, you’ll mostly be able to assume portability. Places to be careful are:

  • Unix sockets (the socket module and anything that calls on it) which aren’t available on Windows
  • Some specific high-performance event loops for asyncio (the default one will always work, but if you select something in particular, the choices available differ by platform)
  • Access to low level facilities provided by the operating system, eg some parts of ctypes and some functions in the os module - but, again, a lot of it is fully portable
  • Certain aspects of file system handling. Sadly, there’s no getting around this one; different OSes and different file systems have different types of things available.
  • Signal handling since, again, a lot of these are OS-specific. You can rely on getting a Ctrl-C signal, and there’ll always be some sort of termination signal, but you won’t find (eg) SIGWINCH on Windows.
  • As you’ve discovered, the precise set of available timers; but, again, there’s some that are common, and then the ones that aren’t
  • A handful of other small details that usually won’t bother you.

Most of Python - the vast, vast majority of it - is completely cross-platform. If none of the things I listed above is going to trip you up, then you can basically just pretend that Python is the platform, and operating systems are irrelevant. It won’t be always exactly true but it’s extremely close to it.

1 Like