Decorator Unification Protocol¶
The most general decoration variant from Pyc. 6 allows for arbitrary dynamic decorations anywhere in the code. But neither are all of these options needed for every decoration, nor is it generally useful to perform decorations anywhere in the code. Mostly a static decoration like in Pyc. 4 is sufficient and also provides a better code quality, because by decorating directly on the original class or function its modification becomes more visible.
- Comment:
If dynamic decoration is needed, a compact variant as in Pyc. 3 is recommended to keep definition and decoration of an object as close together as possible.
With this in mind, a Decorator Unification Protocol is formulated to unify three requirements:
The first requirement simply states that the implementation must support the most general variant with all parameters, that is, calls of the form
|
just as in Pyc. 6, where the substitute is the
original function or class to be modified.
The second requirement refers to the implementation of the most general static decoration in pie notation as in Pyc. 4 which is implemented by the Python compiler as shown in Pyc. 5. For this to work together with the first requirement,
all extra parameters |
or can of course be omitted if they are not needed.
The third requirement considers the situation when no decorator parameters
at all are present. Then the question arises whether an empty pair of
brackets must be specified for the first call level in static decoration,
or whether it can simply be omitted. Semantically, the two decorations
@Decorator() def substitute (with empty brackets) and
@Decorator def substitute (without brackets) express
absolutely identical facts,
|
and so both decorations should be possible on the one hand and therefore lead to the same result on the other hand. It should be left to personal taste which of these two equivalent variants is chosen.
© Copyright 2020-, Martin Abel, eVation. All Rights Reserved. |
|||
