tapify does not work with `from __future__ import annotations.`

[UshioA]

When the file where the class is defined has from __future__ import annotations, and the class have type hints on its __init__ function, tapify will throw ValueError: 'str' is not callable.

My Python version is Python 3.12.4. Tap version is 1.11.0.

Examples:

This will work fine:

# main.py
class Driver:
  def __init__(self, a: str):
    self.a = a

  def run(self):
    pass


def main():
  from tap import tapify

  tapify(Driver).run()


if __name__ == "__main__":
  main()

Running python main.py will correctly show help messages.

This will throw an error:

# main.py
from __future__ import annotations


class Driver:
  def __init__(self, a: str):
    self.a = a

  def run(self):
    pass


def main():
  from tap import tapify

  tapify(Driver).run()


if __name__ == "__main__":
  main()

Running python main.py results in this:

Traceback (most recent call last):
  File "/***/main.py", line 19, in <module>
    main()
  File "/***/main.py", line 15, in main
    tapify(Driver).run()
    ^^^^^^^^^^^^^^
  File "/***/.venv/lib/python3.12/site-packages/tap/tapify.py", line 344, in tapify
    tap = tap_class(description=description, explicit_bool=explicit_bool, underscores_to_dashes=underscores_to_dashes)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/***/.venv/lib/python3.12/site-packages/tap/tap.py", line 112, in __init__
    self._configure()
  File "/***/.venv/lib/python3.12/site-packages/tap/tapify.py", line 292, in _configure
    super()._configure()
  File "/***/.venv/lib/python3.12/site-packages/tap/tap.py", line 352, in _configure
    self._add_arguments()
  File "/***/.venv/lib/python3.12/site-packages/tap/tap.py", line 312, in _add_arguments
    self._add_argument(*name_or_flags, **kwargs)
  File "/***/.venv/lib/python3.12/site-packages/tap/tap.py", line 292, in _add_argument
    super(Tap, self).add_argument(*name_or_flags, **kwargs)
  File "/***/lib/python3.12/argparse.py", line 1482, in add_argument
    raise ValueError('%r is not callable' % (type_func,))
ValueError: 'str' is not callable

[martinjm97]

Hi @UshioA,

Thank you for the bug report! Since from __future__ import annotations delays evaluation of annotations,

typed-argument-parser/src/tap/tapify.py

Line 285 in 2e18dc8

self._annotations[variable] = str if arg_data.annotation is Any else arg_data.annotation

returns the string of the name of the type 'int' instead of the type int. While one can cast the string type to the type (e.g., using get_type_hints), applying this cast in all cases, might result in unexpected behavior, where a user has a valid (but maybe silly) type 'int' and then Tap correctly crashes because it can't cast to the type 'int' (e.g., with TypeError: 'int' is not callable). If instead, we use the result of get_type_hints, the user will get an int (maybe that's what they wanted, maybe not?).

For our future reference, the change would be to the processing of arg data. For example, in

typed-argument-parser/src/tap/tapify.py

Line 177 in 2e18dc8

def _tap_data_from_class_or_function(

In conclusion, we're not totally sure whether it's reasonable to change tap's default behavior of crashing on string arguments and we'd like to support specifically the case of from __future__ import annotations, but we don't see a robust way to exclusively support this case.

We'll keep thinking about it; let us know if you have any suggestions!

Thanks again,
JK

[UshioA]

where a user has a valid (but maybe silly) type 'int' and then Tap correctly crashes because it can't cast to the type 'int' (e.g., with TypeError: 'int' is not callable). If instead, we use the result of get_type_hints, the user will get an int (maybe that's what they wanted, maybe not?).

The case you’re referring to seems to be when a user writes something like:

class MyClass:
    def __init__(self, mode: 'int' = 'int'):
        ...

In this example, the user might have intended the type of mode to be Literal['int'], or they may simply have made a mistake — perhaps mode was supposed to be of type str or int. Since mistakes can happen in both the annotation and the default value, using get_type_hints here would silently change the behavior of the user’s code, which tapify might want to avoid.

My intuition is that users rarely make mistakes in both the type annotation and the default value. If they do, it’s practically impossible to tell such cases apart from intentional ones. Therefore, tapify could perform a sanity check by comparing each annotation’s evaluated type with the type of its corresponding default value, and reject the class if there’s a mismatch. Even without such a check, tapify would still fail to process a class like this when no argument is provided, since the type int cannot accept the default value "int".

For example, the following code:

# driver.py
class Driver:
    def __init__(self, name: int = "int", license_number: str = "str"):
        self.name = name
        self.license_number = license_number

    def display_info(self):
        return f"Driver Name: {self.name}, License Number: {self.license_number}"

# main.py
from driver import Driver
from tap import tapify

def main():
    print(tapify(Driver).display_info())

if __name__ == "__main__":
    main()

would fail when run with python main.py or python main.py --name placeholder, and only succeed with python main.py --name 100. This is enough to alert the user that something is wrong.

When no default value is provided for a parameter (like mode), there’s no additional information to infer the user’s intent, so it might be fine to just rely on get_type_hints in that case.

[Daraan]

Providing the globals / locals from the owner to get_type_hints might be the key to get the type hint the user intended (at least the one that type-checkers would pick up from the scope).