j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On Tue, Jun 25, 2019 at 03:34:03PM -0700, Ben Rudiak-Gould wrote:
On Tue, Jun 25, 2019 at 2:11 PM nate lust email@example.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.
But you never really could, not unless they were local variables. If they were variables in another namespace, whether a class or a module, and you accessed them with a dot, then in theory you couldn't tell what assignment would do.
In practice, we all know what assignment will do, dot or no dot, nearly always, and when we don't, the code does the right thing. On this list we often worry about code that does weird things that we don't expect, but how often is that a problem in practice?
You are right that if this proposal is successful, this will be one more thing that we have to take on faith that code could mess with but probably won't. But the reality is, so is nearly everything else except for literals like 1234 or None: functions, operators, method calls, imports, the list of things that might not do what we expect is very close to "everything in Python".
In any case, I don't see this being used often outside of very narrow use-cases. I'm more concerned about every single assignment getting a performance hit. The compiler in C++ knows in advance which variables have this special method and which doesn't, and can do the right thing at compile time. The Python compiler can't: every single binding and unbinding needs to jump through hoops to check for this special method whether it is used or not.
If Nate has a working prototype, I'd like to know how big a performance cost it carries.