On 23.04.2021 03:37, akdor1154 wrote:
> 
> akdor1154 <akdor1154@gmail.com> added the comment:
> 
> If I understand the target of this issue, this is a breaking change in python 3.9 .
> 
> E.g. see https://github.com/SAP/PyHDB/issues/149
> 
> Ideally if we did not intend to break libraries then can this be fixed?
> Or if it is acceptable to have such a breaking change, can it be documented as such? (maybe this is https://github.com/python/cpython/pull/23096 ? though I would not interpret that as a breaking change at first glance)

This patch only restored the behavior we had before (and for many many
years). It's not breaking, it's in fact resolving a break which was
caused by earlier:

https://bugs.python.org/issue37751#msg349448

Please note that search functions determine how to map codec names
to codec implementations. The codec search function in the encodings
package uses one way to do this (and depends on how the package
is structured).

The approach taken by the encodings search function is listed here:
https://github.com/python/cpython/blob/master/Lib/encodings/__init__.py#L43

Other search functions can work in different ways.

Now, unfortunately, parts of this kind of normalization have also made
its way into the codecs module itself and into the Unicode
implementation and perhaps not always in a way which allows search
functions to use a different approach or which is consistent.

As I mentioned before, the safest way to go about this is to use
alnum only names for codecs, with the addition of underscores to
separate important parts.

The Python implementation should make sure that such names continue
to work when passed through any codec name normalization.