I've not followed this discussion closely, but I would assume that for most things on the "will never change" list the explanation is simply that the cost of changing it while maintaining backward compatibility is too high compared to the benefit of fixing the problem (regardless of whether it really is a problem). People who come in with enthusiastic proposals to fix some pet peeve usually don't have the experience needed to appreciate the difficulty in maintaining backwards compatibility. (A really weird disconnect from reality happens when this is mentioned in the same breath as "please fix the Python 2 vs. 3 problem". :-) I would also guess that for things that are actually controversial (meaning some people hate a feature that other people love), it's much easier to explain why it's too late to change than it is to provide an objective argument for why the status quo is better. Often the status quo is not better per se, it's just better because it's the status quo. from __future__ import no_colons # :-) On Thu, Jan 12, 2017 at 4:57 PM, Erik <python@lucidity.plus.com> wrote:
On 12/01/17 19:51, Todd wrote:
On Thu, Jan 12, 2017 at 2:33 PM, Sven R. Kunze <srkunze@mail.de <mailto:srkunze@mail.de>> wrote: First of all, I am anti-censor and pro-change.
There is no "censorship" or "banning thoughts" going on here. Even with
this PEP, people are free to think about and talk about how Python could work differently all they want. What this PEP does is tell them that certain decisions have been made about how the Python language is going to work, so they should be aware that such talk isn't going to actually result in any changes to the language.
By saying that "these are things that will not change", then you _are_ sort of banning talk about them (if, as you assert, "such talk isn't going to actually result in any changes to the language" then you are saying don't waste your breath, we won't even consider your arguments).
I think I get Sven's point. A long time ago, someone probably said "Python will never have any sort of type declarations.". But now there is type hinting. It's not the same thing, I know, but such a declaration in a PEP might have prevented people from even spending time considering hinting.
Instead, if the PEP collected - for each 'frequently' suggested change - a summary of the reasons WHY each aspect is designed the way it is (with links to archived discussions or whatever) then that IMO that would be a good resource to cite in a canned response to such suggestions.
It's not that "these things will never change", it's more of a "you need to provide a solid argument why your suggestion is different to, and better than, the cited suggestions that have already been rejected".
Probably a lot of work to gather all the references though. But it could start out with one or two and grow from there. Add to it as and when people bring up the same old stuff next time.
E.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)