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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/R7B3V6S6L6H4VXHKHF5ZGMZ2C7UBVQAP/
Code of Conduct: http://python.org/psf/codeofconduct/
