os.nice (or docs) BUG?

[Thomas Wouters]

On Tue, Jul 10, 2001 at 12:52:00PM +0400, Roman Suzi wrote:

> The following from the Python docs:

>    nice (increment)
>           Add increment to the process's ``niceness''. Return the new
>           niceness. Availability: Unix.

> Contradicts what I see in python 1.5.2 - 2.1:

> >>> import os
> >>> os.nice(1)
> 0
> >>> os.nice(5)
> 0

> It's docs inaccuracy or os.nice() bug? Or glibc bug?

It's more or less a bug, under Linux. (I guess you're using Linux, since you
mention 'glibc'.) If you look at posixmodule.c, you'll notice:

static PyObject *
posix_nice(PyObject *self, PyObject *args)
{
        int increment, value;

        if (!PyArg_ParseTuple(args, "i:nice", &increment))
                return NULL;
        value = nice(increment);
        if (value == -1)
                return posix_error();
        return PyInt_FromLong((long) value);
}

it simply returns the value returned by the 'nice' system call. The Linux
'nice' manpage has this to note:

NOTES
       Note that the routine is documented in SUSv2 to return the
       new nice value, while the Linux syscall and  (g)libc  rou-
       tines return 0 on success. The new nice value can be found
       using getpriority(2).   Note  that  an  implementation  in
       which  nice  returns  the  new nice value can legitimately
       return -1.  To reliably detect an error, set  errno  to  0
       before the call, and check its value when nice returns -1.

> Which category to report it in the Bug tracker?

'Python Library' is the best fit, I guess, but it doesn't really matter.
The group should be 'platform specific', though :) Feel free to assign it
to me, I think I'll check in a fix soon anyway :)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!