It's not clear to me what this is "fixing"--is the point of it the change in behavior you describe above, the freezing of the returned value? Furthermore, the lru_cache(1) usage seems like an odd idiom--almost an oxymoron. What is the advantage over a simple property?

get_home and friends cannot be properties because they are not methods (well, see https://www.python.org/dev/peps/pep-0549/, not that it matters for us).

The point is that the previous implementation checked whether get_home (etc.) has already been called; regardless of whether it has already been called, the internal (_get_home) implementation would be called, and if this is the first call, the result would be logged (implicitly, this behavior assumes that _get_home always returns the same result (which is a reasonable assumption) so further calls do not need to be logged).

Instead, the proposed implementation first wraps the internal implementation (_get_home) into a logging wrapper (level-1 wrapper) (so that whenever the level-1 wrapper is called, the result is logged); then wrapped that guy into a memoizing wrapper (level-2). Because get_home takes no arguments, every call from the second one is going to hit the (single-value) cache, and thus not going to go to the level-1 wrapper. So we return the same value every time and don't need to track ourselves whether we have already been called. [Obviously it is easy to write this as a decorator ourselves (in fact this is what _wrap was). But the point is that this decorator is already provided by the stdlib, under the lru_cache name...]

Yes, I realized right after pressing "comment" that I didn't really mean "property"--but rather the sort of structure used with a property getter:

_user_home = 0  # dummy flag prior to first call, since we can't use None
def get_home():
    """Find user's home directory if possible.
    Otherwise, returns None.
    """
    if _user_home is not 0:
        return _user_home
    _user_home = None
    if six.PY2 and sys.platform == 'win32':
        path = os.path.expanduser(b"~").decode(sys.getfilesystemencoding())
    else:
        path = os.path.expanduser("~")
    if os.path.isdir(path):
        _user_home = path
    else:
        for evar in ('HOME', 'USERPROFILE', 'TMP'):
            path = os.environ.get(evar)
            if path is not None and os.path.isdir(path):
                _user_home = path
                break
    _log.log(logging.INFO, '$HOME=%s', _user_home)
    return _user_home

(Untested, probably can be written better.) Advantage: everything is explicit and in one place; it can be read without having to track down the decorators and figure out how they work.

I don't feel very strongly about the PR (I think the current situation is not so clear, your approach of making everything explicit would work too).

I just realized why the PR name was confusing: as mentioned in the original message I was initially planning to also fix subprocess calls (by moving the log to matplotlib.compat.subprocess.*, rather than having to repeat them every time), but I realized this would conflict with my other PR (on executable resolution) so I decided to leave that out for now, and ended up with a somewhat partial PR.

Why we are calculating paths on demand rather not on module import?

They are effectively computed at import time, the functions are only there to factor out common code and avoid polluting the module namespace with intermediate variables.

I pushed a new version which should be hopefully a bit clearer and better documented.

Superseded (essentially) by #11398.