How about adding rational fraction to Python?

[Steven D'Aprano]

On Thu, 28 Feb 2008 00:30:11 -0800, Dennis Lee Bieber wrote:

> On Thu, 28 Feb 2008 01:25:32 -0000, Steven D'Aprano
> <steve at REMOVE-THIS-cybersource.com.au> declaimed the following in
> comp.lang.python:
> 
>> When it comes to mixed arithmetic, it's just too darn inconvenient to
>> forbid automatic conversions. Otherwise you end up either forbidding
>> things like 1 + 1.0 on the basis that it isn't clear whether the
>> programmer wants an int result or a float result, or else even more
>> complex rules ("if the left operator is an int, and the result of the
>> addition has a zero floating-point part, then the result is an int,
>> otherwise it's an error, but if the left operator is a float, the
>> result is always a float"). Or a proliferation of operators, with
>> integer and floating point versions of everything.
> 
> 	Automatic conversions, okay... but converting a result when all
> inputs are of one time, NO...

What? How does that make any sense?

By that logic, we should see this:

>>> len("a string")
'8'
>>> len([2, 4, 6])
[3]
>>> len({'key': 'value'})
{1: None}



> 	The only rule needed is very simple: promote simpler types to the
> more complex type involved in the current expression (with expression
> defined as "value operator value" -- so (1/2) * 3.0 is INTEGER 1/2,
> resultant 0 then promoted to float 0.0 to be compatible with 3.0).
> 
> 	Very simple rule, used by very many traditional programming
> languages.

And rightly rejected by many other programming languages, including 
modern Python, not to mention calculators, real mathematics and common 
sense.



-- 
Steven