Peter Maydell <peter.mayd...@linaro.org> writes: > On Mon, 3 Jun 2019 at 19:21, John Snow <js...@redhat.com> wrote: >> I get it, we don't want to require Python 3.8 because some dev wanted >> assignment conditionals -- but we're talking about Python 2 here, which >> suffers its EOL by the end of this calendar year.
"Not because some dev wanted assignment conditionals" is the non-reason. Let me spell out the reason: supporting Python 2 is expensive for us. As the amount of Python code grows, it gets more and more expensive. Is this really time and effort well spent? >> So do we think it's reasonable to drop support for Python2 for the >> release that comes out after Python2's EOL, or do we insist on 2x3 >> simultaneous support for years more? > > I don't have a strong opinion on Python in particular, but > I think it would be nicer to avoid the "python is a special > snowflake" effect. Lots of things are nice. Limited resources dictate we can only get some of them. > Would it really be so bad for it to just > be "drop it when it falls off the last LTS distro" like the > rest of our dependencies ? In my experience maintaining and evolving the QAPI generators, supporting both Python 2 and 3 is a constant distraction that adds up over time. It's all manual; we decided against adopting one of tool chains made for dealing with this mess. I'd rather think about how to solve real user problems like deprecation information or command line introspection than deal with Python 2 vs. 3 arcana. Just the other day, I flagged an innocent-looking simplification of some non-QAPI Python code that changed semantics subtly on Python 2, impact unknown. The developer did not know. The fact that I waste precious brain capacity on knowing this shit (pardon my French) is a bloody shame. Well, some of this shit, because I've screwed it up myself, too. The sooner we stop the bleeding, the better.
