[StreamBright]

Except that 90% of Python programmers fail to answer simple questions like:

Given:

    def extendList(val, list=[]):
        list.append(val)
        return list

What do the following print:

print(extendList(1))

print(extendList(1))

print(extendList(2))

print(extendList(3,[]))

I do not blame them. This sort of behavior is error-prone. You can make sure that you do not use such a code in production with code reviews but it would be also great to not having such things in the language.

[dec0dedab0de]

Maybe 90% of Python programmers fail to answer that question until they actually try to do it. Then they never forget.

[czzr]

For what it’s worth, I’m not a Python programmer and I got that correct.

The answer is:

[1]

[1, 1]

[1, 1, 2]

[3]

It relies on knowing something about how python applies default arguments.

I’ve only written about a hundred lines of python in my life, so possibly I just got lucky - still, I would have thought an actual Python programmer should get this?

[goatlover]

It is different from how Ruby and Javascript handle default arguments. I'm surprised Python does that, since I would expect function arguments to be reset to their defaults each call. That's a major side effect.

[kazinator]

It's also different from how Common Lisp handles default arguments, and ... how C++ handles default arguments.

This prints

  0
  1

  #include <iostream>

  using std::cout;
  using std::endl'

  int z;

  int foo(int x = z)
  {
    return x;
  }

  int main(void)
  {
    cout << foo() << endl;
    z++;
    cout << foo() << endl;
    return 0;
  }

[kadoban]

It's pretty odd behavior, yeah. It's easy to work around (set the default to None and then set the actual default in the function body), but I don't know if I've _ever_ seen anyone want it to behave as it does now.

[nitroll]

It does make sense to evaluate the default value for the parameter at the point of definition for serveral reasons. First of all, the default value does not have to be a literal value, and if you wanted it to be evaluated at call time the function would need to capture all of the default values in a closure.

  default = 10
  def foo(x=default):
      return x
  default = 20
  assert foo() == 10

I think tat makes a lot of sense.

It could also be that the default value is a more ocmplex expression, we could use a function to generate a default argument.

  def foo(x=create_default(y, z))

By evaluating it at definition time we only have to evaluate the expression once and not have this weird lazy expression.

And yes it is used, for example the fastapi Dependency Injection system has been build quite cleverly using the ability to construct default values

https://fastapi.tiangolo.com/tutorial/query-params-str-valid...

Yes it is one of those things you just have to learn, but there are tons of stuff like that in most programming languages.

[kazinator]

Under the sane semantics implemented in every major language other than Python, if you want to capture a snapshot of something at definition time, you can put it into a variable:

  wildly_changing_variable = random_initializer();

  stable_snapshot = wildly_changing_variable

  def foo(arg = stable_snapshot):
    ...

Don't touch stable_snapshot and everything is cool. This is the rare case. Of course

  def foo(arg = wildly_changing_variable)

means we want the current value.

I don't understand your "closure" comments; either way, things are being lexically closed. It's a question of when evaluation takes place, not in what scope or under what scoping discipline.

In fact, Python's treatment requires the implementation to have a hidden storage that is closed over; the equivalent of my stable_snapshot variable has to be maintained by the implementation. The definition-time evaluation has to stash the value somewhere, so to that it can use that one and not the current.

[kadoban]

You could easily generate that behavior manually though if the default were the other way, and it would target the common case instead of the rare case.

[kazinator]

> the default value does not have to be a literal value

The default isn't a literal value when it is [], by the way.

If [] were a literal, then this would not be safe or correct:

   def fun():
     local = []
     local.append(3)

The fact is that whenever [] is evaluated, it produces a fresh list each time. It's a constructor for an empty list, exactly like set() for an empty set. It just has slicker syntactic sugar.

Python just calls that a literal because it looks like one.

Looking is being, in Python. Except for all the pitfalls.

[pstuart]

TIL: https://docs.python-guide.org/writing/gotchas/

[StreamBright]

Yes, it is called insanity, doing the same thing, and expecting a different outcome. This is exactly what that function does.

[Cogito]

are those statements executed one after the other? In any case, it's definitely a pitfall, one that has been fairly widely publicised, even with checks embedded into various tools/IDEs.

[wolfgke]

Why didn't the Python developers use the possibility of introducing backward-breaking changes in Python 3 to fix such a pitfall?!

[theamk]

If this is a problem for you, I recommend pylint. No need to rely on code reviews, and catches majority of cases like this.

(You’ll likely want to disable some of the more opinionated checks, but this is well documented and supported)

[StreamBright]

Not a problem for me, just for the 90% of candidates who we interview.