On Fri, Aug 09, 2019 at 02:28:13PM -0400, Jonathan Goble wrote: > I am perplexed at the opinion, seemingly espoused by multiple people > in this thread, that because a major part of the problem is that the > warnings were not visible enough, somehow the proposed solution is > making them not visible enough again?
Making the warnings invisible by default is only the first step, not the entire solution. We don't break backwards compatibility lightly, and the current behaviour is not an accident, it is a documented feature which developers are entitled to rely on. We are chosing to change that behaviour, breaking backwards compatibility, to the inconvenience of end-users, library authors, and developers on Mac/Unix/Linux, for two benefits: 1. To possibly allow the addition of new escape sequences such as \e some time in the future. 2. To strongly discourage newbie Windows developers from hard-coding paths using backslashes, but to use forward slashes instead. Especially on Python-Ideas, time and time again we hear the mantra that we should only break backwards compatibility if the benefit strongly outweighs the cost of change. Raymond has given compelling (to me at least) testimony that right now, the cost of change is far too high for the two minor benefits gained. So *right now*, it looks like we ought to be prepared to back away from the change altogether. We thought that the balance would be: "it will be a little bit painful, but the benefit will outweigh the pain" justifying breaking backwards compatibility, but we have found that the pain is greater than expected. If we cannot reduce the pain, and move the balance into the "nett positive" rather than the "nett negative" we have right now, we ought to cancel the deprecation. Making the deprecation silent by default will reduce the pain. That's the first step. Pushing the deprecation schedule back a release or more will give us time to rethink the deprecation process, fix the technical issues we discovered about SyntaxWarnings, and give library authors time to eliminate the warnings from their libraries. > It's too late, in my > understanding, in the 3.8 cycle to add a new feature like a change to > how these warnings are produced (it seems a significant change to the > .pyc structure is needed to emit them at runtime), so this supposed > "solution" is nothing but kicking the can down the road. Is that a problem? Any deadline we have to make unrecognised backslash escapes an error is a self-imposed deadline. We lived with this feature for more than a quarter of a century, we can keep kicking the can down the road until the benefit outweighs the pain. If that means "forever", then I personally will be sad, but so be it. However, even if it is too late to add any new tools or features to Python 3.8 (and that's not clear: this won't be a *language* change, so the feature freeze may not apply) all is not lost. We're aware of the problem, and can start pointing library authors at this thread, and the relevent b.p.o. ticket, and push them in the right direction. Raymond mentioned two libraries by name, bottle and docutils, and Matt scanned the top 100 packages on PyPI. That's a good place to start for anyone wanting to contribute: raise bug reports on the individual library trackers. (If they haven't already been raised.) https://github.com/bottlepy/bottle/issues (I'd do that myself except I have technical problems using Github.) I have reported it to docutils: https://sourceforge.net/p/docutils/bugs/373/ [...] > So put these warnings front and center now > so package and code maintainers actually see it The problem is that this seriously and negatively affects the experience for many end-users. That's what we're trying to prevent, or at least mitigate. -- Steven _______________________________________________ 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/B7FH5IGUX24J7X7QEANAOSTIKTOHZJ5E/
