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 <rosuav@gmail.com> wrote:
On Wed, Aug 7, 2019 at 7:33 PM Steven D'Aprano <steve@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-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/RISO4KSTHBMQZJT5XFS34GCB2PB66WNV/