@Brett Cannon

> PEPs actually become historical documents once they are implemented

Actually the inconsistency of the values of the 3 module attributes (``__file__``, ``__cached__`` and ``__package__``) is with respect to the other values within the current implementation (not only with respect to the values specified in PEP 451). Sorry if I did not explain this well. Let me detail:

For ``__file__``, if you look at the current output of the above "Imported modules" section, you have:

- __file__: None, for an imported namespace package;
- __file__: 'not set', for an imported built-in module;
- __file__: 'not set', for an imported frozen module,

which is inconsistent: it should always be 'not set' when ``__file__`` has no meaning.

For ``__cached__``, if you look at the current output of the above "Run modules" section, you have:

- __cached__: None, for a non-package module run from the file system (``python3 module.py``) or run from standard input (``cat module.py | python3``);
- __path__: 'not set', for a non-package module run from the file system (``python3 module.py``) or run from standard input (``cat module.py | python3``),

which is inconsistent: it should always be 'not set' when ``__cached__`` has no meaning, like it is already the case for ``__path__`` and other module attributes.

For ``__package__``, if you look at the current output of the above "Run modules" section, you have:

- __package__: None, for a non-package module run from the file system (``python3 module.py``) or run from standard input (``cat module.py | python3``);
- __package__: '', for a non-package module run from the module namespace (``python3 -m module``) or a package run from the file system (``python3 module/``).

which is inconsistent: it should always be ``''`` when there is no parent package for ``__package__`` to refer to.