[Python-ideas] Python Numbers as Human Concept Decimal System

[Stefan Krah]

Nick Coghlan <ncoghlan at gmail.com> wrote:
> Stefan: use the existing decimal type, change default context to Decimal64,
> round all decimal literals to current context

I'm open to many options, including doing nothing or somehow deal with
the UNARY_MINUS issue in another way.

First of all, I don't think that having a decimal literal is in any
way essential -- professional users probably deal with Decimals much
like Marc-Andre described and I cannot see why we should add a literal
primarily for inexperienced users.

So, if we add a literal, professional users should be able to use it
in a meaningful way, too.


I understand the benefits of a context with fixed precision, Emax and
Emin, so here are the drawbacks:

  1) It must be possible to set rounding and traps, so the context
     is not really fixed.

  2) Code that mixes Decimal64 and Decimal (virtually all professional
     code) will get hard to read and to understand, since we now have
     two contexts (problems) instead of one.

     Even tracking the flags will be challenging.

  3) We must decide between Decimal64 and Decimal128. The latter is
     quite a bit slower, the former may not have sufficient precision.


Now, to the argument that a context may be changed by a third party
package:

This is inherently true for all global (thread local) state and is really
a problem of the package.  Packages can do that with locales (which would
also affect the "n" formatting for Decimal64), packages can do that right
now with the existing Decimal type.

In fact, for a highly robust package, people should not use the global
context at all [1].  IIRC potential problems with coroutines were pointed
out on python-dev recently.


And that is another problem:  If a package is using fixed Decimal64 literals,
is it then supposed to use only the official global context?

I think that would be a bad idea, unless the official context is completely
frozen.  That on the other hand would deprive users of controlling Overflow,
clamping etc.


Stefan Krah



[1] If you read and implement this, do watch performance a little (method
    lookups can ruin a lot, using the operators is usually faster).