Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Log implicit refs #928

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

larsoner
Copy link
Contributor

@StefRe working on using the exclusion of implicit refs for MNE-Python, it occurred to me that it would be nice to have a way for SG to tell me what its most common implicit refs are. This PR adds support for this via:

    'log_implicit_limit': 10,

For example, this is what tinybuild now gives:

most common implicit backreferences (10 most):
    - 5: DummyClass
    - 3: ExplicitOrder
    - 2: DummyClass.prop
    - 2: DummyClass.run
    - 1: identify_names
    - 1: clean_modules
    - 1: figure_rst

And for MNE-Python running a subset of our docs (after excluding a few):

    - 176: data_path
    - 94: Epochs
    - 89: read_raw_fif
    - 51: pick_types
    - 45: find_events
    - 32: Raw
    ...

WDYT @StefRe ?

One problem is that exclusion currently works when creating the set of possible references to resolve. We do this for example by adding both mne.epochs.Epochs and mne.Epochs to the list of backreferences, then figuring out which is actually documented in the API docs later. My ugly workaround for now is just to keep count based on the name rather than the module.name. A better fix would be to delay the counting/printing until later, when we resolve which one is actually correct. Then we can give the name as it shows up in the API docs. So that's going in the TODO...

Todo:

  • Fix some -D-incompatible gallery conf switches
  • Implement counting and writing out
  • Make exclusion work at the level of replacement / with full API names, not backref generation / just the obj/method
  • Document feature
  • Add tests

Another option would be to write these to a file at the end of the build like we do for sg_execution_times.rst, which would also be easy. Not sure which is better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant