Skip to content
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

feat: Add initial restructured text docstirng parsing #71

Merged
merged 6 commits into from Nov 28, 2020

Conversation

plannigan
Copy link
Contributor

This implementation should be mostly complete.

Not implemented:

  • references: Not planned at this time
  • examples: I'm not aware of a standard format for this

Still needed:

  • more test:
    • Many of the error cases aren't currently covered
    • More full fixture test cases

To be cleaned up:

  • I'm not confident I got the types right for all of the data that comes in with the context
  • ParseContext works, but it is a bit awkward with the rest of the project using the dict

References: #67

This implementation should be mostly complete.

Not implemented:
 - references: Not planned at this time
 - examples: I'm not aware of a standard format for this

Still needed:
 - more test:
   - Many of the error cases aren't currently covered
   - More full fixture test cases

To be cleaned up:
 - I'm not confident I got the types right for all of the data that comes in with the context
 - ParseContext works, but it is a bit awkward with the rest of the project using the dict

References: mkdocstrings#67
@plannigan
Copy link
Contributor Author

The PR still ended up being fairly big. Holding off on one of the main directives wouldn't have reduced the line count much. This seemed like a good stopping point to get something up for review. Subsequent PRs will be much smaller.

@pawamoy
Copy link
Member

pawamoy commented Oct 23, 2020

Hello! Sorry for the delay, I've been quite busy 🙂

Thank you very much for this PR! I'm sure a lot of people will like it.
I'll start reviewing now.

@plannigan
Copy link
Contributor Author

As a heads up, I tried using this implementation against a real project and it was not getting the signature of functions, so parameters were not displaying their type or kind correctly. I followed the same pattern used for the google format for parsing in the unit tests. But I might have missed something related to the context dictionary. So keep an eye of for that even though all of the unit tests currently pass.

Copy link
Member

@pawamoy pawamoy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm a bit too tired to read all that code closely 😅

But with a quick look I can tell the code is clean, you added comments to explain things, so LGTM.

Just a nitpick about the helpers in the test file.

About the signature of functions not being passed, maybe you could try to write a test that is actually loading an object, to see how it behaves from A to Z. I started thinking about the code structure, hopefully I'll find some time to improve it so it will be more straight-forward and easier to reason about.

Comment on lines 679 to 699
def assert_parameter_equal(actual: Parameter, expected: Parameter) -> None:
assert actual.name == expected.name
assert_annotated_obj_equal(actual, expected)
assert actual.kind == expected.kind
assert actual.default == expected.default


def assert_attribute_equal(actual: Attribute, expected: Attribute) -> None:
assert actual.name == expected.name
assert_annotated_obj_equal(actual, expected)


def assert_annotated_obj_equal(actual: AnnotatedObject, expected: AnnotatedObject) -> None:
assert actual.annotation == expected.annotation
assert actual.description == expected.description


def get_rst_object_documentation(dotted_fixture_subpath) -> Object:
return Loader(docstring_style="restructured-text").get_object_documentation(
f"tests.fixtures.parsing.restructured_text.{dotted_fixture_subpath}"
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you move these helpers at the top of the file? I find it less confusing, and we'll be able to add test at the end without having to think about pushing the helpers further down.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. I generally do it with the helper functions at the end, but it doesn't matter much. Another option would be to implement __eq__() on the section detail objects, This would allow for assert sections[1].value == [EXPECTED_PARAM]. I opted not to do that to keep my PR more self-contained without making changes to the other structures.

@pawamoy
Copy link
Member

pawamoy commented Oct 23, 2020

Oh, it would also be really great if you could update the README 🙂

@plannigan
Copy link
Contributor Author

I was able to track down there error in my code related to the context. (A helper function in the google test suite passes the signature and type in as part of the context. However, the main source code only ever passes in obj and optionally attributes. I altered the helper function to be similar to what the main source does.)

I also added more test cases complete coverage.

@plannigan
Copy link
Contributor Author

Wanted to check back in. Is there anything else you would like me to add to this PR before it can be merged?

@pawamoy
Copy link
Member

pawamoy commented Nov 27, 2020

Hello! I've been lacking time and energy... but I'll try to give a final review tomorrow 🙂

@pawamoy pawamoy merged commit 0b58c8d into mkdocstrings:master Nov 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants