On Wed, Aug 07, 2019 at 02:33:51PM +1000, Chris Angelico wrote:
On Wed, Aug 7, 2019 at 1:54 PM Steven D'Aprano <steve@pearwood.info> wrote:
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.
So HOW are you going to make sure developers see it?
I've only just started thinking about it, give me a couple of minutes! *wink* 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? 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/E7QCC74O... 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. Quite frankly, if we continue with the unmodified plan, third-party devs who are affected will have the right to feel mightly pissed off at us. We make an implicit, if not explicit, promise that we won't break backswards compatibility lightly, but if we do, we will give them plenty of notice except under the most dire circumstances (such as a serious security vulnerability). And yet here we are rushing through a breaking change in an accelerated manner, for a change of marginal benefit. Sure, we can say that *technically* we gave them all the notice promised, it was at the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of The Leopard". https://www.goodreads.com/quotes/40705-but-the-plans-were-on-display-on-disp... I'm sure that the affected devs will understand why it was *their* fault they couldn't see the warnings, when even people from a first-class library like SymPy took four iterations to do it right.
Currently it requires some extra steps or flags, which are not well known. What change are you proposing for 3.8 that will ensure that this actually gets solved?
Absolutely nothing. I don't have to: we're an entire community, this doesn't have to fall only on my shoulders. I'm not even the messenger: that's Raymond. I'm just (partly) agreeing with him. Just because I don't have a solution for this problem doesn't mean the problem doesn't exist.
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. 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. Let's slow down and put it off for another release, giving us time to solve the warnings problem, and library authors the deprecation period promised.
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. Its not a big fix, but people have other priorities, like work, family, a life, etc. That's why we normally give developers *multiple years* of warnings to fix problems, not weeks. This change is not so important that we have to push it through in an accelerated time frame.
("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. -- Steven