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 -----
What is the proposal?
* Add an is_integer() method to int(), Decimal(), Fraction(), and Real().
Modify Rational() to provide a default implementation.
Starting point: Do we need this?
* We already have a simple, traditional, portable, and readable way to make the
test: int(x) == x
* In the context of ints, the test x.is_integer() always returns True. This
isn't very useful.
* Aside from the OP, this behavior has never been requested in Python's 27 year
history.
Does it cost us anything?
* Yes, adding a method to the numeric tower makes it a requirement for every
class that ever has or ever will register or inherit from the tower ABCs.
* Adding methods to a core object such as int() increases the cognitive load
for everyday users who look at dir(), call help(), or read the main docs.
* It conflicts with a design goal for the decimal module to not invent new
functionality beyond the spec unless essential for integration with the rest of
the language. The reasons included portability with other implementations and
not trying to guess what the committee would have decided in the face of tricky
questions such as whether Decimal('1.000001').is_integer()
should return True when the context precision is only three decimal places
(i.e. whether context precision and rounding traps should be applied before the
test and whether context flags should change after the test).
Shouldn't everything in a concrete class also be in an ABC and all its
subclasses?
* In general, the answer is no. The ABCs are intended to span only basic
functionality. For example, GvR intentionally omitted update() from the Set()
ABC because the need was fulfilled by __ior__().
But int() already has real, imag, numerator, and denominator, why is this
different?
* Those attributes are central to the functioning of the numeric tower.
* In contrast, the is_integer() method is a peripheral and incidental concept.
What does "API Parsimony" mean?
* Avoidance of feature creep.
* Preference for only one obvious way to do things.
* Practicality (not craving things you don't really need) beats purity
(symmetry and foolish consistency).
* YAGNI suggests holding off in the absence of clear need.
* Recognition that smaller APIs are generally better for users.
Are there problems with symmetry/consistency arguments?
* The need for guard rails on an overpass doesn't imply the same need on a
underpass even though both are in the category of grade changing byways.
* "In for a penny, in for a pound" isn't a principle of good design; rather, it
is a slippery slope whereby the acceptance of a questionable feature in one
place seems to compel later decisions to propagate the feature to other places
where the cost / benefit trade-offs are less favorable.
Should float.as_integer() have ever been added in the first place?
* Likely, it should have been a math module function like isclose() and isinf()
so that it would not have been type specific.
* However, that ship has sailed; instead, the question is whether we now have
to double down and have to dispatch other ships as well.
* There is some question as to whether it is even a good idea to be testing the
results of floating point calculations for exact values. It may be useful for
testing inputs, but is likely a trap for people using it other contexts.
Have we ever had problems with just accepting requests solely based on symmetry?
* Yes. The str.startswith() and str.endswith() methods were given optional
start/end arguments to be consistent with str.index(), not because there were
known use cases where code was made better with the new feature. This ended
up conflicting with a later feature request that did have valid use cases
(supporting multiple test prefixes/suffixes). As a result, we ended-up with an
awkward and error-prone API that requires double parenthesis for the valid use
case: url.endswith(('.html', '.css')).
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
