For what I can see, the majority of new users in an interactive environment seeing the warning will do so because the incorrect string will be in _their_ code. The benefits are immediate, as people change to either using raw-strings or using forward-slashes for file paths.
The examples in the beggining of this thread, where one changing a file path to "C:\users" sudden have broken code speaks for themselves: this is a _fix_ . Broken libraries will be fixed within weeks of a Py 3.8 release. People will either be using an old install, with Python 3.7, or they keep everything up to date, and for those after 2 months max, the library warnings will be all but gone. In the meantime, what is possible is to publicize more how to disable these warnings on end-users side, since we all agree that few people know how to that. On Wed, 7 Aug 2019 at 06:51, Chris Angelico <ros...@gmail.com> wrote: > On Wed, Aug 7, 2019 at 7:33 PM Steven D'Aprano <st...@pearwood.info> > wrote: > > What's the rush? Let's be objective here: what benefit are we going to > > get from this change? Is there anyone hanging out desperately for "\d" > > and "\-" to become SyntaxErrors, so they can... do what? > > So that problems can start to be detected. Time and again, Python > users on Windows get EXTREMELY confused by the way their code worked > perfectly with one path, then bizarrely fails with another. That is a > very real problem, and the problem is that it appeared to work when > actually it was wrong. > > Python has a history of fixing these problems. It used to be that > b"\x61\x62\x63\x64" was equal to u"abcd", but now Python sees these as > fundamentally different. Data-dependent bugs caused by a syntactic > oddity are a language flaw that needs to be fixed. > > > Because our processes don't work the way we assumed, it turns out that > > in practice we haven't given developers the deprecation period we > > thought we had. Read Nathaniel's post, if you haven't already done so: > > > > > https://mail.python.org/archives/list/python-dev@python.org/message/E7QCC74OBYEY3PVLNQG2ZAVRO653LD5K/ > > > > He makes a compelling case that while we might have had the promised > > deprecation period by the letter of the law, in practice most developers > > will have never seen it, and we will be breaking the spirit of the > > promise if we continue with the unmodified plan. > > Yes, that's a fair complaint. But merely pushing the deprecation back > by a version is not solving it. There has to be SOMETHING done > differently. > > > And yet here we are rushing through a breaking change in an accelerated > > manner, for a change of marginal benefit. > > It's not a marginal benefit. For people who try to teach Python on > multiple operating systems, this is a very very real benefit. Just > because YOU don't see the benefit doesn't mean it isn't there. > > > > Otherwise, all you're doing is saying "I wish this > > > problem would just go away". > > > > No, I'm saying we don't have to rush this into 3.8. Let's keep the > > warning silent and push everything back a release. > > > > Now is better than never. > > Although never is often better than *right* now. > > Not sure how the Zen supports what you're saying there, since you're > specifically saying "not never, not now, just later". But what do you > actually mean by not rushing this into 3.8? > > > Right now, we're looking at a seriously compromised user-experience for > > 3.8. People are going to hate these warnings, many of them won't know > > what to do with them and will be sure that Python is buggy, and for very > > little benefit. > > Then the problem is that people blame Python for these warnings. That > is a problem to be solved; we need people to understand that a warning > emitted by a library is a *library bug* not a language flaw. > > > > Library authors can start _right now_ fixing their code so it's more > > > 3.8 compatible. > > > > Provided that (1) they are aware that this is a problem that needs to be > > fixed, and (2) they have the round tuits to actually fix it by 3.8.0. > > Neither are guaranteed. > > (1) Yes it is, see above; (2) fair point, but this is restricted to > string literals and can be detected simply by compiling the code, so > it's a reasonably findable problem. > > > > ("More" because 3.8 doesn't actually break anything.) > > > What is actually gained by waiting longer > > > > We gain the avoidance of a painful experience in 3.8 for a significant > > number of users and third-party devs. > > > > The question we haven't had answered is what we gain by pushing through > > with the original plan. Plenty of people have said "Let's just do it" > > but as far as I can see not one has explained *why* we should put end- > > users and library developers through this frustrating and annoying > > rushed deprecation period. > > And unless you have a plan to do something different in 3.8 that > ensures that library devs see the warnings, there's no justification > for the delay. All you'll do is defer the exact same problem by > another eighteen months. If the warning remains silent in 3.8, how > will library devs get any indication that they need to fix something? > > If you can offer a better plan, then by all means, do so. But > deferring without a change is of no real value, and it means ANOTHER > eighteen months added onto the time before novice programmers get to > be told about string literal problems. > > ChrisA > _______________________________________________ > 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/RISO4KSTHBMQZJT5XFS34GCB2PB66WNV/ >
_______________________________________________ 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/3OFD5DGO4ZOL3PC6RS3643QD3KDRP4PE/
