I think this particular mess was caused by the hiding of “DeprecationWarning”s by default: If you don’t see any warnings cropping up in your production code, you don’t know you have to fix something.

Some languages handle it like this:
  1. Silent deprecation warning (deprecated in docs and/or hidden like in Python, the most eagle-eyed maintainers will see it and fix it)
  2. Visible deprecation warning (people start seeing it and bug you in issues)
  3. Hide things behind a flag: You’ll have breakage but you get a grace perior by enabling some scary looking environment variable or so (nobody can deny that things are getting serious)
  4. Removal
Going from 1 to 4 is of course pretty harsh, and this is what we’re doing.

I propose that at least in the future, we have a schedule for every single deprecation to go to a gradual process like above.

Best, Phil

Am Fr., 31. Jan. 2020 um 05:21 Uhr schrieb Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp>:
Dima Tisnek writes:

 > I thought that collections compatibility was kept up to 3.8
 > specifically because py2 was alive.
 > No that that requirement is gone, so should the shim, right?

Python 2 is still very much alive (even in a Python 3 venv :-þ):

    (analysis.venv) 01 16:56$ /usr/bin/python
    Python 2.7.10 (default, Feb 22 2019, 21:55:15)
    [GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.37.14)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> ^D

We have stopped supporting Python 2 in the sense that we are no longer
going to release source updates to Python 2.  That doesn't necessarily
mean we don't consider the needs of users who continue to depend on
Python 2 for one reason or another, excellent or totally (in our
oh-so-ever-'umble opinion) mistaken though that reason may be.

 > Ofc., my assumption could be just wrong...

It might be, it might not be, it might be situation-dependent (ie,
decisions should be made case by case on a cost to Python core
developers versus benefits to Python 2 users and those who support
them in their libraries etc basis).

I think it would certainly be reasonable to make the decision that
we're going to go full speed ahead with Python 3 and start stripping
out Python 2-only features in the stdlib code.  I don't support that,
but I'm not a core developer, so that's a +1.0e-17 for keeping the
code.  I get the feeling that Guido is also not in favor of a
Procrustean[1] approach to Python 2 support in the Python 3 stdlib,
but I could be wrong.  Since he's not BDFL, that's merely indicative,
but IMO it's a pretty strong indicator.

What would really distress me however, is if we forget that we're not
supporting *code*, we're supporting *users* by creating and
maintaining code.  Of course we can choose that user base, and may
have to make painful decisions.  But this community is about people
supporting people, just like any community.

Footnotes:
[1]  Look up "Procrustes" in Wikipedia.  It's not a story to tell in
this family setting. ;-)
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/WX4LA55VR35LEAM46WWMQHS2T5DZOZII/
Code of Conduct: http://python.org/psf/codeofconduct/