PEP-597: Emit a Warning when encoding is omitted

PEPs
21

I updated the PEP.

2 Likes
22

might be worth suggesting in the PEP that typeshed use:

LOCALE_ENCODING: Literal["__locale_encoding__"] = ...  # or whatever the string constant ends up
1 Like
23

I don’t think that it’s a good idea to say “deprecation” if there is no plan to change the default behavior in the future. In past discussions, I understood that we cannot make UTF-8 the default encoding in the near future. We cannot raise an error when the encoding is omitted neither, since it would break too much code.

Would it be possible to use a new very specific warning class, rather than reusing PendingDeprecationWarning? Ideas of warning name:

  • DefaultEncodingWarning
  • ImplicitEncodingWarning
  • NoEncodingWarning
  • etc.

A specific warning gives the ability to easily ignore it when you test an application for deprecation warnings, but don’t want to be annoyed by the encoding warnings. Use -W ignore::DefaultEncodingWarning command line option or PYTHONWARNINGS=ignore::DefaultEncodingWarning environment variable.

It’s not only about the warning class, but also the message sent to Python users. There is no scheduled plan to break their applications soon.

2 Likes
24

But it is why there is PendingDeprecationWarning. If we have actual removal/changing plan, it should be DeprecationWarning or FutureWarning.

“Pending” means “there is no actual plan to remove/change it”. So using PendingDeprecationWarning totally makes sense to me.

I am not sure that merits is enough to adding one more builtin exception class.
I can not imagine users want to fix PendingDeprecationWarning, but ignore use of default text encoding. I want to notice all warnings and fix as many as possible when I use -Xdev mode, -Wd, or PYTHONWARNINGS=default.

1 Like
25

People are proposing to make UTF-8 the default since we started to discuss Python 3.0. 12 years after the release of Python 3.0, we still get new issues with special locale configurations on Linux. Python uses UTF-8 on Windows, macOS, Android and VxWorks for the filesystem encoding. On Linux and FreeBSD, it still uses the locale encoding: Python Initialization Configuration — Python 3.13.0a2 documentation

Maybe in 10 years, it will be obvious to use UTF-8 by default on all platforms. But in 2020, it remains a controversial question (see discussions on my previous attempts to switch to UTF-8 by default last year).

IMO PendingDeprecationWarning means an incoming incompatible change, which is not the case here. This problem is important enough to require a new specific warning class.

“Pending” means “there is no actual plan to remove/change it”. So using PendingDeprecationWarning totally makes sense to me.

Usually, a PendingDeprecationWarning in introduced in Python version N, then replaced with DeprecatedWarning in version N+1, to finally remove the feature in version N+2. Sometimes, PendingDeprecationWarning in introduced after a final 3.x.0 final, in a bugfix release. But there is no general rule.

1 Like
26

Didn’t we agree that we should use DeprecationWarning from first last year?

Previous discussion:

https://mail.python.org/archives/list/python-dev@python.org/thread/PE57K2XE2SWKNWKJQNMB3XNEU2BEAVIC/

Current note in the document:

Introducing new Warning class will affects warning filter configurations. We already have different default rules for DeprecationWarning and PendingDefaultWarning. We have special care in tests. Third party libraries too.

So I didn’t want to introduce a new warning class, especially until we emit the warning only in dev mode. If we abandon to changing the default encoding, but just wait all system in the world become UTF-8 locale, the new Warning class and filter rules are technical debt.

But if the new Warning class is subclass of the DeprecationWarning, we may able to avoid making filter rules more complicated. How do you think this subclassing?

For naming, if we want to use the warning only for this specific purpose, verbose name is preferred since we have much XxxxEncoding (FS, Locale, Default, PYTHONIOENCODING etc…)
For example, “TextIOEncodingWarning” or “DefaultTextIOEncoding”.

2 Likes
27

I updated the PEP 597. I added EncodingWarning and option to enable it.

  • EncodingWarning, like BytesWarning
  • -X warn_encoding or PYTHONWARNENCODING to enable it.
3 Likes
28

I created new thread on python-dev ML for the updated PEP.

https://mail.python.org/archives/list/python-dev@python.org/thread/SFYUP2TWD5JZ5KDLVSTZ44GWKVY4YNCV/

3 Likes