Making lengthy types legible in editors
I have encountered the following legibility problem in two libraries that I work on. I will: - describe the issue I am facing - ask for guidance - describe a hack that I have played with & my ideal-solution THE PROBLEM ----------- One of the parameters in my most used, user-facing functions has a "lengthy" annotation; e.g. _T = TypeVar("_T", bound=Callable) Wrapper = Callable[[_T], _T] ValidWrapper = A[Wrapper] | B[Wrapper] | C[Wrapper] | Wrapper | None | str def my_func(x: ValidWrapper | Sequence[ValidWrapper]): ... Viewing the signature of `my_func` in, via tooltip, in IPython, Jupyter, VSCode, or PyCharm reveals an absolute mess. Consider that A, B, and C are generics that are defined in a deeply-nested module of my library and their paths are included in the signature... You can see screenshots from these editors here: https://github.com/mit-ll-responsible-ai/hydra-zen/pull/125 This legibility issue is a major concern to me. Some of my users (including high school students) are rightfully bewildered when they bring up the signature in their editor via a tooltip (or Shift+Tab in Jupyter). However, accurate annotations are obviously important to help to guide them away from making mistakes. GUIDANCE -------- Does anyone have any advice for dealing with this legibility issue? Is there a mechanism in typing that I have overlooked? It occurs to me (as I write this) that perhaps moving to type-stubs could circumvent this. MY ATTEMPT AT A SOLUTION ------------------------ The ideal solution that I can think of is something with the form-factor MyType = Alias("MyType", true_type=ActualType) Where MyType is exactly the same as ActualType, but it provides a string field (that returns "MyType" here), that editors/tools can hook into to inform how they print the type - a purely aesthetic mechanism. I have attempted to experiment with NewType, Alias, and TypeVar to see if I could manage this legibility issue with the current typing capabilities. I have one hack that cleans up the experience for Jupyter users: if TYPE_CHECKING: ValidWrapper = # Actual, correct annotation else: ValidWrapper = TypeVar("ValidWrapper") This coerces Juptyer to render the annotation as `Union[~ValidWrapper , Sequence[~ValidWrapper ]]`. Clearly, this is an abuse of TypeVar, and I am generally not happy with this approach. It also has no improvement for VSCode and PyCharm. Thank you for your time! Ryan Soklaski
Maybe I'm misunderstanding, but are you just looking for a type alias? You should be able to write something like: MyType = Union[Some, Very, Long, Type] At least in VS Code (with Pylance/pyright), we'll show the alias name when it's used rather than expanding it out (only expanding it out when you hover over the alias itself so you can see what's in it). In Pylance, we have issues related to the size of the tooltips and are working on ways to better format things like functions with many, many parameters or overloads (but, are largely limited by what's currently available within the LSP / VS Code APIs).
(And if there's a condition under which we are showing the whole type and not the alias for reason, that sounds like a bug and we'd love an issue.)
Thanks for the quick reply, Jake. I will open an issue - I am using a type alias here. Pylance behaved nicely when I hit this issue in another situation, but it is being verbose in this latest encounter. For the Jupyter notebook/lab editors, I do not think that they have enough context to infer the alias' name. But perhaps I am wrong, and this is a capability that they can develop.
PyCharm has an issue tracking this: https://youtrack.jetbrains.com/issue/PY-42486 On Thu, Oct 7, 2021, 1:07 PM <rsoklaski@gmail.com> wrote:
Thanks for the quick reply, Jake. I will open an issue - I am using a type alias here. Pylance behaved nicely when I hit this issue in another situation, but it is being verbose in this latest encounter.
For the Jupyter notebook/lab editors, I do not think that they have enough context to infer the alias' name. But perhaps I am wrong, and this is a capability that they can develop. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: dustin.wyatt@gmail.com
Thanks for this, Dustin. In case your are interested, here is the Pylance issue that I filed: https://github.com/microsoft/pylance-release/issues/1914
participants (3)
-
Dustin Wyatt
-
Jake Bailey
-
rsoklaski@gmail.com