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

[Michael McLay]

On Friday 27 July 2001 06:13 am, M.-A. Lemburg wrote:
> 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")

With the changes made in the prototype this would be relatively easy to 
implement. 

Using an 'i' suffix could be confused with an imaginary number.  It would be 
very easy for someone to mistakenly type 12i instead of 12j and get an 
integer instead of an imaginary number

The next implementation of my PEP will change the 'f' to a 'b', as in binary 
number.  The same suffix is used for both integer and float because they work 
together as a binary number implementation of numbers.  With the decimal 
number implementation there is only one type for both integer and float.

    123b -> int("123") 
    123.45b -> 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 tokenizer just passes a number with a suffix as a string to a function in 
compiler.c   The number in the string could be any valid number, e.g. 123, 
123.45, 123.45e-3, or .123. The function processing the string then 
determines what type of number object to create based on the suffix.  It 
would be the responsibility of the function that processes the 'r' suffix to 
accept or reject the number encoded in the string. 

> 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 ;-).

I wasn't suggesting creating a separate interpreter, I was suggesting adding 
a simple mechanism for allowing a new dialect of Python to be added to the 
existing interpreter.  This new dialect would be easier to use for certain 
types of programming activities.  The use of a decimal number type as the 
default type in this new language dialect is only one change that was 
proposed.  Another would be to use Unicode as the default character set.  
This would allow Unicode characters to be in strings without needing to 
escape them.  The proposal also suggests removing the tab character from 
indentation of blocks.  The goal is to create a language that would clean up 
some of the warts in the Python syntax and take advantage of the capabilities 
of modern IDE environments.

The idea of adding a new language on top of the existing infrastructure isn't 
that unusual. The gcc compiler can process many languages to produce a common 
machine dependant object code.  I can envision taking my simple changes a few 
steps further and turning the entire tokenizer into a replaceable unit.  This 
approach would allows projects to build other languages on top of the Python 
byte code interpreter.  Imagine having Javascript, VBasic, or sh tokenizer 
frontends generating Python bytecodes.  Think of it as the pyNET 
architecture:-)  This change probably belongs in Python4k.

Perhaps the PEP should be split into two parts.  The first PEP would be to 
add decimal characters with a 'd' suffix and also allow suffix characters to 
be added to the default float and integer types.  I think everyone agrees 
that this change is needed.

The second PEP will cover the proposed creation of the dpython dialect.  This 
PEP would be a container for proposed changes to the Python syntax that would 
make the language easier to teach to newbies and easier to use in a financial 
application.

Your suggestion to allow additional numerical types to be added by users 
would be included in the first PEP if the BDFL thinks this is a good idea.