Antoine Pitrou 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.
Well, they can be wrong sometimes, too :-) > 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? The patch doesn't seem to rely on the glibc, so we are fine here. Or do the other libs work likewise? > And the DSL processor takes care of the rest. > > What does this become if your return object isn't typed? It's typed, just the type is "int or None". I'm sure some statically-typed languages are able to express this (OCaml? Haskell?). Anyway, I don't mind whether it's None or 0 or -42. But let's not hide the information. ---------- _______________________________________ 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
