[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Stephen J. Turnbull]

Steven D'Aprano writes:

 > Or maybe, as a developer (not an end-user of an app), you could be more 
 > proactive in reporting those warnings to the third party, and 
 > encouraging them to fix them. Maybe even submitting a patch?

As Chris B points out, it's quite possible that (generic) you have
already reported, and maybe even submitted that patch, but you still
have to wait for the release.  Thing about submitting such patches --
I can't speak for Python programs, but in XEmacs I probably refused
more warning-suppression patches than I accepted, because there was a
deeper problem that needed to be fixed and the annoying warning was
merely a side effect.  And for any project, even if you submit a
patch, there's no guarantee that the next version (or three) will
contain it, which means vendoring the source.  Urk!

 > Of course I understand that folks are busy maintaining their own
 > project, and have neither the time nor the inclination to take over
 > the maintenance of every one of their dependencies. But we
 > shouldn't just dismiss warnings in those dependencies as "warnings
 > I don't care about" and ignore them as Not My Problem.

Sure, but it's still worth providing various kinds of automation.  For
example, it would be nice if downstream (us) could fire and forget
reports of DeprecationWarnings, knowing that bug reporting systems
would automatically identify and merge them.  And for
DeprecationWarnings, rather than patching, it would be usually be nice
to suppress the warning, I think.

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7MY34PHQVOWGRCHUJ7MSMTPSP544MTV6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Christopher Barker]

On Thu, Jan 27, 2022 at 10:47 AM Steven D'Aprano 
wrote:

> > >Getting the right people to pay attention to them is always the hard
> part.
>
> Or maybe, as a developer (not an end-user of an app), you could be more
> proactive in reporting those warnings to the third party, and
> encouraging them to fix them. Maybe even submitting a patch?
>

Personally, I do exactly that -- but more often than not (thankfully) the
upstream project is already working on it, or already fixed it, but in a
version that I can't use yet. So then I really want to silence those
warnings. Which is pretty easy to do with pytest, but maybe not so easy
everywhere?


>  But we shouldn't just
> dismiss warnings in those dependencies as "warnings I don't care about"
> and ignore them as Not My Problem.
>

Unless we have done due diligence already :-)

-CHB


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YUWICC2Q274FBOZF5BX2N3BYEO7MHMQH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Steven D'Aprano]

On Wed, Jan 26, 2022 at 02:40:32PM -0800, Neil Schemenauer wrote:
> On 2022-01-18 23:14, Gregory P. Smith wrote:
> >
> >Our stdlib unittest already enables warnings by default per 
> >https://bugs.python.org/issue10535.
> >
> >Getting the right people to pay attention to them is always the hard part.
> 
> I wonder if we can do a bit better in that regard.  When I install 3rd 
> party packages, I create a usercustomize.py file that uses 
> filterwarnings() to turn off all the warnings I don't care about.  I 
> don't know how but maybe we could make that easier to do.  That way, you 
> don't get buried in warnings coming from code you don't maintain.

Or maybe, as a developer (not an end-user of an app), you could be more 
proactive in reporting those warnings to the third party, and 
encouraging them to fix them. Maybe even submitting a patch?

If we use a library, then we surely care about that library working 
correctly, which means that if the library generates warnings, we 
*should* care about them. They are advanced notice that the library is 
going to break in the future.

Of course I understand that folks are busy maintaining their own 
project, and have neither the time nor the inclination to take over the 
maintenance of every one of their dependencies. But we shouldn't just 
dismiss warnings in those dependencies as "warnings I don't care about" 
and ignore them as Not My Problem.

Like it or not, it is My Problem and we should care about them.

Especially in the case of open source software, the lines of 
responsibility are blurred. Open source libraries are not proprietary 
black boxes with a strict division between the vender that supplies the 
library and the people who use the library. They are fully transparent, 
we can see the warnings and, at least potentially, see how to fix them. 
And we have the legal right to.

This is a hard problem, but it is not solely a technical problem. It is 
partly a social problem, and you cannot fix social problems with 
technology. People are ignoring the warnings, and not just the immediate 
developers of the software, but their downstream users.

The open source mantra about many eyes making bugs shallow doesn't work 
when everyone is intentionally closing their eyes to the warnings of 
pending bugs.



-- 
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BCEKHDT76GGG2E65DCCIX4DC6OL5CIW4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Christopher Barker]

On Wed, Jan 26, 2022 at 12:50 PM Neil Schemenauer 
wrote:

> maybe we should be more aggressive about showing PendingDeprecationWarning
> if it comes from code that seems to be written by the user, e.g. outside
> site-packages
>
> That would be pretty straightforward.

> or not from a package installed by pip.  The exact logic of that is
> complicated though.
>
> or impossible, I always use pip install -e on teh code I'm developing
(though that could be detected, I presume), and if I have more than one of
my own packages, then they are piip installed.

Ido think we could work harder on documenting how to selectively disable
warnings though.

-CHB




___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/HB4ZSI5UWSI3R3ASTIOCAYNU7YPBB57F/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HDAOJ5A6GERC33NOJNINITQFL6U52XDP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Neil Schemenauer]

On 2022-01-18 23:14, Gregory P. Smith wrote:
Our stdlib unittest already enables warnings by default per 
https://bugs.python.org/issue10535.


Getting the right people to pay attention to them is always the hard part.


I wonder if we can do a bit better in that regard.  When I install 3rd 
party packages, I create a usercustomize.py file that uses 
filterwarnings() to turn off all the warnings I don't care about.  I 
don't know how but maybe we could make that easier to do.  That way, you 
don't get buried in warnings coming from code you don't maintain.


Additionally, maybe we should be more aggressive about showing 
PendingDeprecationWarning if it comes from code that seems to be written 
by the user, e.g. outside site-packages or not from a package installed 
by pip.  The exact logic of that is complicated though.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HB4ZSI5UWSI3R3ASTIOCAYNU7YPBB57F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Victor Stinner]

On Wed, Jan 19, 2022 at 11:58 AM Sebastian Rittau  wrote:
>
> Am 18.01.22 um 22:57 schrieb Victor Stinner:
> > At the end of my first email, I also suggest thinking about
> > incompatible changes differently, try to make affected projects
> > compatible in advance. The problem are not the changes themselves, but
> > how they are introduced in Python, and more globally how they are
> > introduced "in the Python ecosystem" (!).
> >
> I believe that some (semi-) automated way to actively test and notify
> important projects of deprecations/removals before a release would be a
> great addition to the Python ecosystem. This is a complicated issue, but
> well worth it. (I'm not volunteering. :) )

In practice, it is the work that we are doing on Fedora, but for
changes already merged in Python.

Once, I wrote a small project https://github.com/vstinner/pythonci to
test a few projects on a modified Python (with a patch applied), but
it's really hard to automate the creation of the environment to test a
project.

It's hard to download and install dependencies in a reproducible way,
especially for "non-Python" dependencies (Linux packages).

Fedora already has recipes for that: RPM packages with "build
dependencies", commands to download the code, apply patches if needed,
run the test suite, etc.

With my project, quickly, I had to patch pip, setuptools, etc. For
example, to fix ResourceWarning or a DeprecationWarning (remember
collections.MutableMapping removal? html5lib has to be patched
manually, the vendored copy inside pip!). Maintaining patches on
multiple projects is not easy.

Well, if someone wants to help me on the pythonci project, you're
welcome ;-) I'm interested to investigate different approaches to have
simpler and more reliable "recipes".

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EWS4TZTHBNAGH6N5SUXRPCGW7CUL5SB7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Sebastian Rittau]

Am 18.01.22 um 22:57 schrieb Victor Stinner:

At the end of my first email, I also suggest thinking about
incompatible changes differently, try to make affected projects
compatible in advance. The problem are not the changes themselves, but
how they are introduced in Python, and more globally how they are
introduced "in the Python ecosystem" (!).

I believe that some (semi-) automated way to actively test and notify 
important projects of deprecations/removals before a release would be a 
great addition to the Python ecosystem. This is a complicated issue, but 
well worth it. (I'm not volunteering. :) )


 - Sebastian

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4QVAHO4U5QC44QWMJNCONNNE5HVDQPX3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Gregory P. Smith]

On Tue, Jan 18, 2022 at 6:24 AM Victor Stinner  wrote:

> Hi,
>
> My colleagues Tomáš Hrnčiar and Miro Hrončok made good progress on
> updating Python 3.10 to Python 3.11 in Fedora, but some specific
> Python 3.11 incompatible changes are causing more troubles than
> others:
> https://discuss.python.org/t/experience-with-python-3-11-in-fedora/12911
>
> We propose to revert the following 2 changes in Python 3.11 and
> postpone them in a later Python version, once most projects will be
> compatible with these changes:
>
> * Removal of unittest aliases (bpo-45162): it broke 61 Fedora packages
> * Removals from configparser module (bpo-45173) - broke 28 Fedora packages
>
> --
>
> We reported the issue to many affected projects, or when possible, we
> also wrote a pull request to make the code compatible (lot of those
> were made by others, e.g. Hugo van Kemenade, thank you!).
>

+1 to rolling both of these back for 3.11.  Deprecation removals are hard.
Surfacing these to the impacted upstream projects to provide time for those
to integrate the changes is the right way to make these changes stick in
3.12 or later.  Thanks for doing a significant chunk of that work!

As you've done the work to clean up a lot of other OSS projects, I suggest
we defer this until 3.12 with the intent that we won't defer it again. That
doesn't mean we can't hold off on it, just that we believe pushing for this
now and proactively pushing for a bunch of cleanups has improved the state
of the world such that the future is brighter.  That's a much different
strategy than our passive aggressive DeprecationWarnings.

-gps


>
> The problem is that fixing a Fedora package requires multiple steps:
>
> * (1) Propose a pull request upstream
> * (2) Get the pull request merged upstream
> * (3) Wait for a new release upstream
> * (4) Update the Fedora package downstream, or backport the change in
> Fedora (only needed by Fedora)
>
> Identifying the Python incompatible changes causing most troubles took
> us a lot of time, but we did this work. Reverting the two Python 3.11
> incompatible changes (causing most troubles) will save us "bug triage"
> time, to get more time on updating projects to Python 3.11 for the
> other remaining incompatible changes.
>
> We are not saying that these incompatible changes are bad, it's just a
> matter of getting most projects ready before Python 3.11 final will be
> released.
>
> --
>
> By the way, before making a change known to be incompatible, it would
> be nice to run a code search on PyPI top 5000 projects to estimate how
> many projects will be broken, and try to update these projects
> *before* making the change.
>
> For example, only introduce an incompatible change into Python once
> less than 15 projects are affected. Getting a pull request merged is
> nice, but a release including the fix is way better for practical
> reasons: people use "pip install ".
>
> --
>
> Fedora work on Python 3.11 is public and tracked at:
> https://bugzilla.redhat.com/show_bug.cgi?id=PYTHON3.11
>
> Click on "depends on" to see current issues:
>
> https://bugzilla.redhat.com/buglist.cgi?bug_id=2016048_id_type=anddependson=tvp
>
> Example of bz #2025600: mom fails to build with Python 3.11:
> AttributeError: module 'configparser' has no attribute
> 'SafeConfigParser'.
>
>
> Victor Stinner -- in the name of the Python Red Hat / Fedora maintenance
> team
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/GJTREADEXYAETECE5JDTPYWK4WMTKYGR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3J3VKNTKGPWACFVDWPRCS7FNED2A34R4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Gregory P. Smith]

On Tue, Jan 18, 2022 at 10:58 PM Christopher Barker 
wrote:

> On Tue, Jan 18, 2022 at 10:30 AM Brett Cannon  wrote:
>
>>  I remember that "noisy by default" deprecation warnings were widely
>>> despised.
>>>
>>> One thought, what if they were off by default UNLESS you were doing unit
>>> tests?
>>>
>>
>> I believe pytest already does this.
>>
>
> Indeed it does, at least in recent versions (1-2 yrs ago?)
>
> And even that is pretty darn annoying. It's really helpful for my code,
> but they often get lost in the noise of all the ones I get from upstream
> packages.
>
> I suppose I need to take the time to figure out how to silence the ones I
> don't want.
>
> And it does prompt me to make sure that the upstream packages are working
> on it.
>
> Now we just need to get more people to use pytest :-)
>

Our stdlib unittest already enables warnings by default per
https://bugs.python.org/issue10535.

Getting the right people to pay attention to them is always the hard part.


>
> -CHB
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/LZAF3TOOIAAFXXK2KPAXA5V5SRBOSIIP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5YOEMAIVXMVWCORAY54LZQO62755HQGX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Christopher Barker]

On Tue, Jan 18, 2022 at 10:30 AM Brett Cannon  wrote:

>  I remember that "noisy by default" deprecation warnings were widely
>> despised.
>>
>> One thought, what if they were off by default UNLESS you were doing unit
>> tests?
>>
>
> I believe pytest already does this.
>

Indeed it does, at least in recent versions (1-2 yrs ago?)

And even that is pretty darn annoying. It's really helpful for my code, but
they often get lost in the noise of all the ones I get from upstream
packages.

I suppose I need to take the time to figure out how to silence the ones I
don't want.

And it does prompt me to make sure that the upstream packages are working
on it.

Now we just need to get more people to use pytest :-)

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LZAF3TOOIAAFXXK2KPAXA5V5SRBOSIIP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Victor Stinner]

On Tue, Jan 18, 2022 at 5:48 PM Steve Dower  wrote:
> Discovering during alpha that some packages haven't updated for the
> release that hasn't happened yet isn't the end of the world. Reverting
> the changes now is probably a bit premature - realistically we can undo
> these anytime during beta if we discover that packages are unable to be
> fixed over the next 9 months.

In Fedora, if a frequently used dependency is broken, a long list of
packages "fail to build". (In Fedora, the package test suite must pass
to build a package successfully.) If it takes 9 months to fix this
dependency, we will likely miss other issues before the Python final
version in dependent packages. The problem is when the issue is on the
Python side.

For example, we discovered that cloudpickle didn't work on Python
3.10. In fact, it was a Python regression. I had to modify how the
function object constructor inherits globals (bpo-42990). This kind of
change is fine during the beta phase, but it's bad to change the
Python behavior in a bugfix Python 3.10.x release :-(

Another example is when Cython was ported to Python 3.8, a
PyCode_New() change caused a lot of troubles. After multiple exchanges
between Cython and Python and a few more issues, it was decided to
*revert* the PyCode_New() change. I would not be possible to revert
the change in Python 3.8.1 or later :-(

There are many examples like that, I don't have an exhaustive list. If
issues are discovered earlier, we get more time to discuss and design
how to handle them.

I don't know where is the good trade-off here. That's why I'm opening
a discussion. Yes obviously, we can revert these 2 changes later. Or
we can just keep them ;-)

--

At the end of my first email, I also suggest thinking about
incompatible changes differently, try to make affected projects
compatible in advance. The problem are not the changes themselves, but
how they are introduced in Python, and more globally how they are
introduced "in the Python ecosystem" (!).

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DI7FCMTSL2MGIZAAJ6I7QRJYTQQQ37VP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Brett Cannon]

On Tue, Jan 18, 2022 at 9:43 AM Richard Damon 
wrote:

>
>
> On Jan 18, 2022, at 11:34 AM, Guido van Rossum  wrote:
>
> 
> At best it shows that deprecations are complicated no matter how well you
> plan them. I remember that "noisy by default" deprecation warnings were
> widely despised.
>
> On Tue, Jan 18, 2022 at 6:49 AM Antoine Pitrou  wrote:
>
>> On Tue, 18 Jan 2022 15:17:41 +0100
>> Victor Stinner  wrote:
>> > Hi,
>> >
>> > My colleagues Tomáš Hrnčiar and Miro Hrončok made good progress on
>> > updating Python 3.10 to Python 3.11 in Fedora, but some specific
>> > Python 3.11 incompatible changes are causing more troubles than
>> > others:
>> >
>> https://discuss.python.org/t/experience-with-python-3-11-in-fedora/12911
>> >
>> > We propose to revert the following 2 changes in Python 3.11 and
>> > postpone them in a later Python version, once most projects will be
>> > compatible with these changes:
>> >
>> > * Removal of unittest aliases (bpo-45162): it broke 61 Fedora packages
>> > * Removals from configparser module (bpo-45173) - broke 28 Fedora
>> packages
>>
>> Doesn't this show, once again, that making DeprecationWarning silent by
>> default was a mistake?
>>
>>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)
> *
>
>
> One thought, what if they were off by default UNLESS you were doing unit
> tests?
>

I believe pytest already does this.

-Brett


>
> That would cut out a lot of the excessive noise issue, but put them in
> before the programmer when they are developing. Yes, they will get the
> warnings for dependencies but that lets the programmer apply pressure to
> fix it or warning they may need to change something if it won’t get fixed.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/UAHZKJNQTMXDORVGX5U5EHKI4HQAV7BN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BSGVVVO2DLPUZPU37ETVYYZLNNL3VEF4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Richard Damon]

> On Jan 18, 2022, at 11:34 AM, Guido van Rossum  wrote:
> 
> 
> At best it shows that deprecations are complicated no matter how well you 
> plan them. I remember that "noisy by default" deprecation warnings were 
> widely despised.
> 
>> On Tue, Jan 18, 2022 at 6:49 AM Antoine Pitrou  wrote:
>> On Tue, 18 Jan 2022 15:17:41 +0100
>> Victor Stinner  wrote:
>> > Hi,
>> > 
>> > My colleagues Tomáš Hrnčiar and Miro Hrončok made good progress on
>> > updating Python 3.10 to Python 3.11 in Fedora, but some specific
>> > Python 3.11 incompatible changes are causing more troubles than
>> > others:
>> > https://discuss.python.org/t/experience-with-python-3-11-in-fedora/12911
>> > 
>> > We propose to revert the following 2 changes in Python 3.11 and
>> > postpone them in a later Python version, once most projects will be
>> > compatible with these changes:
>> > 
>> > * Removal of unittest aliases (bpo-45162): it broke 61 Fedora packages
>> > * Removals from configparser module (bpo-45173) - broke 28 Fedora packages
>> 
>> Doesn't this show, once again, that making DeprecationWarning silent by
>> default was a mistake?
>> 
> 
> -- 
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)

One thought, what if they were off by default UNLESS you were doing unit tests?

That would cut out a lot of the excessive noise issue, but put them in before 
the programmer when they are developing. Yes, they will get the warnings for 
dependencies but that lets the programmer apply pressure to fix it or warning 
they may need to change something if it won’t get fixed.___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UAHZKJNQTMXDORVGX5U5EHKI4HQAV7BN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Steve Dower]

On 1/18/2022 2:44 PM, Antoine Pitrou wrote:

We propose to revert the following 2 changes in Python 3.11 and
postpone them in a later Python version, once most projects will be
compatible with these changes:

* Removal of unittest aliases (bpo-45162): it broke 61 Fedora packages
* Removals from configparser module (bpo-45173) - broke 28 Fedora packages


Doesn't this show, once again, that making DeprecationWarning silent by
default was a mistake?


That's a hypothesis, but we don't have enough information to prove it. 
If we'd gone the other way, perhaps we'd be looking at massive 
complaints from "regular" end users about all the noisy warnings that 
they can't fix and saying that making it noisy was the mistake.


Discovering during alpha that some packages haven't updated for the 
release that hasn't happened yet isn't the end of the world. Reverting 
the changes now is probably a bit premature - realistically we can undo 
these anytime during beta if we discover that packages are unable to be 
fixed over the next 9 months.


That said, I'm fine with reverting the changes on the basis that they 
cause churn for no real benefit. If someone wants to argue that the 
benefit is worthwhile, that's fine, as long as they also argue in favour 
of the churn.


We shouldn't pretend to be surprised that something we changed causes 
others to have to change. We *know* that will happen. Either we push 
forward with the changes, or we admit we don't really need them. With 
this amount of time before the release, we can't blame downstream users 
for reverting it.


Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PGR4WUPMVGF67IWX2O7EKA2NSHFYEX5P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Guido van Rossum]

At best it shows that deprecations are complicated no matter how well you
plan them. I remember that "noisy by default" deprecation warnings were
widely despised.

On Tue, Jan 18, 2022 at 6:49 AM Antoine Pitrou  wrote:

> On Tue, 18 Jan 2022 15:17:41 +0100
> Victor Stinner  wrote:
> > Hi,
> >
> > My colleagues Tomáš Hrnčiar and Miro Hrončok made good progress on
> > updating Python 3.10 to Python 3.11 in Fedora, but some specific
> > Python 3.11 incompatible changes are causing more troubles than
> > others:
> > https://discuss.python.org/t/experience-with-python-3-11-in-fedora/12911
> >
> > We propose to revert the following 2 changes in Python 3.11 and
> > postpone them in a later Python version, once most projects will be
> > compatible with these changes:
> >
> > * Removal of unittest aliases (bpo-45162): it broke 61 Fedora packages
> > * Removals from configparser module (bpo-45173) - broke 28 Fedora
> packages
>
> Doesn't this show, once again, that making DeprecationWarning silent by
> default was a mistake?
>
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/AQHDYW4RBXV7U5YDZVHE2I2BWEZAC6PB/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ISKNUHFT4W2GKUEIOL5HQTXBMJVQXK2M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Antoine Pitrou]

On Tue, 18 Jan 2022 15:17:41 +0100
Victor Stinner  wrote:
> Hi,
> 
> My colleagues Tomáš Hrnčiar and Miro Hrončok made good progress on
> updating Python 3.10 to Python 3.11 in Fedora, but some specific
> Python 3.11 incompatible changes are causing more troubles than
> others:
> https://discuss.python.org/t/experience-with-python-3-11-in-fedora/12911
> 
> We propose to revert the following 2 changes in Python 3.11 and
> postpone them in a later Python version, once most projects will be
> compatible with these changes:
> 
> * Removal of unittest aliases (bpo-45162): it broke 61 Fedora packages
> * Removals from configparser module (bpo-45173) - broke 28 Fedora packages

Doesn't this show, once again, that making DeprecationWarning silent by
default was a mistake?



___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AQHDYW4RBXV7U5YDZVHE2I2BWEZAC6PB/
Code of Conduct: http://python.org/psf/codeofconduct/