[Python-Dev] Making None a keyword
Fri, 26 Apr 2002 15:25:54 -0400
>> are the builtin singleton data constants, so I'm +1 on those.
> I'll go along with True and False, since I expect that these will be
> frequently used (though still not as frequently as None).
In a dynamic sense I bet they'll be used more often than None, in part
because I'll steer people toward it <wink>. For years I've been steering
people to manage their "dicts used as sets" via:
for element in some_candidate_producer:
dict_used_as_set[element] = 1
instead of using "None", for two reasons: first, I view the dict as mapping
elements to "true", as in "yes, I'm present". The introduction of bool
makes this very natural, as in
ispresent = dict_used_as_set.get(element, False)
The guts of loops like that have a high dynamic count. Second, using "1"
instead of "None" is significantly faster today, and that can be important
in short scripts doing data crunching (i.e., the dict setup can account for
the bulk of such a program's runtime, and the faster string-keyed dict guts
get, the more significant the fixed overhead of doing the "= None/1/True"
Objective statistics <wink>: A module I've been writing for my own fun is
up to 329 lines now. It contains "None" 8 times, and "True" and "False" 7
times each. The Nones are mostly used as argument defaults (so evaluated
once per program run), and in one-time-per-call "was an argument specified?"
tests at function starts. One None is used in an inner loop, in an assert
that a certain value is not None. The dynamic count of True and False
evaluations is going to swamp the dynamic count of None evaluations in this
> Ellipsis is very rarely used (only by numeric code implementing
> multi-dimensional arrays), NotImplemented is used somewhat more but
> still pretty esoteric. So I'm -1 on those.
Fine by me. So is this consensus? Start warning for non-rvalue uses of
and that's it for 2.3.