On Sep 22, 2019, at 18:15, Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Sep 23, 2019 at 10:42 AM Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
On Sep 22, 2019, at 02:08, Nutchanon Ninyawee <me@nutchanon.org> wrote:
Link is a language feature that allows multiple variable names to always refer to the same underlying object define in a namespace. For now, if the variable a link with b. I will denote as a >< b or link('a', 'b')
a = 2 a >< alpha # link 'a' with 'alpha' b = 3 print(b**alpha) # print 9 alpha = 3 print(b**a) # print 27
How would this work? I can think of a few options, but they all either badly slow down every variable use, don’t work with locals, or require >< to be handled at compile time. Do you have at least a sketch of how this works?
Since there's nothing in the OP's article about implementation, I'm going to assume that the OP hasn't actually planned any, and is just looking at syntax and semantics.
Sure. Part of the reason I asked all those specific questions about the semantics is that if the OP (or anyone else who groks the use case) has a strong feeling that the answer must be X or must be Y, that would constrain the possible ways to implement it. To take one example: if aliases shouldn’t affect globals(), that means we probably need to modify something about the way STORE_NAME and friends work with normal namespaces rather than to create a new AliasDict and make that the default type for module namespaces and leave STORE_NAME alone. Also, if there are “obvious right answers” to many of those questions, but they imply contradictory things, it’s worth knowing that before getting into the details of the implementation. And finally: I suspect that most of this proposal is an attempt to work around a complexity that Python and other namespace-based languages don’t have in the first place, only lvalue-based languages like C++ (see the “ensure no copy” thing). But there seems to be a core idea that is _not_ be irrelevant to Python. And diving into the semantics should hopefully separate those out.
Currently, Python has a default set of rules for how to interpret the meaning of a bare name, but you can alter that with "global" and "nonlocal" declarations. Aliasing could be handled exactly the same way: at compile time, interpret this name as meaning the same as that name.
Sure, but the OP clearly wants this to work in globals within a Jupyter notebook, not just locals. I’m not sure you’d even want that to be compile time, but if you did, it couldn’t work the same way as locals (where the entire scope is compiled at once, so the compiler can distinguish different kinds of names and hang them on the code object). Also, some of the examples add a link to a class after it’s already been created, or even to an instance. Even if you could figure out how to make compile-time links in a class statement, I can’t see how you could make dynamically adding links to a class object compile-time.
It would be more Pythonic to use a keyword rather than the "><" glyph (even while typing it for that example, my fingers autocorrected to "<>", which would be syntactically valid but usually meaningless -
Wait, isn’t <> a syntax error (unless you import Barry)? Not that I think >< is beautiful—and the OP gave that as a placeholder until someone thinks of something better—but if <> is an error, and linters and IDEs can suggest that maybe you meant ><, I’m not sure this part is a problem.
The trouble is that the "alias-ness" of it needs to be able to be stored in a namespace somehow.
Yes, and it needs to be storable in both dict-based and fast-local namespaces and work the same way (or differently but in a well-defined and -motivated different way), not to mention _slots_ and modules with custom namespace types and so on, and it needs to do so without making every runtime access and assignment significantly slower.