{"id":102,"date":"2009-06-12T09:27:00","date_gmt":"2009-06-12T09:27:00","guid":{"rendered":"https:\/\/knielsen-hq.org\/w\/?p=102"},"modified":"2021-09-01T11:29:00","modified_gmt":"2021-09-01T11:29:00","slug":"learning-python","status":"publish","type":"post","link":"https:\/\/knielsen-hq.org\/w\/learning-python\/","title":{"rendered":"Learning Python"},"content":{"rendered":"\n

Among other things, these past few months I have been working on setting up Buildbot<\/a>, including adding various enhancements and bug fixes<\/a> that are needed to properly build and test the MariaDB and MySQL code base.<\/p>\n\n\n\n

Since Buildbot is written in Python, this means I have also had to learn Python. I am an old-time Perl hacker, so this exercise feels a bit like living in enemy territory \ud83d\ude09<\/p>\n\n\n\n

Anyway, Python is often touted as a more “pretty” language. And in many ways it is. Still, it is not without its own gotchas. Think “scope rules”. Obviously someone haven’t been reading up on the subject before implementing things in Python, causing the language to behave stupidly (and certainly different from what one expects) in the following three cases that I hit during my Buildbot work.<\/p>\n\n\n\n

First assignment is implicit scope declaration<\/h2>\n\n\n\n
    def foo():\n        s = 0\n        def inc():\n            s = s + 1\n        print s\n        inc()\n        print s\n<\/pre>\n\n\n\n
This results in this error:<\/p>\n\n\n\n
UnboundLocalError: local variable 's' referenced before assignment\n<\/pre>\n\n\n\n
Why? Because assigning to `s’ declares a new<\/em> variable. Yep, that’s right, a nested scope can read the value of a variable in an outer scope, but it cannot assign it!<\/p>\n\n\n\n
This is the work-around:<\/p>\n\n\n\n
    def foo():\n        s = { 'blarg': 0 }\n        def inc():\n            s['blarg'] = s['blarg'] + 1\n        print s['blarg']\n        inc()\n        print s['blarg']\n<\/pre>\n\n\n\n
Now the inner scope in inc()<\/code> does not assign<\/em> to the outer variable `s’. It merely reads the value, and updates the dictionary it contains. So now things work. Hm …<\/p>\n\n\n\n
Class vs. instance members<\/h2>\n\n\n\n
    class Bar:\n        s = 0\n        def foo(self, x):\n            self.s += x\n            print self.s\n\n    a = Bar()\n    a.foo(5)\n    b = Bar()\n    b.foo(8)\n<\/pre>\n\n\n\n
So this example actually works as one would expect from first glance (it prints “5” then “8”). But then when I looked closer, I did not understand how it could work. That s = 0<\/code> creates a class<\/em> member, shared by all instances of the class. So how can each instance still get their own private copy, each correctly initialised to 0?<\/p>\n\n\n\n
Ah, the answer is another variant of assignment creating a new scope. Look at self.s += x<\/code>. This statement first reads s.self<\/code>, which provides the value of the class<\/em> member. It then assigns the new value to s.self<\/code>, but since this is assignment, it now refers to an instance<\/em> member, so it creates a new instance member! I don’t know what those Python guys where thinking when they made self.s<\/code> refer to two different variables in a single statement …<\/p>\n\n\n\n
So this means that while the above example works as expected, this very similar one does not:<\/p>\n\n\n\n
    class Bar:\n        s = []\n        def foo(self, x):\n            self.s.append(x)\n            print self.s\n\n    a = Bar()\n    a.foo(5)\n    b = Bar()\n    b.foo(8)\n<\/pre>\n\n\n\n
The last statement prints [5,8]<\/code> as self.s<\/code> is now a class member shared among all instances.<\/p>\n\n\n\n
The work-around here is to initialise member variables in the constructor __init__()<\/code>, not in the class declaration.<\/p>\n\n\n\n
    class Bar:\n        def __init__(self):\n            self.s = []\n        def foo(self, x):\n            self.s.append(x)\n            print self.s\n\n    a = Bar()\n    a.foo(5)\n    b = Bar()\n    b.foo(8)\n<\/pre>\n\n\n\n
Late-binding closure construction<\/h2>\n\n\n\n
    b = []\n    for i in range(10):\n        b.append(lambda x: i)\n\n    b[0](42)\n    b[3](42)\n<\/pre>\n\n\n\n
This outputs the same<\/em> value “9” twice. All of the functions in the list return 9! Oops.<\/p>\n\n\n\n
The reason is apparently that the closure created by (lambda ...)<\/code> does late binding of captured outer variables, meaning that it refers to the name, not to the value at the time of closure construction. This is unlike any other language I have ever seen that has lexical scoping, so quite confusing.<\/p>\n\n\n\n
I know of two work-arounds in this case, neither of them pretty.<\/p>\n\n\n\n
One is to use a dummy extra parameter with a default value:<\/p>\n\n\n\n
    b = []\n    for i in range(10):\n        b.append(lambda x, dummy=i: dummy)\n\n    b[0](42)\n    b[3](42)\n<\/pre>\n\n\n\n
See, when the variable i<\/code> appears in the default value of a parameter, it is bound early (so to the value of i<\/code> is used, not the name), different from when the variable appears in the body of the lambda expression.<\/p>\n\n\n\n
The other work-around is to build and call an extra closure to force binding to the correct value:<\/p>\n\n\n\n
    b = []\n    for i in range(10):\n        b.append( (lambda j: (lambda x: j)) (i) )\n\n    b[0](42)\n    b[3](42)\n<\/pre>\n\n\n\n
This time, passing the value of i<\/code> to the outer lambda forces early binding, so we get the expected results.<\/p>\n\n\n\n
Something to be aware of for an old-time Perl hacker like me, used to using functional style when programming…<\/p>\n","protected":false},"excerpt":{"rendered":"
Among other things, these past few months I have been working on setting up Buildbot, including adding various enhancements and bug fixes that are needed to properly build and test the MariaDB and MySQL code base. Since Buildbot is written in Python, this means I have also had to learn Python. I am an old-time… Continue reading Learning Python<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[35,4,6,34],"_links":{"self":[{"href":"https:\/\/knielsen-hq.org\/w\/wp-json\/wp\/v2\/posts\/102"}],"collection":[{"href":"https:\/\/knielsen-hq.org\/w\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/knielsen-hq.org\/w\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/knielsen-hq.org\/w\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/knielsen-hq.org\/w\/wp-json\/wp\/v2\/comments?post=102"}],"version-history":[{"count":1,"href":"https:\/\/knielsen-hq.org\/w\/wp-json\/wp\/v2\/posts\/102\/revisions"}],"predecessor-version":[{"id":103,"href":"https:\/\/knielsen-hq.org\/w\/wp-json\/wp\/v2\/posts\/102\/revisions\/103"}],"wp:attachment":[{"href":"https:\/\/knielsen-hq.org\/w\/wp-json\/wp\/v2\/media?parent=102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/knielsen-hq.org\/w\/wp-json\/wp\/v2\/categories?post=102"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/knielsen-hq.org\/w\/wp-json\/wp\/v2\/tags?post=102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}