6 Commits
Author SHA1 Message Date
Mikhail Golubev 3079150697 PY-60104 Don't try to infer side effects of not type hinted decorators
Assume that such decorators as well as "well-known" decorators, which we special-case,
don't change signatures of decorated functions and classes.

This change effectively stops the long-standing policy of safe-listing a few recognized
"well-known" decorators and assuming everything else can change a definition in any
way. This approach doesn't apply well to the current state of the Python world, where most
of the common side effects of decorators, such as adding new parameters, can be expressed
in type hints.

In 2021.1 we added PyDecoratedFunctionTypeProvider that was able to infer a return type of
decorator over its body, as for any other function, and then correctly apply this information
to a decorated definition. It led to a number of problems.

First of all, depending on whether TypeEvalContext allowed us to access AST of a decorator's
body, we inferred different signatures for functions decorated with an imported decorator in
inspections and in user-initiated actions, such as Parameter Info.

Secondly, we started inferring useless `(*args, **kwargs)` signatures in case of decorators
defined following the common pattern of returning a wrapper function accepting arbitrary
parameters and itself decorated with @functools.wraps (PY-48338). In some sense, our code
analysis was "too smart" in its type inference in this case.

Lastly, we diluted the return types of functions decorated with unknown decorators, even
fully typed, by uniting these types with Any (so-called "weak" types). This logic
existed before PyDecoratedFunctionTypeProvider, but it became more problematic now
than we were able to propagate this artificial union through generic decorators.

This change in behavior might lead to some false positives for untyped Python code
with non-pure decorators. However, given that other type checkers are also likely to hit these
problems, there is now a stronger incentive to add type hints for such problematic APIs.
In the worst case, we can special-case some heavily requested decorators as we did before.

GitOrigin-RevId: db11fb3573bda5da155cb921a30adc31d5c841e2
2024-01-09 20:49:13 +00:00
Semyon Proshev cff3f1f86d Enable pyi-stubs for os (PY-23258, PY-21395, PY-21394, PY-21397, PY-17420, PY-28984, PY-27584)
GitOrigin-RevId: 34ecf07bc68276e62315d01f3c3347f79026ec65
2019-11-20 11:37:02 +00:00
Semyon Proshev 9bab826071 PY-21040 Fixed: False positive: os.popen(...).close() doesn't return anything
Update os.popen skeleton to return class which has return value in close()
2016-11-15 15:54:43 +03:00
Andrey Vlasovskikh 8fed6c91ee Fixed function doesn't return anything inspection for decorated and overridden methods (PY-10883) 2013-09-25 17:29:14 +04:00
Ekaterina Tuzova d7281a83a9 implemented pylint W0601
Inspection is used when a variable is defined through the "global" statement but the variable is not defined in the module scope.
2013-03-22 15:44:16 +04:00
Ekaterina Tuzova d74c7f2ab1 implemented pylint E1111
Inspection is used when an assignment is done on a function call but the inferred function doesn't return anything.
2013-03-22 14:43:49 +04:00