This PEP has been rejected by the BDFL [12]. As per the
pseudo-sunset clause [13], PEP 326 is being updated one last time
with the latest suggestions, code modifications, etc., and includes a
link to a module [14] that implements the behavior described in the
PEP. Users who desire the behavior listed in this PEP are encouraged
to use the module for the reasons listed in
Independent Implementations?.

This PEP proposes two singleton constants that represent a top and
bottom [3] value: Max and Min (or two similarly suggestive
names [4]; see Open Issues).

As suggested by their names, Max and Min would compare higher
or lower than any other object (respectively). Such behavior results
in easier to understand code and fewer special cases in which a
temporary minimum or maximum value is required, and an actual minimum
or maximum numeric value is not limited.

While None can be used as an absolute minimum that any value can
attain [1], this may be deprecated [4] in Python 3.0 and shouldn't
be relied upon.

As a replacement for None being used as an absolute minimum, as
well as the introduction of an absolute maximum, the introduction of
two singleton constants Max and Min address concerns for the
constants to be self-documenting.

What is commonly done to deal with absolute minimum or maximum values,
is to set a value that is larger than the script author ever expects
the input to reach, and hope that it isn't reached.

Guido has brought up [2] the fact that there exists two constants
that can be used in the interim for maximum values: sys.maxint and
floating point positive infinity (1e309 will evaluate to positive
infinity). However, each has their drawbacks.

On most architectures sys.maxint is arbitrarily small (2**31-1 or
2**63-1) and can be easily eclipsed by large 'long' integers or
floating point numbers.

Comparing long integers larger than the largest floating point
number representable against any float will result in an exception
being raised:

There are hundreds of algorithms that begin by initializing some set
of values to a logical (or numeric) infinity or negative infinity.
Python lacks either infinity that works consistently or really is the
most extreme value that can be attained. By adding Max and
Min, Python would have a real maximum and minimum value, and such
algorithms can become clearer due to the reduction of special cases.

When testing various kinds of servers, it is sometimes necessary to
only serve a certain number of clients before exiting, which results
in code like the following:

count = 5
def counts(stop):
i = 0
while i < stop:
yield i
i += 1
for client_number in counts(count):
handle_one_client()

When using Max as the value assigned to count, our testing server
becomes a production server with minimal effort.

As another example, in Dijkstra's shortest path algorithm on a graph
with weighted edges (all positive).

Set distances to every node in the graph to infinity.

Set the distance to the start node to zero.

Set visited to be an empty mapping.

While shortest distance of a node that has not been visited is less
than infinity and the destination has not been visited.

Get the node with the shortest distance.

Visit the node.

Update neighbor distances and parent pointers if necessary for
neighbors that have not been visited.

If the destination has been visited, step back through parent
pointers to find the reverse of the path to be taken.

Below is an example of Dijkstra's shortest path algorithm on a graph
with weighted edges using a table (a faster version that uses a heap
is available, but this version is offered due to its similarity to the
description above, the heap version is available via older versions of
this document).

Readers should note that replacing Max in the above code with an
arbitrarily large number does not guarantee that the shortest path
distance to a node will never exceed that number. Well, with one
caveat: one could certainly sum up the weights of every edge in the
graph, and set the 'arbitrarily large number' to that total. However,
doing so does not make the algorithm any easier to understand and has
potential problems with numeric overflows.

Gustavo Niemeyer [9] points out that using a more Pythonic data
structure than tuples, to store information about node distances,
increases readability. Two equivalent node structures (one using
None, the other using Max) and their use in a suitably
modified Dijkstra's shortest path algorithm is given below.

In the above, passing in either NoneNode or MaxNode would be
sufficient to use either None or Max for the node distance
'infinity'. Note the additional special case required for None
being used as a sentinel in NoneNode in the __cmp__ method.

This example highlights the special case handling where None is
used as a sentinel value for maximum values "in the wild", even though
None itself compares smaller than any other object in the standard
distribution.

As an aside, it is not clear to the author that using Nodes as a
replacement for tuples has increased readability significantly, if at
all.

An example of usage for Min is an algorithm that solves the
following problem [6]:

Suppose you are given a directed graph, representing a
communication network. The vertices are the nodes in the network,
and each edge is a communication channel. Each edge (u, v) has
an associated value r(u, v), with 0 <= r(u, v) <= 1, which
represents the reliability of the channel from u to v
(i.e., the probability that the channel from u to v will
not fail). Assume that the reliability probabilities of the
channels are independent. (This implies that the reliability of
any path is the product of the reliability of the edges along the
path.) Now suppose you are given two nodes in the graph, A
and B.

Such an algorithm is a 7 line modification to the DijkstraSP_table
algorithm given above (modified lines prefixed with *):

Note that there is a way of translating the graph to so that it can be
passed unchanged into the original DijkstraSP_table algorithm.
There also exists a handful of easy methods for constructing Node
objects that would work with DijkstraSP_table_node. Such
translations are left as an exercise to the reader.

...The issue is that a range can be open on one side and does not
always have an initialized case.

The solutions I have seen are to either overload None as the
extremum or use an arbitrary large magnitude number. Overloading
None means that the built-ins can't really be used without special
case checks to work around the undefined (or "wrongly defined")
ordering of None. These checks tend to swamp the nice performance
of built-ins like max() and min().

Choosing a large magnitude number throws away the ability of
Python to cope with arbitrarily large integers and introduces a
potential source of overrun/underrun bugs.

Further use examples of both Max and Min are available in the
realm of graph algorithms, range searching algorithms, computational
geometry algorithms, and others.

Independent implementations of the Min/Max concept by users
desiring such functionality are not likely to be compatible, and
certainly will produce inconsistent orderings. The following examples
seek to show how inconsistent they can be.

Let us pretend we have created proper separate implementations of
MyMax, MyMin, YourMax and YourMin with the same code as given in
the sample implementation (with some minor renaming):

Furthermore, the findmin_Max code and both versions of Dijkstra
could result in incorrect output by passing in secondary versions of
Max.

It has been pointed out [9] that the reference implementation given
below would be incompatible with independent implementations of
Max/Min. The point of this PEP is for the introduction of
"The One True Implementation" of "The One True Maximum" and "The One
True Minimum". User-based implementations of Max and Min
objects would thusly be discouraged, and use of "The One True
Implementation" would obviously be encouraged. Ambiguous behavior
resulting from mixing users' implementations of Max and Min
with "The One True Implementation" should be easy to discover through
variable and/or source code introspection.

As the PEP was rejected, all open issues are now closed and
inconsequential. The module will use the names UniversalMaximum
and UniversalMinimum due to the fact that it would be very
difficult to mistake what each does. For those who require a shorter
name, renaming the singletons during import is suggested:

from extremes import UniversalMaximum as uMax,
UniversalMinimum as uMin