Remove Python 3.8 support

[dbanty]

Now that 3.8 is EoL, we can finally update to use 3.9's generic syntax!

[johnthagen]

@dbanty I was curious about the need to translate type into type_. Since type is a soft keyword, is this truly neccessary?

• https://peps.python.org/pep-0695/#generic-type-alias

The type keyword is a new soft keyword. It is interpreted as a keyword only in this part of the grammar. In all other locations, it is assumed to be an identifier name.

I think the generated client would be easier to use if we kept fields named type as type? But perhaps I'm missing a bigger reason why this was done?

---

Edit: Oh, I see you are using the type built in. Are there reasons why the built in conflicts with a field named type (I haven't personally run into builtins conflicting like this before, especially since fields are typically accessed through self.type or cls.type).

If this really must be done, I'd personally advocate for using the old Type and keeping the fields named without underscores as they are in OpenAPI since the change to type_ affects all users of models that happen to use this name (which I suspect is somewhat common).

[eli-bl]

@johnthagen I may be off base but I think the issue may not be specifically the presence of a class attribute with that name, but instead, the fact that the generated from_dict and to_dict methods end up creating a local variable with that name. I'm less clear on the exact circumstances in which that would cause a conflict; I know it's possible to reuse built-ins as variable names in some situations. But I know there have been other situations in this project where certain property names couldn't be used even when they were not built-ins, because something else in the scope had that name.

If that is the issue... I think everyone would agree that moving away from that local-variable-naming scheme would be helpful, but it's non-trivial due to the way template macros are being used (at least in the case of from_dict; I do have a solution for to_dict).

[dbanty]

@eli-bl is correct. The better solution would be to change the local variable naming, but it's a much bigger change.

Sticking with Type causes popular linters to scream, and I don't want to litter the generated code with exceptions.

type specifically causes so many conflicts in so many languages 😭. If you have control over the API I recommend kind

[johnthagen]

I know it's possible to reuse built-ins as variable names in some situations

Yeah, Python supports shadowing at all levels, so locals will shadow built-ins within the scope they are declared. Shadowing typically makes this not a problem (otherwise lots of builtin names would need to be avoided).

• https://docs.python.org/3/library/functions.html

A trivial example:

defmain(a: type[int]) ->str:
type=str(a)
returntypeprint(main(int))
# prints: <class 'int'>