Charles-François Natali added the comment: > Python's goal is not to emulate the suboptimal parts of other languages.
Well, I'm sure they could have returned -1 or 0, which are valid C long distinct from any valid integer representing a number of CPUs. If the libc guys (and many other APIs out there ), chose to return 1 as default, there's a reason. Furthermore, you're missing the point: since the underlying libraries os.cpu_count() rely on return 1 when they can't determine the number of CPUs, why complicate the API by pretending to return None in that case, since you can't detect it in the first place? > We have dynamic typing, and so can return None from the same function that > returns 1. And we have compact expressions like `cpu_count() or 1`, so we > don't have to make unfortunate compromises. That's not because it's feasible that it's a good idea. Dynamic typing is different from no typing: the return type of a function is part of its API. You can't return None when you're supposed to return an int. If I go to a coffee machine to get some chocolate and there's no chocolate left, I don't want it to return me a coffee instead. What's looks more natural if os.cpu_count() is None or if os.cpu_count() >= 1 Even in dynamic typing, it's always a good thing to be consistent in parameter and return value type. Why? For example, PEP 362 formalizes function signatures. With a os.cpu_count() returning a number (or eventually raising an exception), the signature is: def cpu_count() -> int [...] What does it become if you can return None instead? For example, there's some discussion to use such signatures or other DSL to automatically generate the glue code needed to parse arguments and return values from C extension modules (PEP 436 and 437). Basically, you just implement: /* ** [annotation] ** @return int */ long cpu_count_impl(void) { long result = 1; #ifdef _SC_NPROCESSORS_CONF long = sysconf(_SC_NPROCESSORS_ONL); [...] #fi return result; } And the DSL processor takes care of the rest. What does this become if your return object isn't typed? Really, typing is of paramount importance, even in a dynamically typed language. And pretending to return a distinct value is pretty much useless, since the underlying platform will always return a default value of 1. Plus `cpu_count() or 1` is really ugly. Now I hope I made my point, but honestly at this point I don't care anymore, since in practice it should never return None. Documenting the None return value is just noise in the API... ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17914> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com