-
Notifications
You must be signed in to change notification settings - Fork 2
Enable Sphinx configuration caching #570
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
Labels
enhancement
New feature or request
Comments
Blocked by #664, pending next major Sphinx release |
tm91236
added a commit
that referenced
this issue
Mar 31, 2025
By removing the `typehints_formatter` we are able to resolve issues #570 and #734. The former issue is resolved by removing the non-picklable function, which enables build caching, and the second is solved by removing the `TypeVar` bound replacement. While the `TypeVar` replacement does provide more concise documentation, it removes a key piece of information, which the reader must be aware of. For example, in: ```python T = TypeVar("T", bound=Data) def typevar(a: T, b: T) -> None: ... def bound(a: Data, b: Data): ... def valid(a: SupervisedData, b: SupervisedData): ... def invalid(a: Data, b: SupervisedData): ... ``` the `typevar` function is the actual specification, `bound` is the documented specification, `valid` is a valid specification, and `invalid` is an invalid specification which is presented as valid in the documentation (if we replace the `TypeVar` with the bound). As an additional comment, we do now lose the functionality of the `autodoc_custom_types` -- it should be noted that the `ArrayLike` custom type (the only listed custom type) doesn't appear to be used anywhere in the codebase.
tm91236
added a commit
that referenced
this issue
Mar 31, 2025
By removing the `typehints_formatter` we are able to resolve issues #570 and #734. The former issue is resolved by removing the non-picklable function, which enables build caching, and the second is solved by removing the `TypeVar` bound replacement. While the `TypeVar` replacement does provide more concise documentation, it removes a key piece of information, which the reader must be aware of. For example, in: ```python T = TypeVar("T", bound=Data) def typevar(a: T, b: T) -> None: ... def bound(a: Data, b: Data): ... def valid(a: SupervisedData, b: SupervisedData): ... def invalid(a: Data, b: SupervisedData): ... ``` the `typevar` function is the actual specification, `bound` is the documented specification, `valid` is a valid specification, and `invalid` is an invalid specification which is presented as valid in the documentation (if we replace the `TypeVar` with the bound). As an additional comment, we do now lose the functionality of the `autodoc_custom_types` -- it should be noted that the `ArrayLike` custom type (the only listed custom type) doesn't appear to be used anywhere in the codebase. Refs: #570, #734
9 tasks
tm91236
added a commit
that referenced
this issue
Mar 31, 2025
By removing the `typehints_formatter` we are able to resolve issues #570 and #734. The former issue is resolved by removing the non-picklable function, which enables build caching, and the second is solved by removing the `TypeVar` bound replacement. While the `TypeVar` replacement does provide more concise documentation, it removes a key piece of information, which the reader must be aware of. For example, in: ```python T = TypeVar("T", bound=Data) def typevar(a: T, b: T) -> None: ... def bound(a: Data, b: Data): ... def valid(a: SupervisedData, b: SupervisedData): ... def invalid(a: Data, b: SupervisedData): ... ``` the `typevar` function is the actual specification, `bound` is the documented specification, `valid` is a valid specification, and `invalid` is an invalid specification which is presented as valid in the documentation (if we replace the `TypeVar` with the bound). As an additional comment, we do now lose the functionality of the `autodoc_custom_types` -- it should be noted that the `ArrayLike` custom type (the only listed custom type) doesn't appear to be used anywhere in the codebase. Refs: #570, #734
9 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What's the new feature?
Properly handle #561 to permit caching.
What value does this add?
Allows proper caching.
Is there an alternative you've considered?
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: