On Sep 22, 2019, at 02:08, Nutchanon Ninyawee <m...@nutchanon.org> wrote: > > More in detail on this link > https://dev.to/circleoncircles/python-ideas-link-bidirectional-aliasing-in-python-3f20
After reading the whole thing… In “explicitly not-copy assignment”: assignment in Python never copies. Doing `df = data_train` already ensures that it’s the same DataFrame, as you can see if you check them with `is`. In fact, that’s true with most of your examples. Just using `=` already does what you want, because the only difference is what happens if you assign to one of the names again with `=`. None of your examples do so, and in most cases it seems very unlikely that you’d ever want to do so. In fact, the one example where I could imagine wanting to re-assign is this `df` example, where (especially in the REPL or a Jupyter notebook) I might well want to reassign `df` to a _different_ DataFrame, and I certainly would want that to change the binding of `df_train`. So, the one case where `=` and `><` would have different effects, I think `=` is the one you’d always actually want. In “simplify aliasing”, `uninstall = remove` already has the same effect as your `uninstall >< remove`, and in fact it’s a common idiom used all over the standard library. Sure, it means that if you shadow the class’s `uninstall` attribute with an instance attribute it’s no longer the same thing as `remove`, but that’s (presumably) still true in your link case, so neither one is really like `self.uninstall = self.remove`. I don’t think anyone does the `self.uninstall = self.remove` version often anyway, but if that is what you wanted to make easier, you haven’t achieved that. In the same section: how often do people use @property to create a getter and setter that just provides another name for something they’re already exposing publicly? Sure, you _can_ do that, but I don’t think I’ve ever seen anyone do it, or even ask how to do it, so why do we need to make it easier? In “change unintuitive naming”, again, you can already do the same thing with assignment. Whether you want to monkey patch the class or the instance, = will have the same effect as ><, unless some other code tries to monkey patch the same name later—which (a) seems very unlikely, and (b) I’m not sure you’d want it to patch both names anyway. In “allow unnested naming”: it seems like that makes it even harder to implement your feature in a reasonable way. Finally, in the “bad” section: there is a feature a lot like this in most languages where variables are lvalues instead of names. For example, in C++, you can write `auto & a = b`, and then any assignment to either variable changes the other. But that goes along with on a whole lot of things about the language being different. In C++, you can have references as function parameters; `=` is a normal operator that you can overload; storage and identity and type belong to variables rather than values; you can cast values between types through pointers; etc. _______________________________________________ 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/JTFDVJQRPEDA2RUESEXJCLKITQNCSMIU/ Code of Conduct: http://python.org/psf/codeofconduct/
