-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[RFC] Render typed iterators in docstrings (alternative) #2371
Draft
sizmailov
wants to merge
8
commits into
pybind:master
Choose a base branch
from
sizmailov:doc-gen-typed-iterators-ng
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Changes from 7 commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
91ca4e6
Render typed iterators (e.g. Iterator[int]) in docstrings
sizmailov 8bbfeea
Introduce make_iterator_ng/make_key_iterator_ng,
sizmailov 0e360b7
Revert `iterator_passthrough` test change
sizmailov 036add2
Use make_iterator_ng/make_key_iterator_ng in tests
sizmailov 96bdc5f
Use concrete return types instead of auto
sizmailov b1dbc30
fix: typo
sizmailov 98763aa
Avoid deprecation warning in iterator_passthrough
sizmailov c5500d8
Make use of PYBIND11_DEPRECATED macro
sizmailov File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Deprecation of long-standing function is a hostile action to users, since it would lead to warnings in user code, which would force everyone to use _ng version of functions.
This can be viewed as the cost of making the change fully backward-compatible.
Having two similar functions is not a good thing, so one should be marked as deprecated in favor of superior one.
I'm not 100% happy about this. Is there other viable option?
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.
I think if I were to consider this (using a suffix and deprecate the old) vs. #2244 (updating the function), my money would be still be on #2244 :(
In terms of incompatibility, I think that could be solved by using a (deprecated?) implicit conversion from
py::detail::iterator_state<...>
topy::iterator
.However, per @wjakob's points about complexity, I'm not sure if this PR avoids the complexity from before, due to the deprecation (which may lead to another name swap + deprecation from
make_iterator_ng
back tomake_iterator
?).The best option (that I can think of) is to mirror the setup used in
numpy.h
forpy::array
andpy::array_t
:Let
iterator
be the fully type-erased Python interface type, whileiterator_t<ValueType>
can add a (minimal) additional "C++ type-friendly" filter on top ofiterator
(e.g. the casting name, forced casting, etc.). If you do that, then perhaps you only neediterator_t<ValueType>
, rather than carrying around type info indetail::iterator_state<Iterator, Sentinel, bool, Policy>
and use all of thedecltype(...)
stuff? Then you can update thestl.h
stuff to useiterator_t<ValueType>
vs. justiterator
or propogating types from there.It may induce some additional non-functional indirection, but requires less type change?
Thoughts? @bstaletic or @wjakob if y'all are available?
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.
I agree with you up to this point.
Your idea here doesn't sound bad to me, but I believe @wjakob should have the last word.
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.
I also quite like the idea of fixing the actual problem, rather than adding onto the confusion. Then again, I can see the point that this "only" fixes the docstring (and you could already use
py::arg_v
to do so I believe?).At any rate, if we're thinking about making a breaking 3.0.0 release, it would be cool if we could include a fixed version. A potential route would be to first use a new name + deprecation, then rename in a (distant future) pybind11 3.0.0?
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.
This PR only fixes annotation of return type. Functions with typed iterator argument still need to use type-erased
py::iterator
. I don't thinkpy::arg_v
can help here.I like the idea of
py::iterator_t<ValueType>
. The only issue I think of is overloads support. Dispatcher needs to tell the difference betweenf(py::iterator_t<int>)
vsf(py::iterator_t<bool>)
. I think it's not possible to tell which is which until the actual iteration happens, unlike in case ofpy::array_t
. This issue can be "avoided" by banning overloads that different only inpy::iterator_t
argument(s). Alternatively, we can make a scaffold to extract first element (which still might be not enough) to dispatch and then iterate using mocked-up iterator, but this sounds like an implementation nightmare and potential nasty debug sessions for users.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.
Right, jumped to conclusions too quickly, there! We don't actually have a
py::ret_v
, I suppose, to support a manual/custom return type annotation?I thought we already have something like this (where the internal types are only checked at runtime), but I can't find it. This will always be a problem, though, so I wouldn't be opposed to just add it and document that it won't do anything for overloads (but it would do the casting for you, once you ask the next element). pybind11 has more corners where overloads aren't perfect and order matters, so ...
Extracting the first element would be reasonably unexpected, I believe. And as you say: it wouldn't provide any guarantees, so let's have users do that themselves, if they really want to disambiguate.