##// END OF EJS Templates
Improve typing and MIME hook API for inspector (#14342)...
Improve typing and MIME hook API for inspector (#14342) Fixes https://github.com/ipython/ipython/issues/14339 ### Additions Adds `InfoDict` type to improve the typing of `info()` result. Adds missing `"subclasses"` to `info_fields` list (these were added to the field list in https://github.com/ipython/ipython/pull/11486 but we forgot to update `info_fields` variable at the time) - the newly added `InfoDict` type will ensure that this won't happen again. Adds `InspectorHookData` dataclass which is passed to the MIME hooks which now should expect a single argument. Having a single dataclass argument enables us to deprecate individual fields, or add new fields without breaking the existing hooks. The old hooks will still work (if any are out there since this mechanism got just added in the previous point version). ### Deletions A comment over `info_fields` gets deleted: - Contrarily to the comment (which is getting deleted in this PR), `info_fields` were not defining the order of display since at least 2015 (https://github.com/ipython/ipython/pull/7903 - I did not feel the need to go further in the history to find when exactly it happened). - Also contrarily to this comment, current Jupyter messaging spec does not define the contents of `info_fields` (I guess this was lost during IPython/Jupyter split), but the newly added `InfoDict` at least properly annotates their type (if you know where I can find the old IPython messaging spec with the descriptions I can add these as doc comments). Unused `cast_unicode` import gets deleted. If someone imported it from here... well they really should not have. ### Deprecations - mime hooks taking two arguments (`obj, info`)

File last commit:

r28649:b66c93b8
r28661:2084e7f3 merge
Show More
CONTRIBUTING.md
117 lines | 4.4 KiB | text/x-minidsrc | MarkdownLexer

Triaging Issues

On the IPython repository, we strive to trust users and give them responsibility.
By using one of our bots, any user can close issues or add/remove
labels by mentioning the bot and asking it to do things on your behalf.

To close an issue (or PR), even if you did not create it, use the following:

@meeseeksdev close

This command can be in the middle of another comment, but must start on its
own line.

To add labels to an issue, ask the bot to tag with a comma-separated list of
tags to add:

@meeseeksdev tag windows, documentation

Only already pre-created tags can be added. So far, the list is limited to:
async/await, backported, help wanted, documentation, notebook,
tab-completion, windows

To remove a label, use the untag command:

@meeseeksdev untag windows, documentation

We'll be adding additional capabilities for the bot and will share them here
when they are ready to be used.

Opening an Issue

When opening a new Issue, please take the following steps:

  1. Search GitHub and/or Google for your issue to avoid duplicate reports.
    Keyword searches for your error messages are most helpful.

  2. If possible, try updating to main and reproducing your issue,
    because we may have already fixed it.

  3. Try to include a minimal reproducible test case.

  4. Include relevant system information. Start with the output of:

    python -c "import IPython; print(IPython.sys_info())"

    And include any relevant package versions, depending on the issue, such as
    matplotlib, numpy, Qt, Qt bindings (PyQt/PySide), tornado, web browser, etc.

Pull Requests

Some guidelines on contributing to IPython:

  • All work is submitted via Pull Requests.
  • Pull Requests can be submitted as soon as there is code worth discussing.
    Pull Requests track the branch, so you can continue to work after the PR is submitted.
    Review and discussion can begin well before the work is complete,
    and the more discussion the better.
    The worst case is that the PR is closed.
  • Pull Requests should generally be made against main
  • Pull Requests should be tested, if feasible:
    • bugfixes should include regression tests.
    • new behavior should at least get minimal exercise.
  • New features and backwards-incompatible changes should be documented by adding
    a new file to the pr directory, see the README.md
    there
    for details.
  • Don't make 'cleanup' pull requests just to change code style.
    We don't follow any style guide strictly, and we consider formatting changes
    unnecessary noise.
    If you're making functional changes, you can clean up the specific pieces of
    code you're working on.

GitHub Actions does
a pretty good job testing IPython and Pull Requests,
but it may make sense to manually perform tests,
particularly for PRs that affect IPython.parallel or Windows.

For more detailed information, see our GitHub Workflow.

Running Tests

All the tests can be run by using

pytest

All the tests for a single module (for example test_alias) can be run by using the fully qualified path to the module.

pytest IPython/core/tests/test_alias.py

Only a single test (for example test_alias_lifecycle) within a single file can be run by adding the specific test after a :: at the end:

pytest IPython/core/tests/test_alias.py::test_alias_lifecycle

Code style

  • Before committing, run darker -r 60625f241f298b5039cb2debc365db38aa7bb522 <file path> to apply selective black formatting on modified regions using darker==1.5.1 and black==22.10.0
  • As described in the pull requests section, please avoid excessive formatting changes; if a formatting-only commit is necessary, consider adding its hash to .git-blame-ignore-revs file.

Documentation

Sphinx documentation can be built locally using standard sphinx make commands. To build HTML documentation from the root of the project, execute:

pip install -r docs/requirements.txt   # only needed once
make -C docs/ html SPHINXOPTS="-W"

To force update of the API documentation, precede the make command with:

python3 docs/autogen_api.py

Similarly, to force-update the configuration, run:

python3 docs/autogen_config.py