I Challenge You to Debug These 7 Lines of Code Under 9 Minutes (theodo.fr)

Experienced in Python? This will take you less than one minute.

     def foo(a, methods=[]): # methods defaults to [] if not specified
     ohno.

This is a common mistake in pretty much any language that captures a closure inside a lambda: C++, JS, etc. Unfortunately, debugging this the first time takes 20 minutes; the next time, it takes 0 seconds.

Is this a designed feature or something that just happened? I really think that this behaviour is erroneous and unexpected.

With python (and many other languages) I find myself getting bitten by behaviour like this every now and then. I use scheme for almost all my personal projects, and I can only remember getting bitten twice. Once was unexpected, and the other was laziness on my part.

    scala> var x = 5
    x: Int = 5

    scala> def func(arg1: Int = (x+1)) = { println(arg1)}
    func: (arg1: Int)Unit

    scala> func()
    6

    scala> var x = 7
    x: Int = 7

    scala> func()
    6 //unchanged

    scala> var list = List(1,2,3)
    list: List[Int] = List(1, 2, 3)

    scala> def printList(arg1: List[Int] = lis) = { println(arg1) }
    printList: (arg1: List[Int])Unit

    scala> printList()
    List(1, 2, 3)

    scala> var list = List(4,5,6)
    list: List[Int] = List(4, 5, 6)

    scala> printList()
    List(1, 2, 3)

It's a common JavaScript interview question to ask about capturing variables in a closure.

What really frustrates me with go is that it doesn't have a mature debugger so I have to resort to inserting print statements everywhere.

Took me less than 7 minutes with a single print statement. I'm a FE developer though, and python feels awfully similar to JavaScript.

"If I lied, you are allowed to insult me abundantly through your favorite channel."

Haha racket can here is how.

    #lang racket
    
    (define (foo a [methods empty])
      (let ([methods
             (append methods
                     (for/list ([i (range 3)])
                       (lambda (x) (+ x i))))])
        (for/sum ([m methods])
          (m a))))
    
    (foo 0)  ;; Should be 3
    (foo 1)  ;; Should be 6
    (foo 2)  ;; Should be 9
    (foo 2 (list (lambda (x) x)))  ;; Should be 11
    (foo 0)
    (foo 1)
    (foo 2)


    ;; Now the wrong way

    ;; The lambda capturing wrong
    (define (foo a [methods empty])
      (define i 0)
      (let ([methods
             (append methods
                     (for/list ([z (range 3)])
                       ;; modifying the variable i
                       (set! i z) 
                       (lambda (x) (+ x i))))])
        (for/sum ([m methods])
          (m a))))

    ;; this one doesn't do the default parameter wrong, because
    ;; methods and methods-default share an imutable list and we
    ;; modify only methods so beside "empty" they won't share the same
    ;; reference anymore, to get it wrong we should use a mutable list
    ;; (doesn't exist in racket).
    (define foo
      (let ([methods-default empty])
        (lambda (a [methods methods-default])
          ;; (printf "~a ~a\n" (length methods) (length methods-default))
          (define i 0)
          (for ([z (range 3)])
            (set! i z)
            (set! methods (cons (lambda (x) (+ x i))
                                        methods)))
          (for/sum ([m (append methods methods-default)])
          (m a)))))

    ;; So i use a box to make it mutable.
    (define foo
      (let ([methods-default (box empty)])
        (lambda (a [methods methods-default])
          ;; (printf "~a ~a\n" (length (unbox methods)) (length (unbox methods-default)))
          (define i 0)
          (for ([z (range 3)])
            (set! i z)
            ;; methods and methods-default share the same reference of box.
            (set-box! methods (cons (lambda (x) (+ x i))
                                    (unbox methods))))
          (for/sum ([m (unbox methods)])
            (m a)))))

The moral of the story, language design matter, immutable by default is good, lexical scoping is good, binding over variable is good, ruby, python, php and javascript (the languages the author mention) are bad in that regards.

One thing php, ruby, python (but not javascript) has good over racket their identatation tend to be flat and racket (let form, no return statement) tend to go all the way to the right.

Great intro to PDB, but I have to be critical of: "The second group took 9 minutes on average, and the first one 14 minutes! Those are not completely statistically significant, but that’s still a 35% speedup on an 8-line-long program."

If you want to talk about statistical significance, don't say "not completely". It either is or it isn't. If you think the p-value is important (and I'm not saying it is, but don't bother mentioning it if you don't think it is), then you can't claim a 35% speedup. If you're reporting results in the context of significance, and you decided that your results were not significant, then the 35% speedup is meaningless.

It took me a minute to see the problems, but - not having touched Python for over a decade - I can't for the life of me bring the lambda to capture the value of the variable.

I know this doesn't work (because python assignment rules)

    def foo(a, methods=[]): 
    m=[];
    for bla in methods:
        m.append(bla)

    for i in range(3): 
        k = i
        m.append(lambda x: x + k)

But this should work, according to quick'n'dirty google (because default assignment), and yet it doesn't.

    for i in range(3): 
        def bar(c, d=i): return c+d
        m.append(lambda x: bar(x))

EDIT: Ok, I'm something missing here.

This doesn't capture the value of i

    for i in range(3): 
        m.append(lambda x,i=i: x+i)

But this does. WTH?!

    for i in range(3): 
        m.append(lambda i=i: i)

    for i in range(3): 
        m.append(lambda x,i=i: x+i)

Worth bearing in mind that if you develop and ship software to third parties, you're going to want a lot of debug statements in the logs, so don't omit them completely!

The fact that "methods" is somehow kept defined in the scope of the function and preserved when you call it again and isn't always reinitialized to [] is just dumb. No wonder this was a bug, who the hell would see that and how is this "feature" ever useful except to create bugs?

It's mystifying to me that the author comes to the conclusion that the solution to this is to educate people on debugging tools and edge-case semantics. The reason the code is difficult to debug is because the "bug" is that functions are apparently completely broken and violate every reasonable assumption anybody is likely to make about them without a priori knowledge about this specific edge case. Why isn't the conclusion then, that Python is broken, and has a serious and fundamental problem? Why doesn't anybody see this as a "broken window", that leads us as a culture to believe that this sort of thing is acceptable and to be expected and not an ugly, horrible, and utterly unnecessary problem? Is this really the language we're supposed to teach to beginners? How many combined hours have been wasted on solving problems generated by this behavior, and for what purpose? I don't understand why people accept this.