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 <st...@pearwood.info> 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 <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. > > 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. > > > > -- > Steven > _______________________________________________ > 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/WAUOSPEB2CDA2USO3ULJ6SPPFPDDU2L7/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Nate Lust, PhD. Astrophysics Dept. Princeton University
_______________________________________________ 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/TTN7BYFPUHB2SEP6F2PCXA6LVWTV4WDY/ Code of Conduct: http://python.org/psf/codeofconduct/
