On Fri, Apr 8, 2022 at 8:29 AM Chris Angelico <ros...@gmail.com> wrote:
> > > another that's using nautical miles, but *not both in the same > > > module*? Absolutely! There is talk about "the Application" as though that's one thing, but Python applications these days can be quite large collections of third party packages -- each of which do not know about the other,a nd each of which may be using units in different ways. For example, I have an application that literally depends on four different JSON libraries -- each used by a different third-party package. Imagine if the configurable JSON encoding/decoding settings were global state -- that would be a disaster. Granted * Python is dynamic and has a global module namespace, so packages CAN monkey patch and make of mess of virtually anything. * "Well behaved" packages would not mess with the global configuration. But that doesn't mean that it wouldn't happen -- why encourage it? Why have a global registry and then tell people not to use it? Having a global registry/context/whatever for something that is designed/expected to be configured is dangerous and essentially useless. I'm not sure if this is really a good analogy, but it reminds me of the issues with system locale settings: Back in the day, it seemed like a great idea to have one central palceon a computer to set these nifty things that apply to that particular computer. But enter the internet, where the location the computer the code is running on could be completely unrelated to where the user is and what the user wants to see, and it's a complete mess. Add to that different operating systems, etc. To this day, Python struggles with these issues -- if you use the default settings to open a text file, it may get virtually any encoding depending on what system the program is running on -- there is a PEP in progress to fix that, but it's been a long time! Dateitme handling has the same issues -- I think the C libs STILL use the system timezone settings. And an early version of the numpy datetime implementation did too -- realy bad idea. In short: The context in which code is run should be in complete control of the person writing the code, not the person writing the "application". Again: practical use case with units: I maintain a primitive unit conversion lib -- in that lib, I have a "registry" of units and names and synonyms, etc. That registry is loaded at module import, and at that time it checks for conflicts, etc. Being Python, the registry could be altered at run time, but that is not exposed as part of the public API, and it's not a recommended or standard practice. And this lets me make all sorts of arbitrary decisions about what "mile" and "oz" and all that means, and it's not going to get broken by someone else that prefers different uses -- at least if they use the public API. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/UDGHUPACN7ZP6YZYOBWOB4CEVQWTGMGM/ Code of Conduct: http://python.org/psf/codeofconduct/
