Steven, 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; https://github.com/natelust/cpython/tree/cloakingVars. 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 email@example.com 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 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.
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 -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://email@example.com/message/WAUOSP... Code of Conduct: http://python.org/psf/codeofconduct/
-- Nate Lust, PhD. Astrophysics Dept. Princeton University