With PEP 451, Python 3.4 introduced module specs to encapsulate the module's import-related information, particularly for loading.  While __loader__, __file__, and __cached__ are no longer used by the import machinery, in a few places it still uses __name__, __package__, and __path__.

Typically the spec and the module attrs will have the same values, so it would be a non-issue.  However, the import-related module attributes are not read-only and the consequences of changing them (i.e. accidentally or to rely on an implementation detail) are not clearly defined.  Making the spec strictly authoritative reduces the likelihood accidental changes and gives a better focus point for a module's import behavior (which was kind of the point of PEP 451 in the first place).  Furthermore, objects in sys.modules are not required to be modules.  By relying strictly on __spec__ we likewise give a more distinct target (of import-related info) for folks that need to use that trick.

I don't recall the specifics on why we didn't change those 3 attributes for PEP 451 (unintentional or for backward compatibility?).  At one point we discussed the idea that a module's spec contains the values that *were* used to load the module.  Instead, each spec became the image of how the import system sees and treats the module.

So unless there's some solid reason, I'd like to see the use of __name__, __package__, and __path__ by the import machinery eliminated (and accommodated separately if appropriate).  Consistent use of specs in the import machinery will help limit future surprises.

Here are the specific places:

__name__
--------
mod.__repr__()
ExtensionFileLoader.load_module()
importlib._bootstrap._handle_fromlist()
importlib._bootstrap._calc___package__()
importlib._bootstrap.__import__()

__package__
-----------
importlib._bootstrap._calc___package__()

__path__
--------
importlib._bootstrap._find_and_load_unlocked()
importlib._bootstrap._handle_fromlist()
importlib._bootstrap._calc___package__()

__file__
--------
mod.__repr__()

Note that I'm not suggesting the module attributes be eliminated (they are useful for informational reasons).  I would just like the import system to stop using them.  I suppose they could be turned into read-only properties, but anything like that should be addressed in a separate issue.

If we do make this change, the language reference, importlib docs, and inspect docs should be updated to clearly reflect the role of the module attributes in the import system.

I have not taken into account the impact on the standard library.  However, I expect that it will be minimal at best.  (See issue #21736 for a related discussion).