On Wed, Aug 07, 2019 at 10:14:08AM +1000, Chris Angelico wrote:
On Wed, Aug 7, 2019 at 10:03 AM Steven D'Aprano <steve@pearwood.info> wrote:
- Keep the SyntaxWarning silent by default for 3.8. That gives us another year or more to gently pressure third-party libraries to fix their code, and to find ways to encourage developers to run with warnings enabled.
How do you propose to apply this pressure?
We already have some good information about the offending libraries. (Remember, the libraries here haven't done anything wrong. They were using a documented feature. We've just changed our mind about that feature.) Raymond mentioned two, docutils and bottle, and Matt did a scan of the top 100 downloads on PyPI. We can start by reporting this as a bug to them.
How about: whenever a third-party library uses a potentially-wrong escape sequence, it creates a message on the console. Then when someone sees that message, they can post a bug report against the package.
You're right, of course, and if we were talking about one or two warnings a week, affecting a handful of users, I don't think Raymond would have said anything. But apparently this is a widespread problem with common third party libraries. That means its going to affect lots of people. We have a few problems: - The people affected will mostly be the end users, not the developers. - These sorts of SyntaxWarnings are scary and intimdating to beginners, even when they are harmless. Many of them will not know how to silence warnings, or who to report it as a bug to. - Since end users rarely search for existing bug reports before adding a new one, or upgrade to the latest version, we're effectively sentencing the third-party library authors to be flooded with potentially dozens of identical bug reports long after they have fixed the issue. - I expect that many end users will report it as a *Python* bug, so we're going to share some of that pain too. - The benefit of the desired change is relatively low. The intention was for the developers, not end users, to see the warning. If end users see more than a tiny number of these warnings, our plan failed. That's okay: since the benefit of the breaking change is small, we can rethink the plan, delay the breaking change, and try to come up with a better system that ensures developers see these warnings before their users do. We're not fixing a major security issue here, or adding a new feature that will make people's code enormously better. We're breaking people's code to force them to write "better" code, so that *maybe* some day in the future we can add new escape sequences. That's a really small benefit for breaking backwards compatibility. We don't break backwards compatibility lightly because of the knock on effects of code churn, libraries that stop working, frustrated users, obsoleted blog posts and books, questions asked on Stackoverflow etc. When the benefit is small, we require the pain to be correspondingly small. That's not going to be the case if we continue with the plan. Don't think of this as a failure. Think of it as an opportunity: we've identified a weakness in our deprecation process. Let's fix that process, make sure that *developers* will see the warning in 3.8 or 3.9, and not raise an exception until 4.0 or 4.1. I know people just want to get it over and done with, I do too. But we have responsibilities to the community, and we've lived with the current behaviour for 25+ years, another 2-3 years won't kill us. -- Steven