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 neologix
Recipients Yogesh.Chaudhari, dilettant, ezio.melotti, kushal.das, nedbat, neologix, pitrou, r.david.murray, serhiy.storchaka, trent, vstinner
Date 2013-05-13.21:15:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM1ChQotWVNTuwUS-8VSEJRSxsAB7i0Lxuo8CErWc2T5xg@mail.gmail.com>
In-reply-to <1368475529.19.0.545562465188.issue17914@psf.upfronthosting.co.za>
Content
> 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...
History
Date User Action Args
2013-05-13 21:15:53neologixsetrecipients: + neologix, pitrou, vstinner, nedbat, trent, ezio.melotti, r.david.murray, serhiy.storchaka, kushal.das, dilettant, Yogesh.Chaudhari
2013-05-13 21:15:53neologixlinkissue17914 messages
2013-05-13 21:15:52neologixcreate