Andrew Barnert wrote:
More in detail on this link https://dev.to/circleoncircles/python-ideas-link-bidirectional-aliasing-in-p... 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
On Sep 22, 2019, at 02:08, Nutchanon Ninyawee me@nutchanon.org wrote: 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.
Since Python is an interpreted, dynamic language. In general, the type of variables tends to change throughout its lifetime especially in Jupyter notebook workflow. There will always be uncertainty about types, instance ids underlying each variable. Using `><`, will make a set of names refer to an object/value regardless of its immutable or mutable. Fair enough for the point that `df >< df_train` is the same as `df = df_train`. and the following preferable of `=` over `><` in most of the time. I agreed that `><` and `=` have the same effects most of the time. But the true value of `><` is laying in reassigning or re-binding which is not the case for `=`. Monkey patch may only benefit from a use case if you have like 3 or more name to patch and that not happen often. Personally, my code has a considerable amount of links. I would be much easier to maintain if there is such a thing like 'link'. This might be a paved way to multilingual coding. It will be a solid feature at least for me.