Fix docstring mismatches in the Python bindings - #3948
Merged
Conversation
1 task
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Proposed changes
Four docstring fixes in
python/src, all cases where the doc text disagrees with the binding it is attached to. Checked each against the compiled module after rebuilding.dequantize(ops.cpp): theArgs:block listedmodelast, afterglobal_scaleanddtype, but the signature has it before them. Anyone following the doc order positionally gets aTypeError:pad(ops.cpp): documented asconstant_value, but the keyword isconstant_values, so the documented spelling raisesTypeError: incompatible function arguments.rfftn(fft.cpp): theReturns:sentence was cut off at "The output" mid-thought. Completed it to matchrfftandrfft2("The output data type will be complex."), which is also what it returns (complex64).FunctionExporter(export.cpp):fun:\mx.exporter`was missing the leading colon on the role, so it rendered as literal text instead of a link to:func:`mx.exporter``.Checklist
Put an
xin the boxes that apply.pre-commit run --all-filesto format my code / installed pre-commit prior to committing changes(docstring text only, no tests; rebuilt CPU-only locally and confirmed the rendered docstrings)
Happy to split this into separate PRs if you would rather review them apart.
for transparency: freshman contributor here, and Claude Code helps me scan for this kind of doc/signature drift, but i ran the two
TypeErrorcases above myself, diffed each docstring against its ownnb::sigline, and rebuilt to check the strings render before opening this. tell me if any of the rewording should read differently.