On Sat, 15 May 2021 at 20:52, David Mertz <me...@gnosis.cx> wrote: > > On Sat, May 15, 2021, 3:13 PM Oscar Benjamin >> >> That would mean that a simple statement like x = -1.01d could assign >> different values depending on the context. Maybe with the new parser it is >> easier to change this so that an unary +/- can be part of the literal. > > Steven, at least, stated he assumed this decimal literal would be either > decimal64 or decimal128. That would remove this exact concern you state. > > But decimal64 behaves differently that decimal128, and both have different > semantics than Decimal. I don't disagree that decimal128 is a useful data > type, but it's definitely a wrinkle for various flavors of "decimal" to arise > in various ways. For example, how does this change the numeric tower?
Decimal is not really in the numeric tower: https://bugs.python.org/issue43602 The question is really what exactly is the rationale for having a new Decimal type? I guess it's something like: """ The decimal module is well suited to more advanced needs but is hard to use for less experienced users who just want to do some simple calculation and expect that the arithmetic should work intuitively unlike binary floating point. We therefore introduce a new decimal type that is simpler and add literal syntax for that type so that the barrier to using decimal-based calculations is as low as possible. """ Then you need to consider how much easier you are really making things e.g. 0.1d vs D('0.1'). To what extent can the "hard to use" claim be countered by improving the docs e.g. by making a simpler explanation of how to use Decimal for basic calculations and perhaps adding a brief section to the tutorial? Most importantly: who is prepared to implement and maintain any of this? If the proposal is having 0.1d be Decimal('0.1') then that's a lot easier than introducing a new decimal128 type. If anyone wants to take this forward then I think that for that version of the proposal a usable C implementation of e.g. decimal128 is what is needed. I expect that making a conforming C implementation of decimal128 will be a lot harder than making a C implementation of Fraction. Making a really good implementation of either is hard but the "spec" for rational numbers is much simpler than for decimal floating point. -- Oscar _______________________________________________ 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/H7UUQAK6P62TS45RIM34ZHLS3AFYZADH/ Code of Conduct: http://python.org/psf/codeofconduct/
