Define `priority` semantics

[RealOrangeOne]

The priority field is currently an opaque positive integer. As currently implemented:

• "Higher priority" (ie more urgent) is encoded as a greater priority value
• Tasks which don't define a priority are set as 0.

This presents a few issues:

• The maximum value is unbounded, which could cause issues with different database backends
• It's not possible to define a task as being lower priority than the default (without defining your own default and using it across your application (which doesn't work for external tasks))

Therefore, the scale needs to be better defined:

• How many increments are needed? 10, 50, 100, 1000 etc
• How are lower-than-default priority tasks encoded? Use 0 as the default and support negative? Set the default as half way through the range?

[jribbens]

I would suggest a default of zero, a range of -128 to +127, and also define some constants, e.g.:

    class Priority(IntEnum):
        LOWEST = -128
        LOWER = -96
        LOW = -48
        DEFAULT = 0
        HIGH = 48
        HIGHER = 96
        HIGHEST = 127

and then people can use the constants to increase the likelihood of priorities set by different packages being suitable when used together, and also they can say things like Priority.HIGH + 1 to mean "a little bit higher priority than HIGH but not as high as HIGHEST".

(One might reasonably say "why would anyone care if a value fits in 8 bits in the modern world" but one might also reasonably reply "why on earth would you need more than 256 different priorities?". There are lessons to be learned I think from things like CSS z-index where people end up using ridiculous values like 999999999 because there are no guidelines whatsoever as to what values to use - there's no way of saying what you actually mean rather than just picking a random number and hoping.)

Also I don't think the DEP defines what the priority actually means. Presumably it means "while tasks of priority X are ready to run, no tasks with priority less than X will be run, no matter how old/overdue they are"? This should probably be made explicit.

[RealOrangeOne]

Priority is indeed the biggest measure - not how overdue it is.

I'd not thought of constants - I really like this idea, even if just as a basis. Having 0 in the middle is definitely the way I'm leaning.

256 priorities ought to be enough for anyone (famous last words). Unbounded is going to almost certainly cause issues with other backends. At least with a fixed range it's possible to re-divide that to any smaller range (albeit losing some resolution). Even with the above, you could argue 7 steps is probably enough - fine-grained priorities could end in bike-shedding. I'd be tempted to use 100 either side instead, simply because as humans it's easier to reason about, and the extra 56 priorities probably aren't useful to most.