A rational proposal

[Nick Coghlan]

Mike Meyer wrote:
>>max() and min() are already part of the standard library.
>>Providing them as instance methods is quite irregular.
> 
> They don't handle decimals or rationals. This is following the lead of
> the decimal package.

As Tim pointed out - decimal has its own versions of max & min which conform to 
the decimal specification.

For the builtin in max and min, decimal's behave like any other number.

>>>- decimal(): return the decimal approximation to the rational in the
>>>            current context.
>>
>>This ought to be the responsibility of the decimal() constructor.
>>I can see including it here to avoid adding it to the decimal()
>>constructor, but IMO it's bad design.

Actually, what's missing at the moment is the decimal equivalent of __int__, 
__float__, etc.

Generally, for new types, it is the new type's responsibility to play well with 
pre-existing types, not the other way round (think about what the __str__ method 
actually does - it's the type conversion method for turning your object into a 
string object)

> Good point. Currently, objects now how to convert themselves to int,
> float and complex. Should Rational now how to convert itself to
> Decimal (and conversely, decimal now how to convert itself to
> Rational)?

Doing either of those properly requires adding slots to the type structure 
(since you need new magic methods - __decimal__ and __rational__).

I believe the goal is to have Decimal.decimal become a builtin for Py 2.5, in 
which case, I would also hope to see a __decimal__ special method.

The correct answer would then be for Rational.rational to handle decimals in its 
constructor, and provide an implementation of __decimal__ (similar to the way 
Decimal.decimal interacts with the other builtin types).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at email.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net