Not fixing 3.14.1 because that won’t fix 3.14.0 doesn’t make sense to me.
3 Likes
Please try to actually understand the concerns being raised instead of trying to produce gotchas where there are none.
3.14.0 is broken for this purpose. There is nothing that can be done in that regard.
What will or will not happen for 3.14.1 isn’t relevant for this discussion point.
I have in no way indicated that we cannot or should not change this in a later version, just that doing so will not remove the problem that people have to workaround now. 3.14.0 does not become irrelevant when 3.14.1 is released, as much as I wish were the case. People and organizations do not always move at such a pace on updating without critical reason to do so, and I have to assume that the things I maintain could run on 3.14.0 unless I specifically block that from happening.
2 Likes
And the proposed workarounds for this aren’t great. There’s naught to be done but make sure people who need to know, know:
- precompiling sources can silence this one, but this will increase CI/CD runtimes significantly (in aggregate) for some projects that run CI/CD on every development commit
- you can’t filter this properly, but you can supress all SyntaxWarnings as a category. If you do this, you may miss other things with a better signal to noise ratio, use a linter in conjunction.
- Unless there is a process change to commit to actually understanding this use, you should assume this may happen again and transition away from using python’s warning systems. If you want to avoid that being neccessary, as I would, the other thing that can be done is propose process changes to prevent repeats of this. I have started that in another thread
Skipping a .0 patch level release isn’t the end of the world. In fact, many people who don’t want to use bleeding edge software use this as a strategy.
I’d suggest to focus energy on writing the follow-up PEP now.
17 Likes
It doesn’t matter what I understand. It’s not up to me whether this change gets reverted or not. I follow the PEP process just as I’m suggesting you do.
2 Likes
You don’t need to invent stances on issues that haven’t been expressed to do that, all that has done has required clarification because I don’t want my perspective misunderstood or
misconstrued in a way that is dismissive of taking positive action towards preventing repeats and making sure that those impacted are taken seriously.
Being incompatible with a 3.x.0 release isn’t so bad as it sounds. PyInstaller is incompatible with 3.10.0 due to some regression in dis. The duplicate issues we later received got a bit on the spammy side but once the .1 release was out, nobody seemed to resent having to upgrade a micro version.
I vaguely remember a bug in sqlite3 taking out coverage for 3.6.0 – it happens. As long as bumping micro versions remains low risk, it’s a nuisance but an easily solvable one.
16 Likes
PEP765 is a degradation that breaks valid Python. Its justification is flawed. It should be reverted in Python 3.14.1. The breaking of ~True scheduled for Python 3.16 should be canceled.
The justification is flawed, most importantly, due to its intent:
The Python Software Foundation lists as a core activity:
STRUCTURE AND STABILITY SO THE PYTHON LANGUAGE, ITS CONTRIBUTORS, AND USERS CAN THRIVE.
PEP - 1 states:
A PEP is a design document providing information to the Python community, or describing a new feature for Python or its processes or environment.
This change destabilizes the language and removes, not adds, a feature.
The intent is paternalistic and condescending. Python (like all non-trivial languages) should work to empower programmers. The PEP claims: The current PEP is based on empirical evidence regarding the cost/benefit of this change. This begs the question, cost and benefit to whom? The PEP authors clearly understand how Python finally works, so there is no cost or benefit to them.
We know the concrete cost: Elizabeth King’s code has been broken. Who benefits? The fact that the analysis found undetected bugs in a few of the 8,000 most popular packages only justifies a SyntaxWarning that can be specifically suppressed.
Valid statistical inference requires random sampling of the population. There is no requirement for Python code to be published, so the authors are not justified in using PyPi as a source.
~True is scheduled for removal. This, too, will break existing code, and the fact that (to the best of my knowledge) this degradation of Python was done without PEP raises concerns about the community governance model: I can find no evidence either the: publicly available on the web so that all interested parties can participate. nor Steering Council approval occurred.
3 Likes
This kind of hyperbole is really not helpful, it just keeps turning up the temperature on an already acrimonious discussion.
Pretending that this decision wasn’t taken (and then reaffirmed) after carefully weighing the complicated trade-offs involved is a highly uncharitable interpretation of everyone’s efforts on this.
There were good reasons to break a miniscule amount of code in the interest of making the language safer and easier to use. Even if you don’t agree with the outcome, you can acknowledge the rationale.
A lot of people (judging by the hearts of for example the message above) just have better things to do with their time than to keep relitigating this subject.
We can rerelitigate whether these decisions hit the right trade-off, but my concern here is that it becomes a matter of a vocal minority grinding down the hard-fought and well-reflected opinion of the majority, not on the merits, but by sheer intransigence.
19 Likes
Yeah, hard to tell which way round the situation actually is.
1 Like
Where is the difficulty? On one side you have people calling the end of the world and on the other side you have people asking you to submit the objections you feel have gone unheard in the form of a new PEP.
If you can convince the steering council to freeze python for the sake of stability then that’s what we’ll do. Future languages will avoid these mistakes.
3 Likes
Should not this doscussion had already closed a long time ago?
4 Likes
To prove that we don’t want to hear those who feel they have not been heard?
Feel free to unsubscribe. If anything useful happens it will be on the thread for the follow up PEP.
7 Likes
It was regarding minority/majority argument, nothing else. Just to neutralise it, as I think it is neither conclusive nor productive angle to look at things here.
That’s a fair enough opinion to have, but I definitely wasn’t able to pick up on that sardonic angle from
which sounded genuine to me. Perhaps we have vastly different perceptions of who’s in the majority/minority. FWIW, I’m also including the number of hearts on comments (of which there are a lot on posts that affirm the decision as taken), and then it really does look lopsided to me.
It has come to our attention that our earlier statement was misinterpreted by some. Our wording was not clear enough, and we would like to clarify our intent.
The Steering Council continues to fully support both the intent and direction of PEP 765. The PEP promotes clearer and more predictable control flow, which aligns with Python’s design philosophy and long-term goals.
When we said it was “too late” to revert, that was not meant to imply that we regretted the decision. We meant that even if a PEP were made to revert the feature for 3.14, we were in the release candidate stage, and reverting the change for the 3.14 release would have created more disruption and uncertainty than it would have solved. We acknowledge that this SyntaxWarning has an impact on some users, we were aware of that when deciding to accept the PEP. We value the feedback received and welcome new ideas and perspectives. Anyone who believes that PEP 765 or its implementation should be reconsidered or would like to improve the state of warnings in Python in general is encouraged to work towards a new PEP targeted for a future Python, with clear motivation and supporting evidence, rather than reopening discussion on an accepted one.
To summarize:
- PEP 765 remains accepted and will not be reverted in 3.14.
- Future discussion on this topic should proceed through a new PEP if there is strong motivation to do so.
Warm regards,
Donghee
on behalf of the Python Steering Council
22 Likes
Just to clarify.
Would SC consider reverting this for 3.15 or 3.14.1?
Fwiw for those who aren’t familiar with the distinction between Python language version and CPython versions this is a reasonable point of confusion on the statement. As for Python package versions 3.14 would be equal to 3.14.0 strictly, not 3.14.1.
But yes, for clarity, language PEPs are for Python language versions,which are 3.13, 3.14, 3.15, etc. The language itself doesn’t have bugfix versions.
5 Likes