Andrew Barnert wrote: > 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-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 > 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. _______________________________________________ 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/4CM6CKEMRL4D5GC6WQZ64ZSSGYNOIT4D/ Code of Conduct: http://python.org/psf/codeofconduct/
