Open danieleades opened 7 months ago
ultimately i found a way around by avoiding decorators entirely, but it would be nice if there was some further consideration given to the interaction between plumbum.cli
, decorators, and from __future__ import annotations
.
the copier project is using a decorator to wrap error handling around some
plumbum
methods, like so-see https://github.com/copier-org/copier/blob/5e98d21f35767de527c64da371045f4f018fa619/copier/cli.py
this decorator is then applied to plumbum.cli subcommand methods.
This works fine- the
@decorator
decorator ensures the wrapped method's signature doesn't change, soplumbum.cli
's introspection still works. There are two downsides@decorator
is untyped@decorator
breaks if you addfrom __future__ import annotations
to the fileI tried a different approach using a native decorator:
but this fails, presumably because
plumbum.cli
is relying on some element of the method signature thatfunctools.wraps
fails to forward.I tried instead-
that works, unless you add
from __future__ import annotations
, because that import changes the behaviour ofinspect.signature
(see https://bugs.python.org/issue43355)i'm guessing that's the exact issue that was causing me problems at the beginning of this journey...
How should I proceed?