Against PEP 240

Cameron Laird claird at
Tue May 29 16:31:00 CEST 2001

In article <Ae4BQuAFb6E7Ew0t at>,
Robin Becker  <robin at> wrote:
>In article <9f03m401qcu at>, Alex Martelli
><aleaxit at> writes
>Well OK I accept that BCD has been used. I also in a distant past used
>snobol, spitbol, pl/1 and similar. I defy anyone to claim that cobol
>ever had a significant impact on thought. Of course I should wear more
>flameproof clothes. 
>Floating point is what it says floating point. I don't use commas. As
>for being naive; I used to do the most awful assembly code to get extra
>bits out of accelerated tangent series and the like. I know what an ulp
>is, but I don't claim that makes me better than anyone else though. I
>guess like many an old fart I long for the good old days when missiles
>ruled the budgets and 60 bit fp was as good as it got. Moan whine.
>My main objection is that this is likely to bust just about any
>extension that uses floating point.
Robin, I'm another old-timer who's twiddled
abundant bits in assembler to get results that
would let my customers sleep better at night.
Feel free to use adult language.

Let's be precise:  extensions that pass float-
ing point data will all be broken.  I don't
regard broken extensions lightly; I know what
a cost it can be to reassemble all the parts
just to recreate what one had before.  Do you
agree there'd be value in adding a coda to the
PEP about how to rewrite extensions?  Shall
part of the PEP be a function on the C side
that helps ease the task?
>I'm not against using rationals. They will be slower and I'll have to
>worry about that. I'll be happy if the numerical types PEP allows me
>eventually to get an interval arithmetic together and or do some proper
>numerical differentials (and I'm not talking about finite differences).
>Of all the types I would prefer to have added the first would be a
>parametrized binary fixed point.
>Robin Becker


Cameron Laird <claird at>

More information about the Python-list mailing list