mirror of
https://gitflic.ru/project/openide/openide.git
synced 2025-12-15 02:59:33 +07:00
3079150697
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
1 line
622 B
HTML
1 line
622 B
HTML
<html><body><div class="bottom"><icon src="AllIcons.Nodes.Package"/> <code><a href="psi_element://#module#OneDecoratorFunction">OneDecoratorFunction</a></code></div><div class="definition"><pre><span style="color:#808000;">@decorator</span><br/><span style="color:#000080;font-weight:bold;">def </span><span style="color:#000000;">foo</span><span style="">(</span><span style="color:#000000;">param</span><span style="">: </span><span style="color:#000000;">Any</span><span style="">)</span> -> <span style="color:#000000;"><span style="color:#000080;font-weight:bold;">None</span></span></pre></div></body></html> |