On Sat, 16 Oct 2021, Steven D'Aprano wrote:
The token should preferably be:
* self-explanatory, not line-noise;
* shorter rather than longer, otherwise it is easier to just
type the target name as a string: 'x' is easier to type than
NAME_OF_ASSIGNMENT_TARGET;
* backwards compatible, which means it can't be anything that
is already a legal name or expression;
* doesn't look like an error or typo.
A possible soft keyword: __lhs__ (short for 'left-hand side'):
REGION = os.getenv(__lhs__)
db_url = config[REGION][__lhs__]
It's not especially short, and it's not backward-compatible,
but at least there's a history of adding double-underscore things.
Perhaps, for backward compatibility, the feature could be disabled in any
scope (or file?) where __lhs__ is assigned, in which case it's treated like a
variable as usual. The magic version only applies when it's used in a
read-only fashion. It's kind of like a builtin variable, but its value
changes on every line (and it's valid only in an assignment line).
One thing I wonder: what happens if you write the following?
foo[1] = __lhs__ # or <<< or whatever
Maybe you get 'foo[1]', or maybe this is invalid syntax, in the same way that
the following is.
def foo[1]: pass
Classes, functions, decorators and imports already satisfy the "low
hanging fruit" for this functionality. My estimate is that well over 99%
of the use-cases for this fall into just four examples, which are
already satisfied by the interpreter:
[...]
# like func = decorator(func)
# similarly for classes
@decorator
def func(): ...
This did get me wondering about how you could simulate this feature with
decorators. Probably obvious, but here's the best version I came up with:
```
def env_var(x):
return os.getenv(x.__name__)
@env_var
def REGION(): pass
```
It's definitely ugly to avoid repetition... Using a class, I guess we could
at least get several such variables at once.
If we didn't already have interpreter support for these four cases, it
would definitely be worth coming up with a solution. But the use-cases
that remain are, I think, quite niche and uncommon.
To me (a mathematician), the existence of this magic in def, class, import,
etc. is a sign that this is indeed useful functionality. As a fan of
first-class language features, it definitely makes me wonder whether it could
be generalized.
But I'm not sure what the best mechanism is. (From the description in the
original post, I gather that variable assignment decorators didn't work out
well.) I wonder about some generalized mechanism for automatically setting
the __name__ of an assigned object (like def and class), but I'm not sure what
it would look like...
Erik
--
Erik Demaine | edema...@mit.edu | http://erikdemaine.org/
_______________________________________________
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/BHGDRTX3BBYB66NINSTOPROTCIRKZNRU/
Code of Conduct: http://python.org/psf/codeofconduct/
