> Do you have an idea of how many projects would emit such warning? More
and more projects are running their test suite using -Werror. Any new
warning can make a project test suite to fail.
I don't have an opinion on __trunc__, but as someone who runs such a project, I
have to say this is
Le jeu. 31 oct. 2019 à 11:41, Serhiy Storchaka a écrit :
> I propose to deprecate the falling back to __trunc__ for converting to
> int and remove it in future.
As Nick already said, I'm working on PEP 608 "Coordinated Python
release" which discuss such change:
On Sun., 3 Nov. 2019, 3:29 am Tal Einat, wrote:
> On Sat, Nov 2, 2019 at 1:54 PM Nick Coghlan wrote:
>
>>
>>
>> On Fri., 1 Nov. 2019, 8:10 am Guido van Rossum, wrote:
>>
>>> It seems a good idea to add __int__ to Fraction, but if you stop falling
>>> back to __trunc__, won't that cause
On Sat, Nov 2, 2019 at 1:54 PM Nick Coghlan wrote:
>
>
> On Fri., 1 Nov. 2019, 8:10 am Guido van Rossum, wrote:
>
>> It seems a good idea to add __int__ to Fraction, but if you stop falling
>> back to __trunc__, won't that cause backwards compatibility issues? I'd say
>> looking for __trunc__
01.11.19 00:03, Guido van Rossum пише:
It seems a good idea to add __int__ to Fraction, but if you stop falling
back to __trunc__, won't that cause backwards compatibility issues?
Most numeric types (int, float, Decimal, NumPy types) implement both
__trunc__ and __int__. The only known
On Fri., 1 Nov. 2019, 8:10 am Guido van Rossum, wrote:
> It seems a good idea to add __int__ to Fraction, but if you stop falling
> back to __trunc__, won't that cause backwards compatibility issues? I'd say
> looking for __trunc__ if the alternative is failing isn't so bad.
>
Aye, converting a
It seems a good idea to add __int__ to Fraction, but if you stop falling
back to __trunc__, won't that cause backwards compatibility issues? I'd say
looking for __trunc__ if the alternative is failing isn't so bad.
On Thu, Oct 31, 2019 at 3:43 AM Serhiy Storchaka
wrote:
> Currently __trunc__ is
