[Python-Dev] PEP 326 now online (original) (raw)

Josiah Carlson jcarlson at uci.edu
Sun Jan 4 19:28:36 EST 2004

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

More information about the Python-Dev mailing list