False positive for method named print

[chrisbouchard]

We have a class in our code that's something like:

class Client:
    def print(self, payload):
        ...

I would expect this code to not be flagged:

response = client.print(payload=blahblah)

However, flake8-debug incorrectly determines that this is a call to the builtin print function and flags it DB100.

---

Would it be safe to assume that print and breakpoint won't be called as methods, and to only accept calls on ast.Names for those?

[vyahello]

@chrisbouchard hey, I've intentionally left this flag for built-in names everywhere according to PEP-8 style (argument names of functions and methods should not shadow built-in functions). Basically, your code will work fine and won't really redefine built-ins within class namespace, but this may confuse other people reading code.

Also, there is separate conversation/explanation on stackoverflow, please check

If you disagree with the above, we can actually discuss itю

[chrisbouchard]

@vyahello Thanks for the reply!

I don't think I've heard of a convention against shadowing via method names, but I appreciate that it is technically a form of shadowing. And I appreciate that some people may want to lint against it. 👍

I refreshed myself on PEP-8, and I didn't see any discussion about shadowing in there. Were you thinking of a different PEP?

I also had a look at the StackOverflow question you linked, and I'm not convinced. I'm particularly unconvinced by the appeal to the Zen of Python:

To selectively quote from PEP20:

Beautiful is better than ugly.

I personally would find it more beautiful to say some_client.print(...) rather than some_client.make_print_request(...).

Simple is better than complex.

It feels simpler to me to use the domain language for a method name, rather than to invent new terminology.

Readability counts.

Again, it feels more readable to use the name that people expect.

If the implementation is hard to explain, it's a bad idea.

I'm not even sure what this one has to do with the argument. There's nothing being implemented here—we're just bike-shedding a name.

(In my experience, appeals to the Zen of Python almost always translate to, I think I'm right, but I can't back it up qualitatively. The Zen is intentionally vague, and should be used as inspiration, not post hoc justification.)

---

More importantly, though, it doesn't really feel like it's this linter's role to take a hard stance on shadowing. We already have linters like pep8, bugbear, and ruff to enforce code style. If the goal of this linter to prevent debugging code from leaking into production, it really only matters whether the code is actually calling print() (the built-in). If the code is calling a method that someone could possibly confuse for print(), but isn't actually calling print(), then we're not leaking debugging code into production.

I think the biggest argument for this linter to allow shadowing debug function names is that I don't always get to choose the names of the methods I call. If I import a class from a library, I can't change that they named one of the methods print—but I still need to call it.

I don't feel that requiring me to add # noqa noise in that case helps much. Opinions on shadowing aside, the # noqa clutter hampers readability—and there's always the possibility that an actual print() call will get added on that line in the future, but the desired linter error would be suppressed by the # noqa added for the not-error.