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.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
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/4OUETMGSZEYXLQ23CPDUIKEJCUEEZKUO/
Code of Conduct: http://python.org/psf/codeofconduct/
