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
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
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
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
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
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
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
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
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
(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
10 matches
Mail list logo