In many cases, this invocation of fun_call() would not match its definition signature and it would generate an exception. When that's the case it's not at all a Python gotcha because it halted and forced you to fix the error.

I like this string catenation behavior and I prefer it, even if it causes some confusion in (IMO rare) cases.

I mean, this one is solvable by not using magic constants. Pretty easy to avoid. Can also lint it.

Unless I'm using a string more than once or its meaning is unclear, I always use the literal. In most cases, I find it more legible than having to go look up a constant's definition.

Then yes, I rely on the linter and testing.

I don't get what you're saying. How is it possible to write code without string literals?

    subprocess.check_call([
      "/usr/bin/env",
      "echo"
      "hello world"
    ])

I think she meant to not pass the strings but assign them to constants and then pass those.

Yep! But, like I mentioned, linter can catch this too.

he probably meant not using string literals / ints outside of top-level declarations, so you would instead assign all these parameters to "constants" at top level and then use those constants in function calls, hence avoiding this error.

How often do people write production software that doesn't have string literals?