This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients Yogesh.Chaudhari, dilettant, ezio.melotti, kushal.das, nedbat, neologix, pitrou, r.david.murray, serhiy.storchaka, trent, vstinner
Date 2013-05-13.21:21:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1368480080.4048.8.camel@fsol>
In-reply-to <>
> > 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.
Date User Action Args
2013-05-13 21:21:23pitrousetrecipients: + pitrou, vstinner, nedbat, trent, ezio.melotti, r.david.murray, neologix, serhiy.storchaka, kushal.das, dilettant, Yogesh.Chaudhari
2013-05-13 21:21:23pitroulinkissue17914 messages
2013-05-13 21:21:23pitroucreate