Thread by @HeyChelseaTroy

Mm. Let's talk about this. I use this as one of my examples in my "WTF Python" introductory lecture...the first lecture I do in my Python Programming class.

I'll start with what's happening, move on to how to avoid it, then finish with when to use it.

1/

https://twitter.com/OliverCaldwell/status/1504472687426498562

First, a plug for another thread: if the idea of a "WTF Python Lecture" is intriguing to you, here's a thread where I talked about why I do that lecture!

So now, let's talk about what's happening in the above code snippet.

https://twitter.com/HeyChelseaTroy/status/1481098092137041924

Python evaluates default arguments when it places the DEFINITION of the function into the environment. Not when it RUNS that function. So the default arguments keep the id they had at function definition time.

No problem when your defaults are immutable. But a list is mutable.

That means, when you change the list set in this function as the DEFAULT argument, it's gonna keep using that changed list in future calls that don't set that argument.

If I understand correctly, this was an oversight in the original implementation, but it has been kept bc...

1. There's a way around it and python strives to have "one right way"
2. It's well known, so people were already using the aforementioned circumnavigation
3. ALSO people were using THE FACT THAT PYTHON DOES THIS, and as such
4. Changing it would break people's code.

Zooming out:

The Python maintainers have a very different risk calculation to make about changing behavior than, I dunno, you or I do on a pet project, because their project is in active use by 8.2 million people whose code they need to not break.

So what's this way around that I mentioned?

It's this:

def my_functino(default_list = None):
if default_list == None:
default_list = [ ]
...

This EXPLICITLY sets that default to a FRESH NEW list at function RUN time.

Another syntactic sugar you'll see on the above is "if not default_list." I don't use that for two reasons:

1. The above way is more explicit on what is happening because it doesn't bank on the reader having to remember that None is falsey.

So that's reason 1.

Reason 2: [ ] is also falsey.

So "if not default_list" will REASSIGN that name to a NEW empty list if someone passes in an empty list as the argument. Doesn't break things, but pointless.

BONUS REASON: "" and 0 are ALSO falsey so this behavior won't raise in some cases where someone is passing in the wrong kind of default.

I like my code to tell people when they're doing things wrong before they have to go investigate and then change half their program over it.

ANYWAY, we talked about why this happens and how to avoid it.

When do you use it?

Honestly I don't use this in prod code. I set an instance variable if I want an object to hang onto state.

I do use it occasionally in mocks. Here's how:

1. The object I am mocking mutates some state that I cannot access through an existing instance variable.
2. I don't want to add an instance var to an object JUST to test it, but I want to confirm something happened in this function...
3. Across multiple calls to the function.

Example:

class Logger(Loggable):
def log(msg):
#prod behavior

class MockLogger(Loggable):
def log(msg, messages=[]):
messages.append(msg)
return messages

Such that:

MockLogger.log("Hi!")
msgs = Mocklogger.log("Hello!")

>>>["Hi!", "Hello!"]

This can be useful later when I have a test like:

def test_dispatch_object__logs_to_snowplow():
dispatch.function_that_calls_log_twice()
assert dispatch.messages[0] == "First message I need sent"
assert dispatch.messages[1] == "Second message I need sent"

IN GENERAL, I'd say it's a little sneaky, and if we were all starting over with Python, maybe we'd make this not work this way.

But as it is, that's why it happens, how to get around it, and a use case.

I meant "is None" 😳

@threadreaderapp unroll so I can make some corrections and blogpostify