popkey() method for dictionaries?
Fernando Pérez
fperez528 at yahoo.com
Mon Nov 18 04:18:50 EST 2002
Raymond Hettinger wrote:
> Do you have use cases demonstrating the value of a default rather than an
> exception?
Sure. First, on principle: the exception option is still there, if no default
is provided. What giving a default buys you is not having to trap the
exception yourself. If you want a missing key to generate an exception,
simply don't give a default and that's it. Since it doesn't change the
existing semantics (the current form doesn't take any arguments, so there
can't be any confusion), I think it's a good addition.
But you asked for code. Here's an example from a wrapper which needs to filter
out a keyword dictionary given to a function before passing it downstream. It
needs to remove keywords which won't be understood by the downstream
function, but it knows how to make a default decision if the keyword wasn't
given:
# Filter out other options the original plot doesn't know
hardcopy = popkey(keyw,'hardcopy',psargs['filename'] is not None)
titles = popkey(keyw,'titles',0)
This uses my popkey() function, with the new method it would be simply
# Filter out other options the original plot doesn't know
hardcopy = keyw.pop('hardcopy',psargs['filename'] is not None)
titles = keyw.pop('titles',0)
if my suggestion were accepted. I can always live with my popkey() function
instead, if the crippled version is left in the language :) What I _won't_ do
is use the crippled pop() and wrap things everywhere with explicit try/except
blocks. In the end that only hurts readaility and creates bloat.
This is part of the Gnuplot wrappers in IPython, if you want to see the full
code (or I can give more context). IPython lives at
http://www-hep.colorado.edu/~fperez/ipython
> Also, discuss why similarity with dict.get() applies instead of symmetry
> with list.pop() or dict.popitem().
- list.pop: I wasn't looking when that was written :) But I could argue
similarly that an optional default argument would be a sensible, useful
addition. No semantic break for existing code, and it saves people setting up
try/except traps.
- dict.popitem: this one I'm ok with not having a default value, since it is
meant to traverse the dict in essentially random order. Adding a default
value would be like having a dict_with_default kind of object, which is
definitely different from a regular python dict. popitem() returns a k/v pair
and is typically used for exhausting a dict destructively, so it makes a lot
of sense to break at the end.
But pop(key) is much more specific, so I think it is sensible to be able to
control its behavior more closely. Just like dict.get(), which allows
straight through the function interface one to control what happens to
missing keys. Semantically pop(key) is almost like get(key), with the
difference that it deletes the k/v entry from the dict. It seems only natural
then that pop() would support the same default arg behavior that get() has.
Cheers,
f.
More information about the Python-list
mailing list