On Tue, May 25, 2021 at 10:55:07AM +0200, Stéfane Fermigier wrote:
> I had a similar idea ~8 years ago while working on a RAD (rapid application
> development) framework [*] that had to manage business objects using a
> variety of frameworks: an ORM (SQLAlchemy), a full-text engine (Whoosh), as
> well as a specifically developed CRUD Web UI framework, permission system,
> audit system, etc.
>
> In this context, variable decorators, in addition to type annotations,
> could bring a whole new level of internal DSL expressivity, including for
> instance:
Could you explain exactly how this proposed feature would allow us to do
all the things you say it would allow us to do? It's not clear to me how
knowing the binding name on the left would allow us to "express data
access constraints" etc.
I was thinking at the framework level, e.g. the decorator would be use to register some metadata somewhere (either class-level or in a global registry, say), and the framework would be to check permission against the current user when accessing the object's field (e.g. at serialisation / deserialisation time, and/or when rendering templates).
For all the things I have suggested, what I have in mind is just:
1) Register some metadata at decorator execution time
2) The framework uses these metadata when it needs them
E.g. you say:
> - Annotations to express full-text search indexability (e.g. @indexed)
I don't even know how to begin interpreting how you get there from the
proposed syntax:
@function(args) name
# -> `name = function('name', args)`
For the use cases I have in mind, some kind of context information would need to be passed too, like:
class Customer:
@permissions({"read": USER, "write": MANAGER})
first_name: str
the function primary_key should be called with the class being constructed for it to make sense.
Here are some alternatives:
1) Set metadata directly on some magical attribute:
class Customer:
__permissions__ = {
'first_name': { READ: ..., WRITE: ... }
}
first_name: str
cons: risk of mispelling or forgetting some attributes; lack of locality; how do we deal with inheritance ?
1bis):
class Customer:
class Meta:
permissions__ = {
'first_name': { READ: ..., WRITE: ... }
}
first_name: str
This is similar to the previous one, so same issues.
class Customer:
dexterity.read_permission(
first_name='cmf.ReviewPortalContent'
)
dexterity.write_permission(
first_name='cmf.ReviewPortalContent'
)
first_name: str
con: easy to misspell the field name (hopefully the rest of the issues is taken care by the framework)
3) One possible idiom to use decorators as I think would be fit, without changing the language, but at the price of an extra line and some additional mental burden:
class Customer:
first_name: str
@acl({"read": USER, "write": MANAGER})
def meta_first_name(self): pass
I.e. use a method decorator on a dummy function named similarly to the variable (e.g. by prepending some magical prefix).
The obvious con is that we still haven't prevented the risk of typo in the function name.
[...] As I see it, objects should almost never know or care what names (note
plural) they are known by, or even if they are bound to any names at
all. There are a few exceptions, mostly classes and sympy symbols, but
I expect that this functionality should be rather niche.
For the kind of applications I have been doing over the last 20 years (enterprise content and information management applications), this is not niche, this is where 50% of the work goes (i.e. defining object models, permissions, workflows, forms, validation, etc.).
S.