Skip to content

Fix decorated attribute methods regression in 9.4.0

Closes #519 (closed)

Original idea in !522 (merged) to support multiple attribute functions signatures in high-api servers turns to be not so good.

To support multiple signatures we checked how many arguments has function with getfullargspec, but we did not think about such use case as function with (*args, **kwargs) signatures. This is a typical signature after wrapping with functools decorator.

As the most robust solution, I propose to strictly fix attribute functions input arguments for high-api servers.

This will be:

For static attributes:

  1. for read function - always 1 argument with device instance ("self")
  2. for write function - always 2 arguments: device instance and value
  3. for is allowed function - always 2 arguments: device instance and request type

For dynamic attributes we basically revert !510 (merged), and stick dynamic attributes to low-level API. The only options left - read value can be returned instead of set_value()

  1. for read function: always 2 arguments (device instance and attribute)
  2. for write function - always 2 arguments (device instance and attribute), value has to be extracted with get_write_value()
  3. for is allowed function - always 2 arguments (device instance and request type)

And a small change improve consistency - added support of read_green_mode, write_green_mode, isallowed_green_mode keywords for dynamic attribute

Fixes for pipes as well. Pipes now behave the same as attributes, and async is_allowed methods are supported.

Also added test for decorated attributes.

Edited by Anton Joubert

Merge request reports