##// END OF EJS Templates
upstream » ipython
RSS

Clone from https://github.com/ipython/ipython.git

Backport PR #10496: Define `_repr_mimebundle_`...
Backport PR #10496: Define `_repr_mimebundle_` Allows objects to display arbitrary mime-types by returning a mimebundle. This is getting increasingly important as custom mime-types are growing in popularity. - mime-bundle is computed first, but other formatters are still called - if a mime-type is present in repr-mimebundle, `_repr_<mime>_` will not be called (avoids redundant calls for backward-compatible objects) closes 10090 cc rgbkrk Alternative design: rather than single method returning the mimebundle itself, return mime-keyed mapping to callables, e.g.: ```python def _repr_mime_methods_(self): return { 'text/html': self._repr_html_, } ``` Another more minor alternative: rather than allowing return of `data` or `(data, metadata)`, require returning the full mime-bundle with `data`, `metadata` keys: ```python def _repr_mimebundle(self): return { 'data': { 'application/vnd.foo+json': [1,2,3], }, } ```
Thomas Kluyver - - Load All Authors

File last commit:

r20636:676067ce
r23619:abbf312f
Show More
CONTRIBUTING.md
45 lines | 2.1 KiB | text/x-minidsrc | MarkdownLexer
/ CONTRIBUTING.md
History | Annotation | Raw |Copy content |Copy permalink

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 master 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 master
  • 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.

Travis does a pretty good job testing IPython and Pull Requests,
but it may make sense to manually perform tests (possibly with our test_pr script),
particularly for PRs that affect IPython.parallel or Windows.

For more detailed information, see our GitHub Workflow.