You may have seen the message I posted a little while ago detailing a bit more about the proposed changes with an example of how the interpreter will handle things like __getself__. I have working code here; I worked very hard to keep all the new behavior behind c if statements of the form if (x != NULL) so that the impact on existing code would be minimized. If you have a bench mark you prefer I would be happy to run it against my changes and mainline python 3.7 to see how they compare.

On Thu, Jun 27, 2019 at 4:03 AM Steven D'Aprano <> wrote:
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 <> 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.

Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct:

Nate Lust, PhD.
Astrophysics Dept.
Princeton University