On Sun, Apr 10, 2022 at 7:25 PM Chris Angelico <ros...@gmail.com> wrote:
> > You might not be, but those of us who use it, or *would* use it if it > > wasn't so dangerous, think differently. > > Would you? What would the behaviour of os.chdir be if it had module > scope? Please explain, I am very curious. > I don't think it helps to be making this parallel -- there is one "current working dir" at once -- that's how it's defined, it's by definition global, and good or bad, that's what it is. But I would say in my library code I NEVER use the current working dir - and certainly don't change it. If a path is passed in, then it's either relative or absolute, and that's OK -- it's in control of the user of the library (the application) -- not the library itself. I have seen code that caches the workingdir, change it, then puts it back -- but that's very much not thread safe, and I'd only recommend it maybe in tests. Back to units and Decimal -- I'm not necessarily advocating module scope -- that is a bit tricky, but in general, I have for the principle that the person writing the code (library author, say) can know and control what's going to happen: If my library converts from lbs to kg -- that had better work, and work the same way regardless of what the application author thinks is allowed, and regardless of what other libraries might need either. For Decimal -- if someone has written an accounting library -- it has damn better well use the proper precision and rounding rules for the kind of accounting it's doing. And it sure as heck shouldn't change because someone writing an application has a different need for Decimals. If all this means that it's impossible to have built-in syntax, then fine -- we shouldn't' have built in syntax -- it would only be useful for one-file scripts and the like, and there are other options for that -- like preprocessors. > Do you actually have a use-case where a library needs to do unit-aware arithmetic independently of the application, or is this purely hypothetical? I sure do -- have I not made this clear? > Libraries should do things that are affected by application configs, when they are working at the behest of the application. > When a library is doing its own thing, it should be independent of such configs. Exactly -- the problem is that I can't imagine a single case where i'd want the behavior of any of my libraries to be altered by the "application" -- so I'd never turn that on, so i dont think there's any point in global context -- and it's dangerous if using the global context is default and easier to do -- folks will use them, and their code will break when it's used in a different context. -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/PDTJ62J6LI3QZ5M2BZXEDJ5GKUJWOAKN/ Code of Conduct: http://python.org/psf/codeofconduct/
