On Tue, 9 Feb 2021 at 11:55, Inada Naoki <songofaca...@gmail.com> wrote:
> I think only we can do is documenting the option like this: > > """ > EncodingWarning is warning to find missing encoding="utf-8" option. It > is common pitfall that many Windows user > Don't try to fix them if you need to use locale specific encoding. > """ I'm a very strong -1 on having programs generate warnings that the user isn't supposed to fix. If we can't provide a good recommendation to the user on what to do, we shouldn't be warning them that what they are currently doing is wrong. I've seen far too many examples of people thinking "well, users can ignore the warning, it's not shown by default" and then users' code being broken because of a situation we didn't think about (most recently, the Python test suite, which runs the venv tests with warnings converted to errors, which broke on a pip release that contains a deprecation warning from packaging). IMO, if we issue a warning, we *must* be able to advise the user how to fix it. Otherwise we shouldn't be assuming we know what's correct better than the user. Personally, I'm not at all keen on the idea of making users always specify encoding in the first place, even if it's "just for the transition". There are far too many people in my experience who wouldn't have a clue what to do when faced with that decision. And the people (again in my experience) who don't know how to make that choice are *precisely* the people for whom the system-defined default is what they want. Certainly, if they are getting stuff off the internet, they will more often get UTF-8, but I tend to find that people with limited understanding of these issues are much more comfortable with the idea that "stuff off the internet needs weird settings like this UTF-8 thing whatever it is", than they are with the idea that they have to tell Python how to read that text file they just got from their boss, who's still got Windows 7 on his PC... If we want to switch the default encoding from the locale encoding to UTF-8, we should find a way to do that which *doesn't* mean that there's a "transitional" state where using the default is considered bad practice. That helps no-one, and just adds confusion, which will last far longer than that one release (there will be people encountering StackOverflow questions on the topic long after the default has changed). Maybe we just have to accept that we can't work out what people are intending, and just state in advance in the documentation that the default will change, then it's documented as an upcoming breaking change that people can address (if they read the release notes, but we seem to be assuming they'll spot a warning, so why not assume they read the release notes, too?). Paul PS I've hesitated about saying this before, as I'm very aware that being from the UK, any problems I have with encodings are relatively minor, so I want to let the people with real problems have their say. But when we're talking about telling users not to fix warnings, I feel the need to speak up. _______________________________________________ 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/5W7YFNY7BLCS25ZICWMH57XH5REITI34/ Code of Conduct: http://python.org/psf/codeofconduct/
