Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Generating error if callable object is formatted as a string? #5213

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
JukkaL opened this issue Jun 13, 2018 · 6 comments
Open

Generating error if callable object is formatted as a string? #5213

JukkaL opened this issue Jun 13, 2018 · 6 comments

Comments

@JukkaL
Copy link
Collaborator

JukkaL commented Jun 13, 2018

Pretty frequently I have errors where I forget to call a method and accidentally pass a method object to % or str.format. Mypy doesn't complain since it's possible to convert a callable object to a string, though usually that's not what I want.

Example:

class Item:
    def name(self) -> str: ...

def f(x: Item) -> None:
    print('name: {}'.format(x.name))  # No error, though should be x.name() 
    print('name: %s' % x.name)  # Similar to above
    foo(str(x.name))  # Ditto

This occasionally happens during refactoring as well, when I replace an instance variable with a method.

Here are a few things we could do about this:

  1. Special case these errors and generate a warning even though the code is not necessarily wrong. Maybe require an explicit repr(x.some_method) to silence the error (# type: ignore or a cast to object would also work).
  2. Introduce a new strictness flag that causes these to be flagged. Not sure if this should be enabled by default.
  3. Introduce a new strictness flag that catches these and other cases where there is no runtime type error, but that we suspect might be errors. Passing a string argument when an iterable object is expected comes to mind as a kind of similar issue, and there are probably others.
  4. Do nothing, since there is no runtime type error and the code could well be valid.

Option 2 seems too specialized -- this doesn't seem important enough to add a strictness flag. Personally I prefer the more opinionated option 1. We could add a hint about how to silence the error in case the code happens to be correct.

@pslacerda
Copy link

I would prefeer option 4 because because seems more suited to a custom plugin for pylint.

@JukkaL
Copy link
Collaborator Author

JukkaL commented Jun 14, 2018

Pylint can't generate this error reliably since it doesn't do type inference.

If mypy had a public plugin API, we'd have another option:

  1. Implement this as a mypy plugin that users can optionally install. The plugin could have other optional "ad-hoc" checks as well.

Finally, if we'd have finer-grained control of which errors to generate (#3806), it would be easier to justify enabling additional checks by default, since there would be a simple way to disable them.

@ilevkivskyi
Copy link
Member

TBH, I have never had this problem. However, I several times had a similar, but harder to diagnose problem: if sym.node.fullname == 'something.Special': ... An experienced mypy developer will immediately see what is wrong, but I remember I had troubles with this mistake several times. So I would rather add a warning for this case.

@JukkaL
Copy link
Collaborator Author

JukkaL commented Jun 19, 2018

So I would rather add a warning for this case.

Funnily enough, I've never had this problem. There is an existing issue for this: #1749

@ilevkivskyi
Copy link
Member

Now that we have error codes, this can be a simple follow-up for #7418

@JukkaL
Copy link
Collaborator Author

JukkaL commented Sep 5, 2019

We still don't have a general way of enabling/disabling specific error codes. When that is supported, this could be just an optional check that can be enabled. --strict could also enable this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants