I can't think of an easy way to test this behavior.  It only occurs
when the file system default encoding and the interpreter default
encoding are different, such that you can open the file but not decode
its name.

things cannot be raised or caught.

functions on platforms where the underlying system calls are available.

calling __import__.  This helps make the expected search locations for encoding
modules be more explicit.

One could use an explicit value for __path__ when making the call to __import__
to force the exact location searched for encodings.  This would give the most
strict search path possible if one is worried about malicious code being
imported.  The unfortunate side-effect of that is that if __path__ was modified
on 'encodings' on purpose in a safe way it would not be picked up in future
__import__ calls.

Buildbot.

whether to rerun libffi configure.

gzip header.

filename attribute is still accessible as a property that emits a
DeprecationWarning.

Will backport.

Will backport to 2.5.

Fixes #1514451.

Will backport.

(The line has no effect anyway, but is present because it's
customary call the base class __init__).

Fixes #847665. Will backport.

at position 0.

is specified at the top of the file.  Also add a note that Python/Python-ast.c
needs to be committed separately after a change to the AST grammar to capture
the revision number of the change (which is what __version__ is set to).