[Python-Dev] PEP 242 Numeric kinds

[paul@pfdubois.com]

PEP-242 does not have anything to do with:
   a. Whether or not some future issue of Numeric goes into the core
   b. Decimal arithmetic
   c. Rational arithmetic

THe current implementation lives in the optional Packages area of the Num=
eric
distribution purely because it was convenient for me to put it there, and=

the most likely customers use Numeric anyway.

The only tie to Numeric is the ability of a kind to tell you the "type le=
tter"
that modules array and Numeric accept as types. 

Background: In Numeric there is an issue that if a Numeric.array a has ty=
pe
'f', corresponding to C 'float' rather than C 'double', it is inconvenien=
t
to 
maintain that type at 'f' during operations with scalars. It  used to be

impossible, now it is inconvenient, and with Numarray it won't be a probl=
em.

Historically then, a lot of us were interested in putting a floating poin=
t
type into Python that corresponded to C 'float'; otherwise something like=

a[i] * b was leading to a double result because a[i], a Python scalar, is=

double. If we had an 'f' scalar, we could make a[i] return that instead
of a 'd' scalar. Yes, there would be no literal equivalent (unless we got=

into the usual fistfight over the literals) but that didn't matter so muc=
h.

With Numarray there is no need for this so the interest in making an 'f'
scalar has declined. 

Still, kinds has its uses anyway. It appears that maybe I'm being too shy=

about its virtues. Certainly many of the standard library modules are equ=
ally
obscure and you could view kinds as a wrapping of a standard C header fil=
e
and therefore of sufficient interest. 

So I will restate my position as, I'd like to push 242 forward or backwar=
d.
It shouldn't sit there in limbo. Advice from the PEPczar about process wo=
uld
be welcomed by me.