Python Anti-Pattern
valinsky.me
Python Anti-Pattern
1–10 of 27 posts
Re: Python Anti-Pattern
#2Yep, a renowned Python footgun. Although Lambda container reuse adds a modern twist to it.
Can I ask what editor you were using? Because decent ones should have warned you about mutable default args.
Re: Python Anti-Pattern
#3Yep, a renowned Python footgun. Although Lambda container reuse adds a modern twist to it. Can I ask what editor you were using? Because decent ones should have warned you about mutable default args.
Shout out to the amazing Pyright, the fast and feature-complete python LSP that you can use with any editor that supports the LSP protocol!
Re: Python Anti-Pattern
#4About half the bugs I fix is due to unexpected interactions with mutable state.
Now, I am usually the creator of the bugs, and it might be that I completely lacks any intellectual rigour with regards to mutable state, but it is re-assuring that I am bot the only one.
This specific behaviour of python has always struck me as completely idiotic.
Re: Python Anti-Pattern
#5A bit of a nit on the step-by-step rundown of what happens. At step 4 it says the Lambda “dies” but I think this is misleading. The response has completed, but the Lambda has not died. In fact the process is still running which is why the mutable state issue presents.
Even if the process died, the container stopped, and the Lambda went “cold”, I wouldn’t even call that “dead”. It’s just cold. Dead would mean totally failed or decommissioned, I think.
Re: Python Anti-Pattern
#6As a Rubyist who only uses Python casually, it's neat to learn this difference! You can write very similar code in Ruby but such default objects appear to be created fresh on initialization avoiding the problem.
Re: Python Anti-Pattern
#7Linters can help a ton with stuff like this, I think pylint warns against this footgun.
Also is there a reason for not using the shorter:
var = var or []
Instead of:
var = [] if var is None else var
Re: Python Anti-Pattern
#8Linters can help a ton with stuff like this, I think pylint warns against this footgun. Also is there a reason for not using the shorter: var = var or [] Instead of: var = [] if var is None else var
I think using `or` for default fallbacks is generally considered bad practice because it disallows all falsey values, like `0` and `{}`.
It doesn't matter in this particular case because the only falsey List is `[]` anyway, but it's a bad habit.
JavaScript added the `??` operator for this specific problem.
Re: Python Anti-Pattern
#9About half the bugs I fix is due to unexpected interactions with mutable state. Now, I am usually the creator of the bugs, and it might be that I completely lacks any intellectual rigour with regards to mutable state, but it is re-assuring that I am bot the only one. This specific behaviour of python has always struck me as completely idiotic.
> This specific behaviour of python has always struck me as completely idiotic
I'm curious, what would be your proposed solution? Make a special case exception for when the expression that constitutes a function default is evaluated? What would that exception look like?
Re: Python Anti-Pattern
#10A bit of a nit on the step-by-step rundown of what happens. At step 4 it says the Lambda “dies” but I think this is misleading. The response has completed, but the Lambda has not died. In fact the process is still running which is why the mutable state issue presents. Even if the process died, the container stopped, and the Lambda went “cold”, I wouldn’t even call that “dead”. It’s just cold. Dead would mean totally…
Agree. Updated that part. Thanks for pointing it out.