On Thu, 7 Apr 2022 at 07:41, Brendan Barnwell <brenb...@brenbarn.net> wrote: > > On 2022-04-06 14:28, Chris Angelico wrote: > > What do the specialized libraries offer that Decimal doesn't? Is it > > really worth all that hassle for the sake of teaching something that, > > in production, would just be done with floats and the math module > > anyway? > > If the decimal module did not already have a global context, would you > suggest adding it just in order to support this sort of teaching use-case?
If it didn't have any sort of precision changing, I wouldn't be using it, as it wouldn't offer anything that floats don't (in terms of teaching - obviously decimal rather than binary floats have specific use-cases, but mine isn't one of them). If the context feature didn't exist, I would assume that precision is configured globally in some way, and that would be absolutely fine with me. > It seems to me that the general claim about global context being a > mistake is that it can create pitfalls. In that sense, the global > context already is a "hassle" that is imposed on people. I don't see > that the potentially-offsetting benefit of (as you say) teaching > something that would actually just be done with floats is really that > compelling. It's nice, sure, but I also don't see any problem with > saying "sorry, you'll have to install a third-party module if you want > to teach some mathematical background about how some operations work, > because we only put into the stdlib what was necessary to actually do > those operations, not teach and demo their underpinnings". I don't understand. What do you mean by pitfalls, and how else would you do variable-precision in the standard library? The most obvious way would simply be "decimal.set_precision(500)" which would, obviously, be completely global. The way it currently is, "decimal.getcontext().prec = 500", isn't very much harder, and permits non-global contexts, but either way, a global context is a good idea for many applications. Yes, there are cases where you need other contexts, but eliminating the global default context creates a HUGE set of hassles. That's why, for instance, the random module has a set of default functions which come from a single global Random object - and the vast majority of applications don't need to create dedicated Random objects, because the global is the right choice. The tools are there for when you need more flexibility, but when you don't need them, you don't have to worry about them. Practicality beats purity. 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/P4GLOFZRBB57GCMNX37U6JWJSFRJC2F7/ Code of Conduct: http://python.org/psf/codeofconduct/
