#griffe — Public Fediverse posts

3D model updated: “Scooter Blinker Button Guard Cap” by xro (@[email protected])

Dark Rap https://zuporouge.com/dark-rap-8/

#dark #rap #horreur #chat #nuit #ombre #griffe #cri #sang #frisson #démon #ténèbres #peur #mystère #hurlement #silhouette #chaos #rage #souffle #hantise #regard #murmure #ruelle #menace #spectre #noirceur #tension #magie #instinct #proie

Griffe is now able to compute source links for objects, pointing to GitHub or other Git services online. See the changelog for v1.14: https://mkdocstrings.github.io/griffe/changelog/#1140-2025-09-05.

#griffe #python #api #git

Gestern habe ich am #Trailbike neue #Griffe von #ESI montiert, weil die Alten inzwischen doch durch waren. Heute habe ich mit dem Lenkerende leicht an einem Baum touchiert und erst später bemerkt, dass es mir dabei den nagelneuen Lenkerstopfen raus gezogen hat. Also vorhin den Müll nach den alten Stopfen durchsucht 🙈

Warum das immer nur passiert, wenn was nagelneu ist 🤔🤷

#MurphysLaw

#Mountainbike #MTB #biken

@[email protected]
@[email protected]
@[email protected]
@[email protected]
@[email protected]
@[email protected]
@[email protected]

Hat zufällig irgendwer eine Idee, was das für ein #Sattel sein könnte, zu dem es wohl auch noch passende #Griffe gibt?

Der Sattel fühlt sich bisher super an.

Ich habe schon gesucht, aber nichts gefunden.

Edit:
Danke für die vielen tollen und schnellen Tipps. Es ist in der Tat ein Modell von NG Sports: "Chaibu ReCycle Race Komfort Sattel" vermutl. aus der #SaltyCactusCollection :-)

https://www.starbike.com/de/ng-sports-chaibu-recycle-race-komfort-sattel-272x143mm-7x7mm-cosmic-schwarz/

Kinda crazy to see #Griffe mentioned as inspiration for the design of #OpenAI's Agents SDK 🤯 Cool to see the SDK's API reference being documented with #mkdoctrings, too 🥰

Next, griffe-pydantic, a #Griffe extension for #Pydantic models:

https://mkdocstrings.github.io/griffe-pydantic/

Next, Griffe TUI, a #Textual user interface for #Griffe:

https://mkdocstrings.github.io/griffe-tui/

We're starting to have a number of #Griffe extensions 🤩 They're all listed here: https://mkdocstrings.github.io/griffe/extensions/official/

I added a few pages to #Griffe's docs: alternative projects, downstream projects, and built-in/official/third-party extensions.

Very cool projects mentioned in there! #Docspec, #pdoc, #papyri, #quartodoc, etc. And I discovered a few Griffe extensions in the process, it's awesome 🤩

- https://mkdocstrings.github.io/griffe/alternatives/
- https://mkdocstrings.github.io/griffe/downstream-projects/
- https://mkdocstrings.github.io/griffe/extensions/built-in/

I think #Griffe is ready for v1. Just one more v0 release to communicate one last deprecation.

I'm marking all the deprecated stuff in #Griffe with #Yore comments.

Yore is a new tool of mine that helps you manage legacy code. You write comments above lines or blocks of code, with a simple grammar for applying transformations once a version is reached (e.g. 1.0.0) or once a minor Python version reaches its End Of Life.

#python #legacy #deprecation #eol #majorbump

I'm adding tests to #Griffe, 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 (#Sphinx-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!

#python #api #docs

I'm completely rewriting #Griffe's docs. Griffe is all about public APIs, so its API docs should be exemplary.

These will be the best docs I've written until now. I've taken inspiration from projects with great documentation: #Hatch, #MaterialforMkDocs and #Textual notably 🙂

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 #API (using #Griffe 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.

#python

Working towards a v1.0 for #Griffe. I will enjoy removing all the legacy code used for backward compatibility 😛

We're not there yet. See the milestone: https://github.com/mkdocstrings/griffe/milestone/1

It's good to be challenged by users.

I was reluctant to add support in #Griffe for some conventions used in the #Python 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 👍

https://github.com/mkdocstrings/python/issues/39#issuecomment-2137083119

Quite the feature in #Griffe: the ability to force using dynamic analysis to extract data from #Python 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)

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 #Griffe 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.

https://github.com/mkdocstrings/griffe/commit/d1696b03a67560a997176d42d07b32395cf723d7

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

https://mkdocstrings.github.io/griffe/best_practices/

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 🙂

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

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

Typically:

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

https://mkdocstrings.github.io/griffe/expressions/#modernization

#Python 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

#Griffe 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.

https://github.com/mkdocstrings/griffe/issues/124#issuecomment-1981072243

#Griffe (Insiders) is now able to search for API breaking changes in #Python packages downloaded from PyPI-like indexes.

https://mkdocstrings.github.io/griffe/checking/#using-pypi

Next version of #Griffe will bring improved support for dataclasses. They are actually a PITA to handle statically 😵 200 LoC + 160 LoC for tests.

https://github.com/mkdocstrings/griffe/pull/240

How are we detecting our public interface contract violations nowaways in #python?

- Only increment the MAJOR part of semver?

#griffe seems like one option but I can't get it to work for the case when I want to treat only my `all` exports as the public interface.

https://github.com/mkdocstrings/griffe/discussions/230

Yesterday I released two new #Insiders features, for #Griffe this time: two different output formats for the `check` command. You can now output in Markdown, useful for changelogs for example, and with GitHub Actions' "annotations" format, which are picked up by GitHub and displayed in the Checks tab and the Files Changed tab.

https://mkdocstrings.github.io/griffe/checking/#markdown

#FastAPI now has proper API docs 🎉 They are built with #mkdocstrings and a #Griffe extension for PEP 727. The PEP was written by @tiangolo himself!

#Cappa puts the finger on what I dislike about #Click: https://cappa.readthedocs.io/en/latest/comparison.html#why-not-click. I'll try Cappa right now in a new project.

I was also strongly tempted by #arguably (https://github.com/treykeown/arguably), but Cappa's use of `Annotated` instead of docstrings makes it super attractive given my recent work on supporting PEP 727 (from @tiangolo) with a #Griffe extension.

I started using pysource-codegen (https://github.com/15r10nk/pysource-codegen) to generate arbitrary but valid Python code to fuzz #Griffe. Great tool!