On Tue, Jun 25, 2019 at 2:11 PM nate lust <natel...@linux.com> wrote:
>if an instance is bound to a variable name, any attempts to rebind that name
>will result in a call to the __setself__ (name negotiable) of the instance
>already bound to that name.
I am very, very strongly opposed to this. It would mean that I
couldn't trust variables any more.
I want to be able to write
for x in items:
without worrying about whether one of the items might "stick" to x and
infect every subsequent iteration of the loop, and any later loop in
the same function that also uses x as a loop variable.
I want to be able to clarify code by assigning a subexpression to a
local variable with a descriptive name, without worrying about whether
that's going to change the meaning of the code.
I need local variables to be easy to reason about, because Python
requires you to use them so much. The thought of the additional
cognitive burden that the mere presence of this feature in the
language would create, in practically everything I write, scares me.
> On first read, that may be surprising, but it extends a behavior pattern that
> already exists for things like properties (and generically descriptors) to
> object instances themselves. Similar caveats and behaviors will apply here as
> well.
It seems very different to me. Magic attributes are declared in the
class. Assignments to that attribute of an instance then go through
the special code in the class. Your proposal doesn't have that split.
Your proposal would be as if assigning a special value to an ordinary
attribute permanently changed that attribute's behavior for that
instance only, in a way controlled by the value, not by the class or
even the instance.
I would be fine with a proposal to declare special variables whose
loading and storing behavior is controlled by Python code. If a
declaration like
metavariable foo = obj
in a scope caused the compiler to generate calls to obj.__get__,
obj.__set__ and obj.__delete__ instead of the usual LOAD_*, STORE_*,
DELETE_* instructions for all mentions of foo in that scope, I would
be fine with that. It would be more similar to descriptor attributes,
it would have no runtime overhead if not used, and most importantly, I
wouldn't have to learn about it if I didn't want to use it. Also you
probably wouldn't need to invent new special method names for it, the
existing ones would work.
> * Variables which keep track of their assignment history, with ability to
> rollback (possibly useful with try except blocks)
> * Variables which write out their value to disk when assigned to
> * An implementation of context variables using only this new framework (does
> not implement tokens, but could be added)
> * const variables that can be used to protect module level 'constants'
> * Instance properties (reproduced below) that allow dynamically adding
> properties
> * An implementation of templated expression, to defer the addition of many
> arrays to a single for loop, saving possibly expensive python iterations.
I don't understand all of these but the ones I do understand seem like
they only require some way to magic-ify the variable before using it.
The part of your proposal that I strongly oppose is overloading the
ordinary assignment syntax for this. Use a special declaration
analogous to global/nonlocal and I think it's fine.
-- Ben
_______________________________________________
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/MW2CFAQ6BKS7TIRHW6SJCUOR4Y2ECQNN/
Code of Conduct: http://python.org/psf/codeofconduct/
