Next release will have breaking changes

[pawamoy]

Next release (v0.33) will contain a refactor of expressions, see #194.

We will take care of releasing a version of mkdocstrings-python with an upper bound on griffe<0.33 before the actual Griffe release.

For projects depending directly on Griffe, here are the pending breaking changes:

• griffe.expressions.Name is removed in favor of griffe.expressions.ExprName
• griffe.expressions.Expression is removed in favor of griffe.expressions.Expr and all its subclasses

If you were using expressions directly, you might want to add a temporary upper bound on Griffe too. Once the new version is released you'll be able to check out the API reference in the docs.

[pawamoy]

Mentioning @machow because you're the only one I know using Griffe directly 😄

[machow]

Thanks for the heads up! If I understand correctly, is the idea of this PR (#194) that expressions will model more than just annotations? It looks like they're being ramped up to represent most python expressions (and represent annotations with more granularity). Does that sound right?

[pawamoy]

Yes, we will now parse attribute values, decorators and class bases as expressions as well (previously it was only for type annotations). Also, previously expressions were lists of strings and names, now they're actual instances of classes with proper attributes. For example an annotation or value which is a subscript will have a left attribute as well as a slice attribute. It makes it easier to access the slice part, while before we had to access elements using their index, which was extremely prone to index errors.

[pawamoy]

Griffe 0.33 was released. mkdocstrings-python 1.3.0 rejects it, and v1.4.0 will support it.