[Python-Dev] PEP for adding a decimal type to Python

Guido van Rossum guido@zope.com
Fri, 27 Jul 2001 09:08:51 -0400

> Just a suggestion which might also open the door for other numeric
> type extensions to play along nicely:
> Would it make sense to have an extensible registry of constructors 
> for numeric types which maps number literal modifiers to constructors ?
> I am thinking of
> 123L -> long("123")
> 123i -> int("123")
> 123.45f -> float("123.45")
> The registry would map 'L' to long(), 'i' to int(), 'f' to float()
> and be extensible in the sense, that e.g. an extension like
> mxNumber could register its own mappings which would make 
> the types defined in these extensions much more accessible
> without having to path the interpreter. mxNumber for example could
> then register 'r' to map to mx.Number.Rational() and a user could
> then write 1/2r would map to 1 / mx.Number.Rational("2") and
> generate a Rational number object for 1/2.
> The registry would have to be made smart enough to seperate
> integer notations from floating point ones and use two separate
> default mapping for these, e.g. '<int>' -> int() and '<float>' ->
> float().
> The advantage of such a mechanism would be that a user could
> easily change the literal semantics at his/her taste.
> Note that I don't think that we really need a separate interpreter
> just to add decimals or rationals to the core. All that is needed
> is some easy way to construct these number objects without too
> much programming overhead (i.e. number of keys to hit ;-).

Funny, I had a similar idea today in the shower (always the best place
to think :-).  I'm not sure exactly how it would work yet --
currently, literals are converted to values at compile-time, so the
registry would have to be available to the compiler, but the concept
seems to make more sense if it is available and changeable at runtime.

Nevertheless, we should keep this in mind.

--Guido van Rossum (home page: http://www.python.org/~guido/)