[python-committers] Re: PEP 563 and Python 3.10.

2021-04-21 Thread M.-A. Lemburg
On 21.04.2021 13:35, Paul Moore wrote: > On Wed, 21 Apr 2021 at 12:24, M.-A. Lemburg wrote: >> >> Isn't that an educational problem ? Adjusting reporting of >> warnings isn't all that hard: >> >> https://docs.python.org/3/library/warnings.html#the-warnings-filter >> >> Perhaps it's just a usabilit

[python-committers] DeprecationWarning silent by default

2021-04-21 Thread Antoine Pitrou
Le 21/04/2021 à 13:34, Victor Stinner a écrit : On Wed, Apr 21, 2021 at 1:24 PM M.-A. Lemburg wrote: Isn't that an educational problem ? Adjusting reporting of warnings isn't all that hard: A common practical problem is a project CI which pulls the most recent verisons of 3rd party dependenc

[python-committers] Re: PEP 563 and Python 3.10.

2021-04-21 Thread Paul Moore
On Wed, 21 Apr 2021 at 12:24, M.-A. Lemburg wrote: > > Isn't that an educational problem ? Adjusting reporting of > warnings isn't all that hard: > > https://docs.python.org/3/library/warnings.html#the-warnings-filter > > Perhaps it's just a usability issue. We could have venvs help > us a bit wit

[python-committers] Re: PEP 563 and Python 3.10.

2021-04-21 Thread Victor Stinner
On Wed, Apr 21, 2021 at 1:24 PM M.-A. Lemburg wrote: > Isn't that an educational problem ? Adjusting reporting of > warnings isn't all that hard: A common practical problem is a project CI which pulls the most recent verisons of 3rd party dependencies and suddenly break if a new deprecation warni

[python-committers] Re: PEP 563 and Python 3.10.

2021-04-21 Thread Victor Stinner
Hi, In this case, we need more advanced warnings filters to only show deprecation warnings in the "current application code", and ignore deprecation warnings from any other module. Is there a way to create an entry point in setuptools which says "this application uses the package xxx"? Since ther

[python-committers] Re: PEP 563 and Python 3.10.

2021-04-21 Thread Anthony Baxter
While I have not been involved in the release process for like 15 years or more, I would like to point out that breaking changes mean the distros are less likely to ship them, and be less likely to trust updates. Trying to get RH &c to stop shipping 1.5.2 was a huge effort. Always, any time when

[python-committers] Re: PEP 563 and Python 3.10.

2021-04-21 Thread M.-A. Lemburg
On 21.04.2021 13:14, Paul Moore wrote: > On Wed, 21 Apr 2021 at 12:05, M.-A. Lemburg wrote: > >> Perhaps we should reconsider making deprecation warnings only >> visible by explicitly enabling them and instead make them visible >> by default. >> >> This would create more noise for users, but for

[python-committers] Re: PEP 563 and Python 3.10.

2021-04-21 Thread Paul Moore
On Wed, 21 Apr 2021 at 12:05, M.-A. Lemburg wrote: > Perhaps we should reconsider making deprecation warnings only > visible by explicitly enabling them and instead make them visible > by default. > > This would create more noise for users, but for the better, since > planned changes then become

[python-committers] Re: PEP 563 and Python 3.10.

2021-04-21 Thread M.-A. Lemburg
On 21.04.2021 12:16, Thomas Wouters wrote: > The idea that we should warn before significant changes to behaviour -- > documented behaviour, like function annotations being evaluated at definition > time, or behaviour commonly depended on, like 'with' being allowed as an > identifier because it was

[python-committers] Re: PEP 563 and Python 3.10.

2021-04-21 Thread Thomas Wouters
(For the record, I'm not responding for the whole SC here.) On Wed, Apr 21, 2021 at 12:08 AM Terry Reedy wrote: > On 4/20/2021 2:57 PM, Thomas Wouters wrote: > > > - PEP 563 provides no warning to users of the feature it’s disabling. > > Removals or major changes to callables usually get depre