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. 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)` [...]
[*]: since this was not available, we eventually went with an external DSL in combination with the "info" argument to the Column declaration in SQLAlchemy, used to pass metadata useful for our framework. This worked, but the code could have been much more elegant with variable decorators (in other words, it was quite ugly in some places and harder than necessary to maintain).
The only think this proposal adds that isn't available right now with a regular function call is that it automagically inserts the assignment target name into the function call arguments. I'm honestly not seeing how you go from such a niche piece of functionality to your glowing review of how it would make all these things so much more elegant. Can you give concrete examples please? 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. -- Steve