On 2022-12-02 02:48, Anony Mous wrote:
Obviously if you were to say "extend library with X", and X was already
present (remember, these are immutable), such an attempt would fail.
Bang. Exception. The very first time you tried it. Therefore, you're
already directly on the path of "going to need a non-colliding name to
use my particular function." See how easy that was? It's absurd to claim
that this is any kind of meaningful obstacle. If it happens, you just
fix it. Like any other programming issue. This is what we do.
It seems you still don't really grasp the scope (har har) of the
problem here. Suppose there is library A and library B and your program
uses both of them. Now you write your program to "extend A with X".
You test it and everything else works fine.
Now six months later a new version of *library B* decides to also
"extend A with X". Now your program breaks, not because of any change
in your code, nor in the code of the library you extended, but because
of a change in the code of a separate library.
You can't just "choose a non-colliding name", because by allowing this
sort of monkeypatching you're breaking down the namespacing barriers
between different modules. A name that's non-colliding *today* might
collide down the road. The way things work now, this can still happen
to some extent, but it's greatly mitigated by the fact that each library
only has to worry about naming collisions within its own code. If
libraries start going around creating names in other libraries
willy-nilly, any library may potentially break any other library (and
thus all code that depends on either). That would be a debugging nightmare.
Of course, even so, this is still possible in current Python, because
we *can* monkeypatch things. But it's a bad idea and most libraries
don't do it; also, our ability to monkeypatch builtins is limited . It
seems what you're describing is a system for encouraging more
monkeypatching (including of builtins), which isn't a road I'd want to
go down.
--
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/HHRQZEZVOT67ATM5IUO57VPGR2LB3XPM/
Code of Conduct: http://python.org/psf/codeofconduct/
