On 2021-06-22 15:35, Soni L. wrote:
Imagine if Python didn't have an + operator, but instead an + *infix function*.
Thus, every module would automatically include the global
def infix +(left, right): ...
And indeed, you could say we already have this. Except currently you can't define your own local infix +. But what if you*could*?
Then that would be bad.
All the examples you give seem bad to me. They just make the code more confusing.
Python combines various paradigms, but I think one way in which it very smoothly leverage object orientation is by making objects the locus of so much behavior. Operator overloads are defined at the object level, as are "quasi-operator" overloads for things like attribute lookup, iteration, context managers, etc. This means that the semantics of an expression are, by and large, determined by the types of the objects in that expression.
What you're describing is basically moving a lot of that out to the module level. Now instead of operator overloads being governed by objects, they'd be governed by the module in which the code appears. The semantics of an expression would be determined not (only) by the types of the objects involved, but also by the module in which the expression textually occurs.
There aren't many things in Python that work this way. Future imports are the main one, but those are rare (and rightly so). The import machinery itself provides some possibility for this (as used by stuff like macropy) but is mostly not used for such things (and again rightly so).
Beyond that, I just think this kind of thing is a bad idea. Objects naturally cross module boundaries, in that an object may be created in one module and used in many other modules. It is good for an object's behavior to be consistent across modules, so that someone using an object (or readng code that uses an object) can look at the documentation for that object's type and understand how it will work in any context. It is good for code to be understandable in a "bottom up" way in which you understand the parts (the objects, expressions, syntactic structures, etc.) and can combine your understanding of those parts to understand the whole. It is bad for an object to shapeshift and do different things in different contexts. It is bad for code to heavily depend on "top down" information that requires you to know "where you are" (in one module or another) to understand how things work. That increases cognitive burden and makes code more difficult to understand.
Personally I'm opposed to anything that moves in that direction.