> 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 exactly the point. I always have the option of adding a given warning to my ignore list (as long as it's raised in such a way that this is easy to do), and I want the hard error so I can heed the warnings.

Avoiding raising warnings because too many test suites break when using -Werror seems counterproductive.

Of course, "lots of stuff breaks with -Werror" could be a proxy for "it would be a lot of work to fix this", and maybe all that work isn't worth it for whatever improvement you'd get from the fixes, but I think it would be better to try and evaluate it on those terms rather than considering broken test suites an inherently bad thing.


On November 5, 2019 1:06:42 AM UTC, Victor Stinner <vstinner@python.org> wrote:
Le jeu. 31 oct. 2019 à 11:41, Serhiy Storchaka <storchaka@gmail.com> 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:
https://www.python.org/dev/peps/pep-0608/

It's discussed at:
https://discuss.python.org/t/rfc-pep-608-coordinated-python-release/2539

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'm looking for help to build a tool to test popular PyPI projects on
a modified Python version, to be able to answer to such questions.

My current experimental project can only test numpy, coverage and
jinja2, and it doesn't work well (especially on Python 3.9):
https://github.com/vstinner/pythonci/

Since this tool doesn't exist yet and since we cannot test all PyPI
projects, I suggest to keep the option of reverting such change if we
consider that it breaks too many projects during the Python 3.9 beta
phase.

Victor