[Python-Dev] Symmetry arguments for API expansion

[Tim Peters]

[Tim]
>> At heart, the Fraction() constructor is _all about_ creating integer
>> ratios, so is the most natural place to put knowledge of how to do so.
>> A protocol for allowing new numeric types to get converted to Fraction
>> would be more generally useful than just a weird method only datetime
>> uses ;-)

[Guido]
> Ironically, the various Fraction constructors *calls* as_integer_ratio() for
> floats and Decimals. From which follows IMO that the float and Decimal
> classes are the right place to encapsulate the knowledge on how to do it.

It appears that as_integer_ratio was slammed into floats and Decimals
precisely _so that_ Fraction() could call them, while Fraction has its
own self-contained knowledge of how to convert ints and Fractions and
strings and numbers.Rationals to Fraction (and the former types don't
support as_integer_ratio).

That's fine, but my objection is subtler:  the actual answer to "can
this thing be converted to an integer ratio?" is not "does it support
as_integer_ratio?",  but rather "can Fraction() deal with it?" - and
there's currently no way for a new numeric type to say "and here's how
I can be converted to Fraction".

An obvious way to extend it is for Fraction() to look for a special
method too, say "_as_integer_ratio()".  The leading underscore would
reflect the truth:  that this wasn't really intended to be a public
method on its own, but is an internal protocol for use by the
Fraction() constructor.

Then it would be obvious that, e.g., it would be just plain stupid ;-)
for `int` to bother implementing _as_integer_ratio.  The only real
point of the method is to play nice with the Fraction constructor.
_As is_, it's jarring that int.as_integer_ratio() doesn't exist - for
the same reason it's jarring int.hex() doesn't exist.

If Mark or I wanted to use float._as_integer_ratio() directly too,
that's fine: we're numeric grownups and won't throw a hissy fit if
ints don't support it too ;-)