On Wed, Mar 5, 2014 at 2:42 PM, Mark H. Harris firstname.lastname@example.org wrote:
The idea of python number means that there are no types, no limits, no constraints, and that all python numbers are dynamic. The upper level syntax is also very simple; all python numbers are simply human.
My influence for this preference is rooted in the Rexx programming language; attributed to Mike Cowlishaw, former IBM fellow. The Rexx programming language is dynamic, and has no types. To put it more succinctly for those of you who have not used Rexx, the only data type is a string of characters (that's it). Rexx numbers are simply those strings of characters that may be interpreted as a valid Rexx number.
I've used REXX extensively. (It's the native scripting language of OS/2, which I first met in the early 1990s and am still using - albeit usually in a VM under Linux these days - as it's still a good thing, just a little left-behind.) There are two huge downsides to that kind of proposal.
1) Performance. Huge huge performance hit. I can take Pike to OS/2, an unoptimized build on an unsupported platform, and absolutely cream a REXX program at any sort of computational work. By specifically working with integers rather than "numbers", I can run code blazingly fast.
2) Accuracy. With REXX, all arithmetic is governed by a single setting of NUMERIC DIGITS, which specifies how many digits of accuracy you want to preserve. (Python can improve granularity with separate contexts, but the same issue will still apply - contexts just let you use different NUMERIC DIGITS settings simultaneously in one program.) Set it too high and performance suffers because the system has to calculate more than you actually care about. Set it too low and accuracy suffers. Even when you're working with integers, going past DIGITS means it goes exponential.
3) Not so huge a downside, but also worth considering: REXX doesn't have complex number support at all. You have to simulate it with two variables. There's no way for the "Python number" system to intrinsically handle complexes.
So really, what you're looking at is unifying int/float/Decimal into a single data type, which is basically Decimal. I'd say merging int into that is a bad idea, but you can get most of what you want to achieve simply by encouraging the use of Decimal everywhere.
Maybe in some distant future version, the Python literal 1.234 will represent a Decimal rather than a float. (And then there'd be other consequences, like what you get when you divide one integer by another.) But until then, all you can really do is encourage people to explicitly use Decimal.