You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It can be useful in combination with mkdocstrings-python and custom templates, to iterate over object values or their attributes that couldn't be loaded by Griffe itself (for example, objects built dynamically and loaded as attributes won't have "members" to iterate over).
Copy file name to clipboardExpand all lines: docs/guide/contributors/architecture.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,7 +23,7 @@ descriptions = {
23
23
"site": "Documentation site, built with `make run mkdocs build` (git-ignored).",
24
24
"src": "The source of our Python package(s). See [Sources](#sources) and [Program structure](#program-structure).",
25
25
"src/griffe": "Our public API, exposed to users. See [Program structure](#program-structure).",
26
-
"packages/griffelib/src/griffelib/_internal": "Our internal API, hidden from users. See [Program structure](#program-structure).",
26
+
"packages/griffelib/src/griffe/_internal": "Our internal API, hidden from users. See [Program structure](#program-structure).",
27
27
"tests": "Our test suite. See [Tests](#tests).",
28
28
".copier-answers.yml": "The answers file generated by [Copier](https://copier.readthedocs.io/en/stable/). See [Boilerplate](#boilerplate).",
29
29
"devdeps.txt": "Our development dependencies specification. See [`make setup`][command-setup] command.",
@@ -104,11 +104,11 @@ Sources are located in the `src` folder, following the [src-layout](https://pack
104
104
105
105
Our test suite is located in the `tests` folder. It is located outside of the sources as to not pollute distributions (it would be very wrong to publish a `tests` package as part of our distributions, since this name is extremely common), or worse, the public API. The `tests` folder is however included in our source distributions (`.tar.gz`), alongside most of our metadata and configuration files. Check out `pyproject.toml` to get the full list of files included in our source distributions.
106
106
107
-
The test suite is based on [pytest](https://docs.pytest.org/en/8.2.x/). Test modules reflect our internal API structure, and except for a few test modules that test specific aspects of our API, each test module tests the logic from the corresponding module in the internal API. For example, `test_finder.py` tests code of the `griffelib._internal.finder` internal module, while `test_functions` tests our ability to extract correct information from function signatures, statically. The general rule of thumb when writing new tests is to mirror the internal API. If a test touches to many aspects of the loading process, it can be added to the `test_loader` test module.
107
+
The test suite is based on [pytest](https://docs.pytest.org/en/8.2.x/). Test modules reflect our internal API structure, and except for a few test modules that test specific aspects of our API, each test module tests the logic from the corresponding module in the internal API. For example, `test_finder.py` tests code of the `griffe._internal.finder` internal module, while `test_functions` tests our ability to extract correct information from function signatures, statically. The general rule of thumb when writing new tests is to mirror the internal API. If a test touches to many aspects of the loading process, it can be added to the `test_loader` test module.
108
108
109
109
## Program structure
110
110
111
-
The internal API is contained within the `packages/griffelib/src/griffelib/_internal` folder. The top-level `griffe/__init__.py` module exposes all the public API, by importing the internal objects from `griffelib`, which itself imports from various submodules of `griffelib._internal`.
111
+
The internal API is contained within the `packages/griffelib/src/griffe/_internal` folder. The top-level `griffe/__init__.py` module exposes all the public API, by importing the internal objects from various submodules of `griffe._internal`.
112
112
113
113
Users then import `griffe` directly, or import objects from it.
114
114
@@ -122,7 +122,7 @@ if os.getenv("DEPLOY") == "true":
@@ -226,13 +226,13 @@ The above exception was the direct cause of the following exception:
226
226
227
227
Traceback (most recent call last):
228
228
File "<stdin>", line 1, in <module>
229
-
File "griffelib/_internal/dataclasses.py", line 1310, in target
229
+
File "griffe/_internal/dataclasses.py", line 1310, in target
230
230
self.resolve_target()
231
-
File "griffelib/_internal/dataclasses.py", line 1369, in resolve_target
231
+
File "griffe/_internal/dataclasses.py", line 1369, in resolve_target
232
232
self._resolve_target()
233
-
File "griffelib/_internal/dataclasses.py", line 1377, in _resolve_target
233
+
File "griffe/_internal/dataclasses.py", line 1377, in _resolve_target
234
234
raise AliasResolutionError(self) from error
235
-
griffelib._internal.exceptions.AliasResolutionError: Could not resolve alias package2.X pointing at package1.X (in package2/__init__.py:1)
235
+
griffe._internal.exceptions.AliasResolutionError: Could not resolve alias package2.X pointing at package1.X (in package2/__init__.py:1)
236
236
```
237
237
238
238
As you can see in the interpreter session above, Griffe did not resolve the `X` alias. When we tried to access its target object anyway, it failed with a `KeyError`, which was raised again as an [`AliasResolutionError`][griffe.AliasResolutionError].
@@ -250,7 +250,7 @@ False # Hmm?
250
250
>>> package2["X"].target
251
251
Traceback (most recent call last):
252
252
...
253
-
griffelib._internal.exceptions.AliasResolutionError: Could not resolve alias package2.X pointing at package1.X (in package2/__init__.py:1)
253
+
griffe._internal.exceptions.AliasResolutionError: Could not resolve alias package2.X pointing at package1.X (in package2/__init__.py:1)
254
254
```
255
255
256
256
The same exception again? What happened here? We loaded both packages, but Griffe still failed to resolve the alias. That is expected; here is the explanation.
However deep the object is, Griffe loads the entire package. It means that in all the cases above, Griffe loaded the whole `markdown` package. The model instance Griffe gives you back is therefore part of a tree that you can navigate.
@@ -41,7 +41,7 @@ To access an object's members, there are a few options:
41
41
42
42
```pycon
43
43
>>> import griffe
44
-
>>> markdown = griffelib.load("markdown")
44
+
>>> markdown = griffe.load("markdown")
45
45
>>> markdown.members["Markdown"]
46
46
Alias('Markdown', 'markdown.core.Markdown')
47
47
>>> markdown.members["core"].members["Markdown"]
@@ -54,7 +54,7 @@ To access an object's members, there are a few options:
54
54
55
55
```pycon
56
56
>>> import griffe
57
-
>>> markdown = griffelib.load("markdown")
57
+
>>> markdown = griffe.load("markdown")
58
58
>>> markdown["core"]["Markdown"] # chained access
59
59
Class('Markdown', 46, 451)
60
60
>>> markdown["core.Markdown"] # merged access
@@ -65,7 +65,7 @@ To access an object's members, there are a few options:
65
65
66
66
```pycon
67
67
>>> import griffe
68
-
>>> markdown = griffelib.load("markdown")
68
+
>>> markdown = griffe.load("markdown")
69
69
>>> markdown[("core", "Markdown")] # tuple access
70
70
Class('Markdown', 46, 451)
71
71
>>> # Due to the nature of the subscript syntax,
@@ -78,7 +78,7 @@ To access an object's members, there are a few options:
78
78
79
79
```pycon
80
80
>>> import griffe
81
-
>>> markdown = griffelib.load("markdown")
81
+
>>> markdown = griffe.load("markdown")
82
82
>>> markdown.get_member("core.Markdown")
83
83
Class('Markdown', 46, 451)
84
84
```
@@ -122,7 +122,7 @@ If a base class cannot be resolved during computation of inherited members, Grif
122
122
123
123
If you want to access all members at once (both declared and inherited), use the [`all_members`][griffe.Object.all_members] attribute. If you want to access only declared members, use the [`members`][griffe.Object] attribute.
124
124
125
-
Accessing the [`attributes`][griffe.Object.attributes], [`functions`][griffe.Object.functions], [`classes`][griffe.Object.classes], [`type_aliases`][griffe.Object.type_aliases] or [`modules`][griffe.Object.modules] attributes will trigger inheritance computation, so make sure to only access them once everything is loaded by griffelib. Don't try to access inherited members in extensions, while visiting or inspecting modules.
125
+
Accessing the [`attributes`][griffe.Object.attributes], [`functions`][griffe.Object.functions], [`classes`][griffe.Object.classes], [`type_aliases`][griffe.Object.type_aliases] or [`modules`][griffe.Object.modules] attributes will trigger inheritance computation, so make sure to only access them once everything is loaded by griffe. Don't try to access inherited members in extensions, while visiting or inspecting modules.
126
126
127
127
#### Limitations
128
128
@@ -254,7 +254,7 @@ from pkg2 import A as B
254
254
255
255
```pycon
256
256
>>> import griffe
257
-
>>> B =griffelib.load("pkg1.B")
257
+
>>> B =griffe.load("pkg1.B")
258
258
>>> B.path
259
259
'pkg1.B'
260
260
>>> B.canonical_path
@@ -339,13 +339,13 @@ Each object has an optional [`docstring`][griffe.Object.docstring] attached to i
339
339
340
340
Docstrings can be parsed against several [docstring-styles](../../reference/docstrings.md), which are micro-formats that allow documenting things such as parameters, returned values, raised exceptions, etc..
341
341
342
-
When loading a package, it is possible to specify the docstring style to attach to every docstring (see the `docstring_parser` parameter of [`griffelib.load`][griffe.load]). Accessing the [`parsed`][griffe.Docstring.parsed] field of a docstring will use this style to parse the docstring andreturn a list of [docstring sections][advanced-api-sections]. Each section has a `value` whose shape depends on the section kind. For example, parameter sections have a list of parameter representations as value, while a text section only has a string as value.
342
+
When loading a package, it is possible to specify the docstring style to attach to every docstring (see the `docstring_parser` parameter of [`griffe.load`][griffe.load]). Accessing the [`parsed`][griffe.Docstring.parsed] field of a docstring will use this style to parse the docstring andreturn a list of [docstring sections][advanced-api-sections]. Each section has a `value` whose shape depends on the section kind. For example, parameter sections have a list of parameter representations as value, while a text section only has a string as value.
343
343
344
344
After a package is loaded, it is still possible to change the style used for specific docstrings by either overriding their [`parser`][griffe.Docstring.parser] and [`parser_options`][griffe.Docstring.parser_options] attributes, or by calling their [`parse()`][griffe.Docstring.parse] method with a different style:
Copy file name to clipboardExpand all lines: docs/introduction.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,10 +22,10 @@ Both commands accept a `-h`, `--help` argument to show all the available options
22
22
23
23
## Python library
24
24
25
-
As a library, Griffe exposes all its public API directly in the top-level module. It means you can simply import `griffe`or `griffelib`to access all its API.
25
+
As a library, Griffe exposes all its public API directly in the top-level module. It means you can simply import `griffe` to access all its API.
0 commit comments