[Python-Dev] Symmetry arguments for API expansion (original) (raw)

Paul Moore p.f.moore at gmail.com
Mon Mar 12 14:22:15 EDT 2018

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.isinteger() 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

More information about the Python-Dev mailing list