Well, zipped-egg packages actually have both `__path__` and `__file__`, but both are bogus; not actual filesystem paths (they are "paths" that would be valid only if the egg were unzipped into a directory, even when it's not). So those types of apps would end up with an `appconfig.path` that isn't `None`, but isn't really usable either (though it probably doesn't break outright, since most uses of `appconfig.path` probably check `os.path.exists` or a variant.)

I'm actually not sure what types of modules either don't have `__path__` or have an empty one. Do you know of any specific examples? Was there one that motivated you to add the `except AttributeError` clause? If they aren't cases that we explicitly supported in prior versions, ISTM it would be valid to say "if you want to use your funky module loader for a Django app, you need to given an explicit path on your `AppConfig`."

The tests that fail in Django's own test suite if I eliminate the `except AttributeError` clause are cases where something is passing in `None` as the `app_module` argument to `AppConfig()` -- but it seems to me that's a case that would probably be better if it failed right away? Unless it was intentional on your part that that should succeed?

The other case I'm aware of that would fail without that `except` check would be if someone passed in a module rather than a package (i.e. `path.to.foo` which is `path/to/foo.py`, not `path/to/foo/__init__.py`). I'm not aware of any good use case for that, but it seems that it "worked" in 1.6. Since it was never documented you could do that, I'm not sure we need to support it?

(Sorry if I'm revisiting things you already went over in depth in working on app-loading. I just feel like this release is kind of our chance to enforce a bit more sanity in this area; if we're going to do it, may as well do it all at once.)