[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
[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
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
[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 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
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
[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
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
> 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
>
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:
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():
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
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 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
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 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
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 2018-03-12, 13:13 GMT, Nick Coghlan wrote:
> +1 from me, as even if commercial redistributors do decide
> they want to collaborate on a post-2020 Python 2.7 maintenance
> branch, there's no technical reason that that needs to live
> under the "python" GitHub organisation, and some solid
> lo
On 11 March 2018 at 11:54, Guido van Rossum wrote:
> Let's not play games with semantics. The way I see the situation for 2.7
> is that EOL is January 1st, 2020, and there will be no updates, not even
> source-only security patches, after that date. Support (from the core devs,
> the PSF, and pyt
19 matches
Mail list logo
