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