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...@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-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/WX4LA55VR35LEAM46WWMQHS2T5DZOZII/ > 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/N5XWYZJEZRSMLG43BAL65YGLXDSVKS6C/ Code of Conduct: http://python.org/psf/codeofconduct/
