This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author p-ganssle
Recipients Aaron.Meurer, belopolsky, p-ganssle, xtreak, yselivanov
Date 2018-09-16.17:42:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1537119773.37.0.956365154283.issue32313@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2018-09-16 17:42:53p-gansslesetrecipients: + p-ganssle, belopolsky, Aaron.Meurer, yselivanov, xtreak
2018-09-16 17:42:53p-gansslesetmessageid: <1537119773.37.0.956365154283.issue32313@psf.upfronthosting.co.za>
2018-09-16 17:42:53p-gansslelinkissue32313 messages
2018-09-16 17:42:53p-gansslecreate