On Feb 20, 10:15 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > | Because UNIX uses priorities between +20 and -20 and Windows, via > | Process and Thread priorities, allows settings between 0 and 31, a > | uniform setting for each system should be derived. This would be > | accomplished by giving process priority in terms of a floating-point > | value between 0.0 and 1.0 for lowest and highest possible priority, > | respectively. > > I would rather that the feature use the -20 to 20 priorities and map that > appropriately to the Windows range on Windows.
The problem as I see it is that -20 to +20 is only just over 5 bits of precision and I can easily imagine an OS with many more than just 5 bits to specify a process priority. Of course, the os.getpriority and os.setpriority, being specific to UNIX, WOULD use the -20 to +20 scale, it's just the generic subprocess that would not. But for a generic priority, I like floating point because it gives 52 bits of precision on most platforms. This would allow for the most flexibility. Also, 0.0 to 1.0 is in some ways more intuitive to new programmers because it can be modeled as ~0% CPU usage vs. ~100% CPU usage, theoretically. Users not familiar with UNIX might OTHO be confused by the idea that a lower priority number constitutes a "higher priority". Of course, the scale used for p in Popen(...).setPriority(p) is really not an important issue to me as long as it makes sense in the context of priorities. Given that os.setpriority and Popen(...).setPriority have virtually the same name, it would probably be better to rename the later to something a bit less prone to confusion. Alternatively, it would not be unreasonable to design setPriority (and getPriority correspondingly) such that under UNIX it takes 1 parameter, -20 to +20 and under Windows it takes 2 parameters, second one optional, where the Windows API priorities are directly passed to it (for getPriority, Windows would return a Tuple pair corresponding to Priority Class and Main Thread Priority). However, I personally prefer a unified definition for subprocess.py's Priority since there already is or will be direct os-level methods to accomplish the same thing in the os- native scale. Anyway, thanks for the input and I will make a note of it in the PEP. Other than the generic Property ranges, do you see any other issues with my proposal? Jeffrey. -- http://mail.python.org/mailman/listinfo/python-list