fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

9.9K
active users

#Griffe

0 posts0 participants0 posts today

I'm adding tests to , that use Griffe to check if:

- all public objects are exposed in the top-level init module
- all public objects are added to the API docs (HTML), and therefore if they are added to the objects inventory (-like objects.inv file)
- if no other object is added to the inventory (no private objects)

Thanks to these tests I made sure not to forget *anything* while rewriting Griffe's docs!

I'm experimenting with moving all my code into a private package, and exposing every public object in the top-level init module of a sibling public package:

- _griffe has all the internal API
- griffe exposes public objects

I added a test to my tests file that loads the internal (using of course 😂) and checks that every "public" name in the internal API is exposed in the public package. Impossible to miss some, and that forces me to privatize the rest.

It's good to be challenged by users.

I was reluctant to add support in for some conventions used in the ecosystem to mark objects as "exported".

To make proper arguments, I had to take a good, serious look at my codebase again. By doing so, I actually identified issues and clear improvements, that once fixed/refactored would allow Griffe to easily support these conventions in a way that makes complete sense 👍

github.com/mkdocstrings/python

GitHubShow __init__ exports · Issue #39 · mkdocstrings/pythonBy JP-Ellis-KPMG

Quite the feature in : the ability to force using dynamic analysis to extract data from packages. Previously it would use static analysis by default and only fallback to dynamic analysis for built-in/compiled modules. Now you can use dynamic analysis for modules with sources available too 🙂

This wasn't an easy change as I thought, but I'm happy how the code evolved.

I've just released v0.45.0. Crossed-fingers for no regressions 🤞 (tests added, but, you know, can't ever be sure)

Replied in thread

Thanks @orsinium. Until now I was fighting this (trying to find out the true parent module), but seeing how inconsistent this is, I give up and will just use what Python gives me.

To give more context: I'm trying to improve the code in that inspects object trees (dynamic analysis). To know whether an object should be added to the currently inspected module as a member or as an alias pointing to somewhere else, I have to check where the object originates from.

github.com/mkdocstrings/griffe

GitHubwip · mkdocstrings/griffe@d1696b0Signatures for entire Python programs. Extract the structure, the frame, the skeleton of your project, to generate API documentation or find breaking changes in your API. - wip · mkdocstrings/griffe@d1696b0
Continued thread

I have published a "best practices" document in 's docs:

mkdocstrings.github.io/griffe/

It says:

- avoid member-submodule name shadowing (the issue described above ☝️)
- avoid wildcard imports
- prefer canonical imports (we recommend @15r10nk's canonical-import tool!)

These recommendations are given from a "static analysis" and "public API" point of view.

I'll gradually add more of these 🙂

mkdocstrings.github.ioBest practices - GriffeSignatures for entire Python programs. Extract the structure, the frame, the skeleton of your project, to generate API documentation or find breaking changes in your API.

(Insiders) just got a new feature: expressions modernization.

It will allow downstream tools like to render type annotations compatible with older Python versions, as if they were using latest features of the language.

Typically:

- typing.Union[int, str] becomes int | str
- typing.Optional[int] becomes int | None
- typing.Set[int] becomes set[int]
- etc.

mkdocstrings.github.io/griffe/

mkdocstrings.github.ioExpressions - GriffeSignatures for entire Python programs. Extract the structure, the frame, the skeleton of your project, to generate API documentation or find breaking changes in your API.

devs, do you often have a submodule and a member with the same name?

For example:

- pkg/__init__.py declares `thing = 1`
- pkg also has a `thing.py` submodule

does not support that and will ignore the member in such cases, giving priority to the submodule. This limitation has been reported multiple times, and I wanted to fix it, but after having worked on it a bit, I'm quite convinced I shouldn't, and instead should say it's bad practice.

github.com/mkdocstrings/griffe

GitHubsubmodules overshadow imports of the same name · Issue #124 · mkdocstrings/griffeBy machow