On Tue, 5 Apr 2022 at 13:00, Steven D'Aprano <st...@pearwood.info> wrote: > > On Tue, Apr 05, 2022 at 04:02:24AM +1000, Chris Angelico wrote: > > > Is it really that much of a problem? Tell me: How often do you REALLY > > expect to have collisions within an application, but in different > > modules? YAGNI. > > You have no idea how many different definitions there are for "mile", do > you? :-)
I don't, but I know there are many. But that's not the problem. The problem is: Do you ever have one module that's using statute miles and another that's using nautical miles, but *not both in the same module*? The only reason to have them namespaced to modules is to allow different modules to use them independently. If your application needs to use both statute and nautical miles in the same module (most likely the main module), then it's going to have an issue, and your proposal adds a ton of complexity (that's a real unit, by the way, I totally didn't make it up) for no benefit whatsoever. > Sure, we can demand that every application that needs to deal with US > survey miles and imperial miles and international miles give them all > distinct names. That's one solution, but not the only solution. My solution is to allow the very very few applications that need both to do some sort of disambiguation. Of course, this is only significant if you need *literals* of all of them. The units themselves can be distinct, even if each one would want to register itself with the name "mile". > But even if you do that, having one interpreter-wide database that any > random library can write to is asking for trouble. If this becomes > widespread, expecting libraries to "just don't overwrite existing units" > is not good enough. What's your proposal? from units.SI import * ? This pollutes your main namespace *and* still has all the same problems. > Wait until you import some library which is not quite so accurate in its > definitions as yours, and it tramples all over your system-wide database > with its own (slightly different) definitions. How would you like your > unit conversions to differ according to the order in which you import > your libraries? > > "If I import cheddar first, then camembert, my lander safely lands on > Mars, but if I import camembert first, then cheddar, it crashes into the > planet at 215 miles per hour." > > Awesome. "If I import * from cheddar first, then camembert, then I have issues". What's the difference? You're looking at a fundamentally identical problem, and thinking that it's fundamentally solved by module-level separation? Show me some evidence. > Its 2022, and you're arguing in favour of a single system-wide database > where any random module can monkey-patch the definitions used by all > other modules. Ouch. Yup I am! Have you ever mutated sys.modules? That's a system-wide database. And there are lots of good reasons to insert things into it. What about importing the logging module and configuring it prior to importing something that spews a ton of messages during its own import? Been there, done that. Yes, a system-wide database isn't actually as terrifying as you seem to think - AND a module-scale separation doesn't even help. > This is exactly analogous to the situation Python would have if there > were no per-module globals, just the system-wide builtins, and every > library stored top-level variables and functions in that namespace. > *shudders* Straw man. It's more like using decimal.getcontext() and making changes. That's global. Do we have per-module Decimal contexts? Do we need them? No. In fact, the only way to change context is globally - though you can do so temporarily. That means you do not have any module-level separation *at all*. I don't hear the Decimal folks screaming about that. You want to add large amounts of completely unnecessary complexity on the basis that the module is the fundamental and sole correct place to namespace these. I'm not seeing any supporting arguments, other than "what if there were collisions? WON'T SOMEONE THINK OF THE COLLISIONS!". Please, show me where there are collisions across modules, and not within a module. That's what I asked, in the snippet you quoted. > Look, I know that in Python, any module *might* sneak into my globals > and modify them. But in practice, they don't, and that would be > considered malware if they did it without very good reason and very > obvious documentation. > > But to have a situation where *by design* all modules trample over each > other's defined units, that's a suboptimal design. (I'm being polite > there.) > I disagree, and I'm also being polite here. Let's keep it that way. ChrisA _______________________________________________ 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/VZXSX3OHDSKT2VTJ6CKCBSRAJRNC3EUF/ Code of Conduct: http://python.org/psf/codeofconduct/
