-
Notifications
You must be signed in to change notification settings - Fork 25
Open
Labels
Description
Python now allows type hinting assignments, like a: str = "foo". This could be useful for nbparameterise, especially for container types, to tell you what type of elements are expected even if the default is empty. Python 3.9+ supports list[int] on the builtin types; older versions require an object from the typing module, e.g. typing.List[int].
Questions:
- Do we replace/combine with the existing
param.type(which is the type of the default value), or provide both separately? - What (if anything) do we do if the annotation outright contradicts the default value, as in
b: int = "bar"? - How broad a range of annotations should we recognise? As nbparameterise doesn't execute the code itself, it doesn't get them evaluated for free. Only builtins, or also things from the typing module? Union types? Optional? Type aliases? etc.
- How do we present these in the API? Do we try to build the objects as if we had run the code? Or offer our own simpler API for a limited subset? Do we try to normalise them so e.g.
typing.List[int]andlist[int]are the same? - How do we expect use cases like command-line args and web forms to handle looser types, if we support these? E.g. if you have something with an
int | strannotation, what sort of input is expected? And what does the new assignment contain? Does puttingintfirst imply a preference, or areint | strandstr | intthe same? Should the end user have some way to control whether they mean7or"7"?
I'll probably think this over for a while before doing anything.
Zloooy