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 l
On Mon, Mar 12, 2018 at 9:51 AM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> 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
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.
I
On 12 March 2018 at 17:59, Serhiy Storchaka 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 ide
On Mon, 12 Mar 2018 09:49:27 -0700
Raymond Hettinger wrote:
>
> Starting point: Do we need this?
> * We already have a simple, traditional, portable, and readable way to make
> the test: int(x) == x
It doesn't look that obvious to me. As a reviewer I would request to
add a comment explaining
On Mon, Mar 12, 2018 at 4:49 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> What is the proposal?
> * Add an is_integer() method to int(), Decimal(), Fraction(), and Real().
> Modify Rational() to provide a default implementation.
>
>From the issue discussion, it sounds to me as th
There's a reason why adding this to int feels right to me. In mypy we treat
int as a sub*type* of float, even though technically it isn't a sub*class*.
The absence of an is_integer() method on int means that this code has a bug
that mypy doesn't catch:
def f(x: float):
if x.is_integer():
12.03.18 21:15, Guido van Rossum пише:
There's a reason why adding this to int feels right to me. In mypy we
treat int as a sub*type* of float, even though technically it isn't a
sub*class*.. The absence of an is_integer() method on int means that
this code has a bug that mypy doesn't catch:
> On Mar 12, 2018, at 12:15 PM, Guido van Rossum wrote:
>
> There's a reason why adding this to int feels right to me. In mypy we treat
> int as a sub*type* of float, even though technically it isn't a sub*class*.
> The absence of an is_integer() method on int means that this code has a bug
>
On Mon, Mar 12, 2018 at 1:03 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> > On Mar 12, 2018, at 12:15 PM, Guido van Rossum wrote:
> >
> > There's a reason why adding this to int feels right to me. In mypy we
> treat int as a sub*type* of float, even though technically it isn't
[Guido]
> as_integer_ratio() seems mostly cute (it has Tim Peters all
> over it),
Nope! I had nothing to do with it. I would have been -0.5 on adding
it had I been aware at the time.
- I expect the audience is tiny.
- While, ya, _I_ have uses for it, I had a utility function for it
approx
If anyone cares, my vote is to rip out both .as_integer_ratio() and
.is_integer() from Python. I've never used either and wouldn't want to.
Both seem like perfectly good functions for the `math` module, albeit the
former is simply the Fraction() constructor.
I can see no sane reason why anyone wo
On Mon, Mar 12, 2018 at 5:18 PM, Tim Peters wrote:
> [Guido]
>> as_integer_ratio() seems mostly cute (it has Tim Peters all
>> over it),
>
> Nope! I had nothing to do with it. I would have been -0.5 on adding
> it had I been aware at the time.
>
> - I expect the audience is tiny.
The datet
[David Mertz ]
> ...
> I can see no sane reason why anyone would ever call float.is_integer()
> actually. That should always be spelled math.isclose(x, int(x)) because
> IEEE-754. Attractive nuisance is probably too generous, I'd simply call the
> method a bug.
Sometimes it's necessary to know, an
On Mon, Mar 12, 2018, 3:25 PM Tim Peters wrote:
> [David Mertz ]
> > ...
> > I can see no sane reason why anyone would ever call float.is_integer()
> > actually. That should always be spelled math.isclose(x, int(x)) because
> > IEEE-754. Attractive nuisance is probably too generous, I'd simply ca
[Tim Peters]
>> ...
>> >>> (-math.inf) ** 3.1
>> inf
[David Mertz]
> Weird. I take it that's what IEEE-754 says. NaN would sure be more intuitive
> here since inf+inf-j is not in the domain of Reals. Well, technically
> neither is inf, but at least it's the limit of the domain. :-).
Mathematical
[Tim. on as_integer_ratio()]
>> - I expect the audience is tiny.
[Alexander Belopolsky]
> The datetime module would benefit from having as_integer_ratio()
> supported by more types. It's been hard to resist requests to allow
> Decimal in timedelta constructors and/or arithmetics
I don't see the
On 03/12/2018 08:41 PM, Guido van Rossum wrote:
If you force me to choose between allowing hex(3.14) or 42.hex() I'll
choose the latter
I assume you meant (42).hex() here. If you're also interested in
changing the language to permit 42.hex(), well, color me shocked :D
(For those who haven
13.03.18 10:35, Larry Hastings пише:
On 03/12/2018 08:41 PM, Guido van Rossum wrote:
If you force me to choose between allowing hex(3.14) or 42.hex() I'll
choose the latter
I assume you meant (42).hex() here. If you're also interested in
changing the language to permit 42.hex(), well, color
On Mon, Mar 12, 2018 at 9:18 PM, Tim Peters wrote:
> [Guido]
> > as_integer_ratio() seems mostly cute (it has Tim Peters all
> > over it),
>
> Nope! I had nothing to do with it. I would have been -0.5 on adding
> it had I been aware at the time.
>
Looks like it snuck into the float type a
On Mon, Mar 12, 2018 at 09:49:27AM -0700, Raymond Hettinger wrote:
> * We already have a simple, traditional, portable, and readable way to
> make the test: int(x) == x
Alas, the simple way is not always the correct way:
py> x = float('inf')
py> x == int(x)
Traceback (most recent call last):
On Mon, Mar 12, 2018 at 10:01 PM, Tim Peters wrote:
> 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 us
[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
So let's make as_integer_ratio() the standard protocol for "how to make a
Fraction out of a number that doesn't implement numbers.Rational". We
already have two examples of this (float and Decimal) and perhaps numpy or
the sometimes proposed fixed-width decimal type can benefit from it too. If
this
[Guido]
> So let's make as_integer_ratio() the standard protocol for "how to make a
> Fraction out of a number that doesn't implement numbers.Rational". We
> already have two examples of this (float and Decimal) and perhaps numpy or
> the sometimes proposed fixed-width decimal type can benefit from
> On Mar 13, 2018, at 10:43 AM, Guido van Rossum wrote:
>
> So let's make as_integer_ratio() the standard protocol for "how to make a
> Fraction out of a number that doesn't implement numbers.Rational". We already
> have two examples of this (float and Decimal) and perhaps numpy or the
> som
OK, please make it so.
On Tue, Mar 13, 2018 at 11:39 AM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
>
> > On Mar 13, 2018, at 10:43 AM, Guido van Rossum wrote:
> >
> > So let's make as_integer_ratio() the standard protocol for "how to make
> a Fraction out of a number that doesn't
> On Mar 13, 2018, at 12:07 PM, Guido van Rossum wrote:
>
> OK, please make it so.
Will do. I'll create a tracker issue right away.
Since this one looks easy (as many things do at first), I would like to assign
it to Nofar Schnider (one of my mentees).
Raymond
>
> On Tue, Mar 13, 2018
Tim Peters wrote:
An obvious way to extend it is for Fraction() to look for a special
method too, say "_as_integer_ratio()".
Why not __as_integer_ratio__?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/list
[Tim]
>> An obvious way to extend it is for Fraction() to look for a special
>> method too, say "_as_integer_ratio()".
[Greg Ewing]
> Why not __as_integer_ratio__?
Because. at this point, that would be beating a dead horse ;-)
___
Python-Dev mailing lis
It seems .as_integer_ratio() has been resolved.
what about the original .is_integer() request? (Or did I miss that somehow?)
Anyway, it seems like __index__() should play a role here somehow... isn't
that how you ask an object for the integer version of itself?
Could float et al. add an __index_
No, the whole point of __index__ is that it refuses *all* floats --
otherwise people will do approximate computations that for their simple
test inputs give whole numbers, use them as sequence indices, and then find
their code broken only when the computation incurs some floating point
approximatio
On Wed, Mar 21, 2018 at 12:32:11AM +, Chris Barker wrote:
> Could float et al. add an __index__ method that would return a ValueError
> if the value was not an integer?
That would allow us to write things like:
"abcdefgh"[5.0]
which is one of the things __index__ was invented to prevent.
On Wed, Mar 21, 2018 at 4:42 AM Steven D'Aprano wrote:
>
>
> > Could float et al. add an __index__ method that would return a ValueError
> > if the value was not an integer?
>
> That would allow us to write things like:
>
> "abcdefgh"[5.0]
>
> which is one of the things __index__ was invented to
On 14 March 2018 at 08:29, Tim Peters wrote:
> [Tim]
> >> An obvious way to extend it is for Fraction() to look for a special
> >> method too, say "_as_integer_ratio()".
>
> [Greg Ewing]
> > Why not __as_integer_ratio__?
>
> Because. at this point, that would be beating a dead horse ;-)
>
I'm no
On Wed, Mar 21, 2018 at 10:31:19AM +, Chris Barker wrote:
> On Wed, Mar 21, 2018 at 4:42 AM Steven D'Aprano wrote:
> > > Could float et al. add an __index__ method that would return a ValueError
> > > if the value was not an integer?
> >
> > That would allow us to write things like:
> >
> > "a
As requested on the bug tracker, I've submitted a pull request for
is_integer() support on the other numeric types.
https://github.com/python/cpython/pull/6121
These are the tactics I used to implement it:
- float: is_integer() already exists, so no changes
- int: return True
- Real: return x
Thank you! As you may or may not have noticed in a different thread, we're
going through a small existential crisis regarding the usefulness of
is_integer() -- Serhiy believes it is not useful (and even an attractive
nuisance) and should be deprecated. OTOH the existence of
dec_mpd_isinteger() seem
On Mar 21, 2018 05:40, "Steven D'Aprano" wrote:
I don't want to change the behaviour of pow(), but we shouldn't dismiss
the possibility of some other numeric function wanting to treat values
N.0 and N the same. Let's say, an is_prime(x) function that supports
floats as well as ints:
is_prim
On Wed, Mar 21, 2018 at 09:46:06AM -0700, Nathaniel Smith wrote:
[...]
> For me this is an argument against is_integer() rather than for it :-).
> is_prime(float) should *obviously*[1] be a TypeError. Primality is only
> meaningfully defined over the domain of integers
And 3.0 is an integer. Just
On Wed, Mar 21, 2018 at 12:38 PM, Steven D'Aprano
wrote:
> In fact, Serhiy's suggestion is not correct when x is not a float:
>
This is a key point -- see some of Tim's posts -- like ot or not, you
probably need to know when you are working with a float and when you aren't
-- and what the implic
On Wed, Mar 21, 2018 at 4:12 PM, Guido van Rossum wrote:
> Thank you! As you may or may not have noticed in a different thread, we're
> going through a small existential crisis regarding the usefulness of
> is_integer() -- Serhiy believes it is not useful (and even an attractive
> nuisance) and s
On Wed, Mar 21, 2018 at 6:48 PM, Chris Barker wrote:
> On Wed, Mar 21, 2018 at 4:12 PM, Guido van Rossum
> wrote:
>
>> Thank you! As you may or may not have noticed in a different thread,
>> we're going through a small existential crisis regarding the usefulness of
>> is_integer() -- Serhiy beli
I know this is all done, but for completeness’ sake:
I just noticed math.trunc() and __trunc__().
So wouldn’t the “correct” way to check for an integral value be something
like:
obj.__trunc__() == obj
I don’t think this has any bearing on adding is_integer() methods to
numeric objects, but migh
In the PR I've submitted, that's essentially what I'm doing for the default
Real.is_integer() implementation. The details differ slightly, in that I
rely on the int() constructor to call __trunc__(), rather than introduce a
new dependency on the math module.
On Tue, 27 Mar 2018 at 21:29, Chris Bar
45 matches
Mail list logo
