Open divad opened 1 year ago
Hi @divad thanks for your feedback. This is an interesting bug.
Underneath get_type_hints uses .annotations which appears to already have the types spectree needs. Thus I wonder if spectree could use that rather than get_type_hints, thus sidestepping the issue. WDYT?
From the get_type_hint
doc:
This is often the same as obj.annotations, but it handles forward references encoded as string literals, adds Optional[t] if a default value equal to None is set and recursively replaces all 'Annotated[T, ...]' with 'T' (unless 'include_extras=True').
Usually, get_type_hint
should be a better choice. But we didn't expect this bug. So far, I don't have a better idea. Will take a deep look later.
Describe the bug
Hey :) This isn't strictly a bug in Spectree but I wanted to raise it nonetheless (see below as to why).
The combination of Spectree, annotations mode and Flask's ResponseReturnValue does not work:
The cause is this bug in Python: https://bugs.python.org/issue43463
The tl;dr is: spectree calls
get_type_hints
, that in turn evaluates the function's return type, in this case Flask'sResponseReturnValue
, this refers to aResponse
class, but it is done so via a string:The
Response
class is not imported at runtime, it's behind aTYPE_CHECKING
guard:Thus, Spectree's annotations feature won't work if the function has a type hint where one of the constituent parts is only imported behind
TYPE_CHECKING
. The python bug doesn't appear as if it will have a resolution any time soon, sadly.I am not very experienced with python typing, but, I wonder if spectree should be using
get_type_hints
. Underneathget_type_hints
uses.__annotations__
which appears to already have the types spectree needs. Thus I wonder if spectree could use that rather thanget_type_hints
, thus sidestepping the issue. WDYT?p.s many thanks for creating and maintaining spectree <3
To Reproduce
Expected behavior
Spectree/Flask starts up
The spectree version
Linux efeb38394e42 6.3.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 11 May 2023 16:40:42 +0000 x86_64 GNU/Linux
Python 3.11.3
Additional context
No response