Pythonic way for missing dict keys

[Steven D'Aprano]

On Sat, 28 Jul 2007 11:52:48 +0000, Alex Popescu wrote:

> jjl at pobox.com (John J. Lee) wrote in news:87lkd0eprj.fsf at pobox.com:
> 
>> Alex Popescu <nospam.themindstorm at gmail.com> writes:
>> 
>>> Zentrader <zentraders at gmail.com> wrote in
>>> news:1185041243.323915.161230 @x40g2000prg.googlegroups.com:
>>>
>>>> On Jul 21, 7:48 am, Duncan Booth <duncan.bo... at invalid.invalid>
>>>> wrote: 
>>>>
>>>> [snip...]
>>>>
>>>> 
>>>>>From the 2.6 PEP #361 (looks like dict.has_key is deprecated)
>>>> Python 3.0 compatability: ['compatibility'-->someone should use a
>>>> spell-checker for 'official' releases]
>>>>         - warnings were added for the following builtins which no
>>>> longer exist in 3.0:
>>>>              apply, callable, coerce, dict.has_key, execfile,
>>>>              reduce, 
>>>> reload
>>>> 
>>>
>>> I see... what that document doesn't describe is the alternatives to
>>> be used. And I see in that list a couple of functions that are
>>> probably used a lot nowadays (callable, reduce, etc.).
>> 
>> callable and reduce are rarely used, at least in code I've seen.  
> 
> I thought G would be using that function a lot. 

Who or what is G? Guido?

And which of the two functions mentioned is "that function"? callable()?


Instead of doing:


if callable(function): function()

you should do:

try:
    function()
except TypeError:
    pass


That should work for most uses of callable(), but isn't quite the same.
(What if function() has side-effects, or is expensive, and you want to
determine if it is callable, but not actually call it _now_?)


> Also, what is the replacement of reduce? I think I remember seeing
> somewhere that lists comprehension would be (but also remember the
> advise that reduce will be quicker).

No, a list comprehension isn't equivalent to reduce(). There is no
replacement for reduce().

Guido has essentially done the functional equivalent of deciding that
because he personally doesn't like for loops, they can and should be
written out as:

counter = 0
while counter < len(sequence):
    item = sequence[counter]
    do_something_with_item
    counter += 1

because it is "easier to read" than a for loop.

And yes, if you think my example is extreme because nobody would be that
stupid, that's the point: removing reduce() _is_ that stupid (and it is
not often I say that about a language design decision by Guido!). Python
can, and probably will, get away with it only because reducing an iterable
to a single value is an uncommon operation, and the most common uses of it
(summing a sequence, finding the minimum and maximum) already have
workable replacements.

It's especially stupid because map() and filter(), both of which do have
simple, easy to understand, completely functional replacements, are going
to stay. reduce() doesn't, and it is going. That's nuts.

It's a shame really. Oh well, maybe it will sneak back in via a functional
module, or itertools, or something. What a waste, what a waste.


>> Certainly has_key will be
>> the most common of those listed above (but trivial to fix).
> 
> dict.has_key(key) becomes key in dict (correct?)

Yes.



>> apply
>> will be common in old code from the time of Python 1.5.2.
> 
> I think there were some advises to not use apply.


help(apply) already tells you how to replace apply():

    Deprecated since release 2.3. Instead, use the extended call syntax:
    function(*args, **keywords).



>> execfile is
>> perhaps more common that callable (?) but again is really a "maybe 1
>> call in a big program" sort of thing.
> 
> What is the replacement for this one?


Slurp the file into a string, execute the string.


But the thing that makes my brain melt is reload(). No, reload() probably
isn't good enough to use in production code, but for interactive use it is
Good Enough. I'm boggled that it is going away!



-- 
Steven.