On Tue, Jun 25, 2019 at 2:11 PM nate lust firstname.lastname@example.org 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.