math.e is just a float instance; inspect.getdoc can only return data about the float type from it. I'm afraid there's nothing we can do here.

In theory, we could create a separate float subclass for each constant (e, inf, etc.) that provides a specific docstring. But I don't think it's worth it, nor worth encouraging.

The issue with getdoc() is essentially the same as for help(). Only modules, classes, and functions have individual docstrings. dir(math.e) equals dir(float), with equal __doc__s, and the same is true for every float.

Admittedly while I've been working on the project that triggered this, I keep forgetting that math.e isn't a function. The explanations given make sense in that context. I do wonder, though, if it would be worth using a function that returns e, or tau, or pi, or whatever other constants, instead of just having the constant. Would there be unnecessary performance impact? I don't know, but in my opinion, it would be helpful to have a useful docstring about these constants.

Yeah, it would be slower and more importantly, it would break a lot of code. I think a better approach would be to design a way to generally add docstrings to arbitrary objects (such as a global __docs__ dict). But there isn't any active proposal to do that as far as I'm aware.

Another possibility would be introducing module-level property, but that would be just as slow as a regular function call. On the plus (?) side, it could also prevent redefining fundamental constants :)