python / python/cpython

Duck-typing in `inspect.getfile`

Open
#131,628 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

stdlib type-feature
Dominant language
Python
Stars
77.2k
Forks
35.9k
PR merge metrics
PR metrics pending

Description

Running inspect.getsource(numpy.random.random_sample) yields

File ~\.conda\envs\sage-dev\Lib\inspect.py:943, in getfile(object)
    941 if iscode(object):
    942     return object.co_filename
--> 943 raise TypeError('module, class, method, function, traceback, frame, or '
    944                 'code object was expected, got {}'.format(
    945                 type(object).__name__))

since the cython function is not correct recognized as a "true" function (i.e. it is not derived from FunctionType). But since a Cython function correct provides __code__, all the information is actually there to properly get the source file.

Refs: https://github.com/cython/cython/blob/030e3886fa094ecae6121f8ccacaf814956dca5c/docs/src/userguide/limitations.rst#L34

While it is quite possible to emulate the interface of functions in Cython's own function type, and recent Cython releases have seen several improvements here, the "inspect" module does not consider a Cython implemented function a "function", because it tests the object type explicitly instead of comparing an abstract interface or an abstract base class. This has a negative impact on code that uses inspect to inspect function objects, but would require a change to Python itself.

and

At the very least, the inspect module should use more duck-typing internally. For example, consider this code from "getfile":

    if ismethod(object):

        object = object.__func__

    if isfunction(object):

        object = object.__code__

    if istraceback(object):

        object = object.tb_frame

    if isframe(object):

        object = object.f_code

    if iscode(object):

        return object.co_filename

Originally posted by @jdemeyer in #74257

Linked PRs
  • gh-131632

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with inspect.getfile and the isfunction/iscode checks shown in the issue. Compare how objects exposing code are handled, then review linked PR gh-131632 before doing any work. Done means the reported Cython function can resolve its source file without breaking existing inspect.getfile behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
devtools
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.