[Python-Dev] PEP 326 now online

[Josiah Carlson]

> > 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.

What does the name 'None' suggest about what it does?  Just as
documentation and fooling around has helped current Python users
understand how 'None' works, they can do the same for "All", albeit with
a PEP that further describes how it works.

Whether or not users realize that None is smaller than anything else is
neither here nor there, they've not done the experimentation to
understand the extended features of the None object.  A similar thing
can be said about the void pointer in C/C++ and new/intermediate users
of those languages.  Heck, the "All" PEP could be used to educate new
Python users as to a useful feature of the None object that they will be
using during their Python experience.

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

'No' is an answer to a question, not a logical idea.  "Is this answer
correct?" -> [Yes, No]  "This answer is correct." -> [True, False]

As of right now, [All, Some, No] produce NameErrors.  Checking the
standard 2.3.2 distribution, seemingly the only examples of any of the
three are in comments, documetation, or strings.

As for naming conflicts, I would like to see code that already has
examples of All being used.

> 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.

Agreed.

> 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.

That seems to be a fairly arbitrary request, as most users don't realize
that None is smaller than any other object - I'm sure that quite a few
readers of python-dev were surprised to discover this.

In my own code, I have produced schedulers in which times of None meant
now.  Seemingly 0 would make as much sense, but there are situations in
which the current time advances from a starting time of 0, some setup
rutines get negative times, etc, resulting in 0 not being early enough.

I'm not sure I really want to go snooping around in the hundreds of
thousands of lines of code that is out there.  Pity that google doesn't
have a regular expression search.


> 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).

float.infinity makes no sense conceptually.  In terms of being of type
float, and being infinity, there already exists an IEEE 754
representation of floating point infinity, which is no larger than 1e309. 
10**309 is not the largest value that can be represented by Python. 
Pretending that it is, is not only misleading, it is incorrect.


> 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)

Min and max are only useful when you have the entire sequence right now
and you only need to find the min or max once.  In various optimization
problems, finding a minimum (or maximum) is done often, and a heap or
heap-like structure is used.

For example, in Dijkstra's shortest path problem on weighted edges, one
starts out by setting the distances of everything in the graph to
infinity, setting the starting point distance to zero, then
systematically pulling out the node with smallest distance, adding its
neighbors, etc.  Min and max are arbitrarily limiting, which is why they
aren't used.


> All of the examples in the PEP are subsumed by Alex's proposal.

Certainly, but I don't offer every use of All in the PEP - doing so
would take quite a while.


> 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.

I don't know, I think that None would be suitable for such cases of
'missing data value'.  It fits in terms of concept, but I may have
missed significant amounts of discussion on the topic as to whether None
makes sense in this case.  Heck, as an alternative, a keyword argument
would make sense in a function:

def getresults(db, query, exceptonnull=0): #partial function prototype


Thank you for your input,
 - Josiah