[Python-Dev] PEP 326 now online

[Raymond Hettinger]

> I believe I've addressed the majority of concerns had for the All
> (previously Some) concept and object (the PEP editor seems to agree),
> and the PEP has been posted as PEP 326.

The name must be something else like Infinity or something more
suggestive of what it does.

All, Some, and No already have meanings in logic and would
guarantee naming conflicts with existing code.



The use cases are very thin but have a ring of truth -- I think many
people have encountered a situation where they needed an initial
value guaranteed to be larger than any element in a set.

It would also be helpful to see how well None has fared as a 
negative infinity object.  Your case would be much stronger
if it could be shown that None was widely used in that capacity
and that it had simplified the code where it was used.



The opposition to new builtins is fierce, so it would be wise to 
bolster the use cases with examples from real code which would be 
improved by having an Infinity constant.  A little user friendliness
testing on newbies couldn't hurt either (try the tutor list).  Also,
develop some strong arguments about why it wouldn't be preferable
to have this as a recipe or example; to tuck it into some other 
namespace; or to attach it to a type (like float.infinity, etc).



Under alternatives, be sure to list Alex Martelli's suggestion to
use the key= construct with min() and max().  This could potentially
trivialize all the issues with writing clean code for finding the
biggest and smallest things around:

min([1,2,3,4])                                         -->  1
min([(a,1), (b,2), (c,3), (d,4)], key=itemgetter(1))   --> (a,1)
max([1,2,3,4])                                         -->  4
max([(a,1), (b,2), (c,3), (d,4)], key=itemgetter(1))   --> (d,4)

All of the examples in the PEP are subsumed by Alex's proposal.
The only example I can think of that still warrants a constant
is for NULL objects stored in a database -- even that example
is weak because there are likely better ways to handle missing
data values.



Raymond Hettinger


#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################