These objections -- such as they are -- are all applicable to every
instance of "I wrote a function" or even "I named a variable" in any
particular namespace: not just within imports, either. Anywhere. Global
context. Sub functions. etc.
Collisions, etc... not a big deal. Change a name. It'll still work the
same. Nothing to it. No matter what the context is in Python. If you were
talking about using a compiled library without the source code (and here
come the back hats), depending on the linking and permissions, you could
probably *still* change the name(s) in the library. But we're talking about
an interpreted scripting language. We have the source code for everything.
Or should. There is no mystery to be had.
You want your own TestDottedQuad? You fear collisions? Fine. Write it as
MyTest23DottedQuad87qxy or whatever. Be really random about it if it
assuages your concerns. Or just rename your new instance, or the one
extending the library (remember,it's an addition, if it's there, something
added it. So you *can* change it if that's your call.) if you can't stand
to write a new name for yours. Either way, bingo. Your functionality is
present in your project. The other functionality is present as well. Both
can be used with your strings. Choose. Enjoy your choice.
You want to write it the hard way, as a loose function that can't handle
class objects like strings? You can do that too. Something immutable is
broken or not functional for your purposes? Lift the code, fix it, give it
your own name, and use it. As an extension or directly. Whatever floats
your boat. There. Done. Easily.
Or... like these non-Python Ruby people that keep mysteriously polluting
the argument - just tell the team "we're not going to do that." Again,
problem solved. You do *not* have to cripple a language to resolve this in
any particular direction. But wait.... you told them and they won't/can't
comply? That's not a language issue. That's a "your team needs different
And mind you, this is all in the context of "big projects." Doing something
yourself? Not even worth a handwave. Write what you need, test it, secure
it, make it work, move on.
There are myriad ways to get naming issues into compliance with whatever
metric you want. Regardless of circumstance. This "we're going to save you
from yourself" mentality serves to coddle weak and/or lazy programmers
while crippling the rest.
The entire idea that these naming issues (and that's all they are) cannot
be coped with absolutely trivially is both nonsensical and insupportable.
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.
Are you thinking "but what if it wasn't tested so no one saw an exception?"
In that case, again, we have a staffing issue. Not a language issue.
As for the "big project" argument put forth earlier, that is also invalid.
In any big project, if the devs aren't outright newbs anyway, people are
given responsibility for specific functionality, and if random person X
wants to mod existing function Y, they submit a suggestion, it goes through
the appropriate process and gets accepted (possibly altered, such as... the
name), or not. Pull requests, etc. Whatever the process is.
But should there not be that (obvious and common these days) process, Any
function in the project is subject to name collisions, any use of any
library with name X / function X is subject to collisions, etc. And how do
we get out of such things? if library A and library B have the same names,
or prehaps function X and function Y, we change one of them. Now you have
your multiple names and/or namespaces and/or names within namespaces.
Likewise, if a function is added (at any level) and there is a name
collision, we can change that too. We can notify our crew and say "globally
edit 'TestDottedQuad' to 'MyTest23DottedQuad87qxy', and by the way, we're
having subs for lunch." Trivial. If your crew isn't up for such things...
well. That's a different problem entirely.
I appreciate that you have strong feelings about this, but you (neither of
the respondents here) have not presented any good arguments. Not even one.
That doesn't mean there aren't supporters of your positions - of course
there are - but every level of computing history is replete with bad ideas
supported by many, and good ideas trampled on by just as many.
Perceptrons/Minsky. Scrums. Clumsy typing systems. Chiclet keyboards.
Freeform formatting. "Comment every line of code." Segment registers (and
oh boy did that one cost us progress!) etc., etc., etc.
> I concur...
Concurring with one another doesn't ensure that you're right. It may also
mean you're both wrong in similar or identical ways.
To reiterate: I've already implemented this functionality through the
auspices of a preprocessor, which also means, no monkey patching. It works
very well, does exactly what I wanted, and improved my particular
circumstance significantly. And then we have:
> I find that implausible.
Okay. However, since I know the truth of it, I'll proceed to not worry in
the least that your thought process ended up there.