On Oct 20, 2021, at 11:38, Eric Snow <report@bugs.python.org> wrote:
> 
> Regardless, I expect the primary reason __package__ is writable is
> because modules have never had any read-only attrs.

So historical accident mostly.

> The more important question now is, when is __package__ ever modified?
> I can think of 2 cases:
> 
> 1. legacy (pre-451) importers set it when they load the module
> 2. someone wants to customize the import system without writing an importer
> 
> With the latter, specifically they are trying to change how the module
> is reloaded or submodules are imported.  In that case there should
> probably be an explicit way to do so without having to hack the import
> machinery.
> 
> My only concern with any support/encouragement for modifying the spec
> after import is it results in less confidence about how the module was
> imported originally.

I guess a question to answer then is whether we philosophically want the module attributes to be equivalent to the spec attributes.  And by equivalent, I mean enforced to be exactly so, and thus a proxy.  To me, the duplication is a wart that we should migrate away from so there’s only one place for these attributes, and that should be the spec.

Here is the mapping we currently describe in the docs:

mod.__name__ === __spec__.name
mod.__package__ === __spec__.parent
mod.__loader__ === __spec__.loader
mod.__file__ === __spec__.origin
mod.__path__ === __spec__.submodule_search_locations
mod.__cached__ === __spec__.cached

But right now, they don’t have to stay in sync, and I don’t think it’s reasonable to put the onus on the user to keep them in sync, because it’s unclear what code uses which attribute.  Okay, so you can just set them both to be safe, but then you can’t do that with __spec__.parent/__package__

This is what leads me to think that having a proxy to keep them in sync and relaxing the read-only restriction is the path forward, even if writing __package__ doesn’t make sense.  It also seems like the easier way to keep backward compatibility, rather than enforcing read-only on __package__ to match __spec__.parent.

So the question is less about whether this is useful than whether it will break things if they write to it.