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
Apidocs #2383
Apidocs #2383
Conversation
@@ -0,0 +1,38 @@ | |||
.. AUTO-GENERATED FILE -- DO NOT EDIT! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean to remove this comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, thanks. I must have missed this one.
[(-8, 5, None), (-7, 1, 4), (0, 2, 3)] | ||
Example:: | ||
|
||
>>> list(extract_input_ranges("~8/5-~7/4 2")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that this is getting tested, it'll have to be extract_hist_ranges
(instead of extract_input_ranges
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, that should be fixed in the next commit.
I think in the long run, this is necessary. Our current setup is a bit too chaotic and leaves users with an incomprehensible impact surface for what IPython is as a library. Given that I don't think the current autogen docs are very good as they are, I'm totally +1 on moving forward with this, even if it takes a while to get it where we'd be completely happy. |
This is important, but should be close the PR and open an issue to track this (> 2 months inactivity)? |
Yes, if you'd prefer. I'm not convinced that this is the right approach - it's a lot of work to do this, as evidenced by the fact that I didn't even finish the docs for IPython.core. But I do think we need to improve our API docs, and work out what parts we really consider the API, and what is implementation details. |
@takluyver Was #2616 a replacement of this one ? can it be closed ? |
Yes, good point. |
Not ready for merge.
This is something we discussed briefly a couple of weeks ago - should we move from fully auto-generated API docs to something a bit more manual, forcing us to be clearer about what is the public API?
I made a start towards that, but I wanted to check what we think of the idea and the details before I spend more time on it. I used the auto-generated API docs with some modifications:
core/history.txt
rather thanIPython.core.history.txt
)Bunch
).ultratb
is interesting):inherited-members:
option from autoclass documentation (classes that derive from Configurable, for example, inherit a lot of confusing methods).. automethod:: __init__
documentation where__init__
doesn't have a docstring.