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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list
