Generating error if callable object is formatted as a string?

Aperta
#5,213 6 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
python
Ambito
devtools

Direzione di ricerca

Start by reviewing the three examples and the four proposed options in the issue. The issue names no files, tests, or entry points; completion would require choosing and specifying a behavior for callable objects passed to formatting or str(), including how valid cases are silenced.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

needs discussion

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.

Lingua principale
Python
Stelle
20.6k
Fork
3.3k
Merge medio
1g 18h
PR unite (30g)
54

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di python/mypy

Tutte le issue di python/mypy

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.