[Python-Dev] Proposal: defaultdict

[Ian Bicking]

Guido van Rossum wrote:
> On 2/17/06, Adam Olsen <rhamph at gmail.com> wrote:
> 
>>It's also makes it harder to read code.  You may expect d[key] to
>>raise an exception, but it won't because of a single line up several
>>pages (or in another file entierly!)
> 
> 
> Such are the joys of writing polymorphic code. I don't really see how
> you can avoid this kind of confusion -- I could have given you some
> other mapping object that does weird stuff.

The way you avoid confusion is by not working with code or programmers 
who write bad code.  Python and polymorphic code in general pushes the 
responsibility for many errors from the language structure onto the 
programmer -- it is the programmers' responsibility to write good code. 
  Python has never kept people from writing obcenely horrible code.  We 
ought to have an obfuscated Python contest just to prove that point -- 
it is through practice and convention that readable Python code happens, 
not through the restrictions of the language.  (Honestly, I think such a 
contest would be a good idea.)

I know *I* at least don't like code that mixes up access and 
modification.  Maybe not everyone does (or maybe not everyone thinks of 
getitem as "access", but that's unlikely).  I will assert that it is 
Pythonic to keep access and modification separate, which is why methods 
and attributes are different things, and why assignment is not an 
expression, and why functions with side effects typically return None, 
or have names that are very explicit about the side effect, with names 
containing command verbs like "update" or "set".  All of these 
distinguish access from modification.

Note that all of what I'm saying *only* applies to the overriding of 
__getitem__, not the addition of any new method.  I think multidict is 
better for the places it applies, but I see no problem at all with a new 
method on dictionaries that calls on_missing.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org