Consider supporting older Python versions?

[kytta]

Hello! Firstly, thank you for this package. I really like it and I want to use it in a project I'm developing.

The project I work on has the minimal Python version of 3.7 (currently the lowest supported version), but your package uses the version 3.9. Hence, my question: would you consider “downgrading” your project to also support Python 3.7 and 3.8? I understand, that you may not want to do this, and it's fine! I could do all the work myself. If you do not want to maintain older Python version at all, it's fine too: I would then fork it and do it on my end. Thanks!

[SupImDos]

Hi @kytta,

Thanks very much 😀

That's a great point, especially since pydantic itself currently supports Python >=3.7. I think it makes sense for us to at least support the same versions that pydantic does.

I'm in the process of moving throughout January, so I'm not sure if I'll be able to commit enough time to this at the moment. If you felt like having a go at the backport then I'm happy to take a look and merge it in eventually.

Off the top of my head I can't think of any issues with supporting 3.7 / 3.8. Some thoughts below:

1. All of the subscripted builtin/generic types (e.g., list[T], dict[K, V], etc) will have to be changed back to the pre-PEP-585 ones (e.g., typing.List[T], typing.Dict[K, V], etc.).
2. The development dependencies might have to be downgraded or handled in a different way? TBD.

I'll do my best to look into this if I get time too.

Thanks!

[kytta]

I'm in the process of moving throughout January, so I'm not sure if I'll be able to commit enough time to this at the moment. If you felt like having a go at the backport then I'm happy to take a look and merge it in eventually.

No worries, it's not a time issue for my project, either. I will try to run pydantic-argparse on Python 3.7 in the next days, I don't think it should be that problematic.

1. All of the subscripted builtin/generic types (e.g., list[T], dict[K, V], etc) will have to be changed back to the pre-PEP-585 ones (e.g., typing.List[T], typing.Dict[K, V], etc.).

Not really. We can use from __future__ import annotations, it's an official backport of PEP-585 for the older Python versions. With this one import, we can continue using list and dict

[SupImDos]

Not really. We can use from __future__ import annotations, it's an official backport of PEP-585 for the older Python versions. With this one import, we can continue using list and dict.

As far as I can tell the from __future__ import annotations backport still doesn't allow the subscripting of types at runtime (only in type annotations).

Python 3.7

>>> from __future__ import annotations
>>> a: list = [1, 2, 3]
>>> b: list[int] = [1, 2, 3]
>>> c = list
>>> d = list[int]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'type' object is not subscriptable

Python 3.9+

>>> a: list = [1, 2, 3]
>>> b: list[int] = [1, 2, 3]
>>> c = list
>>> d = list[int]

I think this is only used when parameterizing the unit tests (e.g., https://github.com/SupImDos/pydantic-argparse/blob/master/tests/argparse/test_parser.py#L106) so it probably doesn't matter too much, but some changes would be required there.

Some more possible incompatibilities I found:

1. typing.Literal, typing.get_origin() and typing.get_args() don't exist yet, so we would have to pull in typing-extensions as a dependency. Might also have some implications on the documentation for using Literal typed arguments.
2. importlib.metadata doesn't exist yet, so we would have to pull in importlib-metadata
   as a dependency. There seems to be some sort of clash in dependency versions here when I try and install it too.
3. argparse.BooleanOptionalAction doesn't exist yet, so we would probably have to backport it ourselves.
4. argparse.ArgumentParser(exit_on_error=...) doesn't exist yet. Not sure what to do about this one.

[kytta]

Not really. We can use from __future__ import annotations, it's an official backport of PEP-585 for the older Python versions. With this one import, we can continue using list and dict.

As far as I can tell the from __future__ import annotations backport still doesn't allow the subscripting of types at runtime (only in type annotations).

Yep, you're right. We have to use typing imports.

1. `typing.Literal`, `typing.get_origin()` and `typing.get_args()` don't exist yet, so we would have to pull in [`typing-extensions`](https://pypi.org/project/typing-extensions/) as a dependency. Might also have some implications on the documentation for using `Literal` typed arguments.

2. `importlib.metadata` doesn't exist yet, so we would have to pull in [`importlib-metadata`
   ](https://pypi.org/project/importlib-metadata/) as a dependency. There seems to be some sort of clash in dependency versions here when I try and install it too.

Started to tackle this in #37 (wow, what a number!)

3. [`argparse.BooleanOptionalAction`](https://docs.python.org/3/library/argparse.html) doesn't exist yet, so we would probably have to backport it ourselves.

4. [`argparse.ArgumentParser(exit_on_error=...)`](https://docs.python.org/3/library/argparse.html#exit-on-error) doesn't exist yet. Not sure what to do about this one.

Haven't got to this yet, but fair point as well.

[SupImDos]

Once I do a release for v0.7.0 this can be closed

[SupImDos]

Closed in #37, released in v0.7.0 (PyPI) - Thanks again @kytta