[Python-Dev] Symmetry arguments for API expansion

[Paul Moore]

On 12 March 2018 at 17:59, Serhiy Storchaka <storchaka at gmail.com> wrote:
> 12.03.18 18:49, Raymond Hettinger пише:
>>
>> There is a feature request and patch to propagate the float.is_integer()
>> API through rest of the numeric types ( https://bugs.python.org/issue26680
>> ).
>>
>> While I don't think it is a good idea, the OP has been persistent and
>> wants his patch to go forward.
>>
>> It may be worthwhile to discuss on this list to help resolve this
>> particular request and to address the more general, recurring design
>> questions. Once a feature with a marginally valid use case is added to an
>> API, it is common for us to get downstream requests to propagate that API to
>> other places where it makes less sense but does restore a sense of symmetry
>> or consistency.  In cases where an abstract base class is involved,
>> acceptance of the request is usually automatic (i.e. range() and tuple()
>> objects growing index() and count() methods).  However, when our hand hasn't
>> been forced, there is still an opportunity to decline.  That said,
>> proponents of symmetry requests tend to feel strongly about it and tend to
>> never fully accept such a request being declined (it leaves them with a
>> sense
>>   that Python is disordered and unbalanced).
>>
>>
>> Raymond
>>
>>
>> ---- My thoughts on the feature request -----
>
>
> I concur with Raymond at all points about this concrete feature and about
> the general design in general.

So do I.

I do think that there is an element of considered judgement in all of
these types of request, and it's right that each such request be
considered on its merits. But I do not think that "symmetry with other
cases" is a merit in itself, it needs to be subjected to precisely the
same sort of scrutiny as any other argument.

In this case, Raymond's arguments seem persuasive to me (in
particular, the uselessness of int.is_integer() and the complexities
in deciding correct behaviour for Decimal.is_integer() in the absence
of an answer in the standard). I would ask why a standalone
is_integer() function, targeted at somewhere in the stdlib like the
math module[1] isn't acceptable, and I'd be wanting to see use cases
for the functionality - in particular use cases for a generic "can be
used for an unknown type" solution, as opposed to type-specific
solutions like float.is_integer or (Fraction.denominator == 1). I
imagine these questions have already been thrashed out on the tracker,
though.

It's certainly true that people get particularly wedded to
symmetry/consistency arguments. Sometimes such arguments have value
(discoverability, teachability, ease of writing type-agnostic code)
but we should keep that value in perspective.

Paul

[1] with possibly a period for development as a 3rd party library,
although I can see that "being built in" may be a key benefit of a
proposal like this