Skip to content

Use type hints? #29

@takluyver

Description

@takluyver

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] and list[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 | str annotation, what sort of input is expected? And what does the new assignment contain? Does putting int first imply a preference, or are int | str and str | int the same? Should the end user have some way to control whether they mean 7 or "7"?

I'll probably think this over for a while before doing anything.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions