inspect.getsource(datetime) shows the Python source code for datetime, even when it is the C extension. This is very confusing. 

I believe it's because _datetime is used to override everything in datetime at the end of the file (here https://github.com/python/cpython/blob/11a247df88f15b51feff8a3c46005676bb29b96e/Lib/datetime.py#L2285), but __file__ is not imported.

I think this is *mostly* the correct behavior (though it may indeed be confusing). Note that `datetime.py` *is* the source of the module `datetime`, it's just that most of the code in there is shadowed by the line you've linked.

If you try and get the source of individual methods that were imported from `_datetime`, you'll get the expected failure:

>>> inspect.getsource(datetime.datetime.fromisoformat)
-- Long traceback --
TypeError: module, class, method, function, traceback, frame, or code object was expected, got builtin_function_or_method


That said, `inspect.getsource` does seem to be erroneously using the Python source for classes, e.g. `print(inspect.getsource(datetime.date))`

This is consistent with the behavior of `functools`, where the Python code for `functools.partial`, even when the C implementation is used.

Not sure if this is something that should be a warning, an exception or if the behavior should simply be documented in the `inspect` documentation.

I'll note that both `inspect.getsource(datetime)` and `inspect.getsource(datetime.date)` were IOError exceptions in Python 2.7, but have been returning the Python source code since at least Python 3.4.

The documentation for getfile says "This will fail with a TypeError if the object is a built-in module, class, or function."

https://docs.python.org/3/library/inspect.html#inspect.getfile

But it doesn't:
>>> inspect.getfile(datetime.datetime)
'C:\\Users\\User\\src\\cpython\\lib\\datetime.py'

Looks like for `getfile` docs should be updated. On python2.7.17_1, 

  import inspect, datetime
  print(inspect.getfile(datetime.datetime)) outputs, 

/usr/local/Cellar/python@2/2.7.17_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/datetime.so

It seems a long time overdue?

_datetime.datetime's tp_name is datetime.datetime so
inspect module guess that _datetime.datetime's module name is datetime, not _datetime.
I don't think we have to fix this issue from inspect module side.

If the _datetime.datetime's tp_name is updated to _datetime.datetime it could be fixed but I don't know this is the right approach and there might be some reason for choosing tp_name as datetime.datetime instead of _datetime.datetime.

@p-ganssle is the best expert for datetime module :)
I think that he could give the answer to this.

I think that we should re-examine this issue after GH-20472 is merged. I'm not really sure how that will affect this and indeed *how* it should affect this. I am not sure whether people are relying on the current behavior, or what use cases would be improved if we had a different behavior.

With regards to this:

> The documentation for getfile says "This will fail with a TypeError if the object is a built-in module, class, or function."

> https://docs.python.org/3/library/inspect.html#inspect.getfile

This is a bit unclear to me, and I'm not entirely sure if `datetime` qualifies. I think of built-in classes as things like `int` and `float`, and built-in functions as things like `abs` and `sum`, and `datetime` is an extension module — albeit one with a C implementation, and one that is in the standard library.

We should probably clarify the wording of `inspect.getsource` and determine what the intended semantics are for PEP-399-style modules, with both a C and pure Python implementation and the C implementation is what's being used. Error? Point to the Python implementation?

messages: + msg325495

components: + Library (Lib)
type: behavior