> > 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.