Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> It's worth explaining why mutable defaults are bad

They can also be good. Here's an example from the Reddit discussion, showing how a mutable default can be used to very neatly and cleanly add memorization to a function:

   def fib(n, m={}):
      if n not in m:
         m[n] = 1 if n < 2 else fib(n-1) + fib(n-2)
      return m[n]


That's an unpythonic hack. It is possible to have an explicit static variable using function attributes; another way is to use a proper memoization decorator which factors this out.


Cleverness like this makes you feel warm and fuzzy inside right up to the point where someone decides to actually pass that second argument to your function.


Well in Python 3 you can warn them:

    def fib(n, m:"donotusethisparameter"={}):


Is that clean and neat, or weird and inscrutable? Will it be clear to /anyone/ reading that code what it's doing?


I'm a Python newbie, and that code was immediately clear and obvious to me when I read it.

I won't say it would be clear anyone that reads it, because we live in a world where people who claim to be programmers can't do fizz buzz.


I'm a Python veteran, and, if you do it like this, I'll shoot you.

Add a @memoize decorator and do it there, you need to always be as obvious as possible. Compare:

    @memoize
    def fibonacci(n): pass
    
    def fibonacci(n, memory=[]): pass
You don't even need documentation for the first example.


Starting from Python 3.2 there is a builtin decorator: http://docs.python.org/dev/library/functools.html#functools....


That's fantastic, thanks for the link.


I agree with your sceptisism. This is misusing a language feature, a better approach is using a decorator.


I blogged about this, and other uses for mutable default arguments (with tongue somewhat in cheek) a few weeks ago: http://inglesp.github.com/2012/03/24/mutable-default-argumen...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: