Dmitri Gavrilov

My concern is how well access to the signature and docstring of the original plan will work. It will probably work fine, but it needs to be tested before this...

I tested how `inspect.signature()` with the class instance. It seems to work fine.

@cjtitus Thanks, you are right. It is unlikely that we may need to set attributes of wrapped functions or monitor dynamically changed attributes, so copy of the `__dict__` should be...

I think the name of the `Plan` class is good. The name `plan_decorator` follows naming convention.

We could name the class as `_Plan`. This should discourage using this class outside Bluesky package. It may be also useful to have `plan_wrapper` that creates `_Plan` class from a...

In bluesky project the difference between wrapper and decorator is that wrappers accepts generators and decorators accepts functions as the parameters: https://github.com/bluesky/bluesky/blob/0f19587dbaf3d70029c77f63a04d39f794ae1806/bluesky/utils/__init__.py#L1121-L1128 Sometimes wrappers are more convenient. We don't need...

The other way is to add attributes with unique names (e.g. `_plan_wrapper_` and `_plan_decorator_`) to `plan_wrapper` and `plan_decorator` classes and check for those attributes in `isplan()` and `isplanfunction()` instead of...

Are component display names expected to be generated automatically based on display names of parents? Or `display_name` attribute should be set explicitly, otherwise it defaults to `None`/`""`?

The idea of implementing RE-compatible interface existed from the very beginning, but no viable solutions were proposed, mostly because the objects, such as devices and plans, exist in the (remote)...

There is an existing PR with similar changes: https://github.com/bluesky/bluesky/pull/1600 This PR looks better organized and also covers stubs, so it may replace the existing PR.