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 staffing" issue. 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. For instance: 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.
_______________________________________________ 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/NNRAUFKFO4Z4XCG25VB2CWDYJJSPM5BS/ Code of Conduct: http://python.org/psf/codeofconduct/
