I love these :). I remember back in uni I would fill my program with them, but then fail the autograder because they were using an older version of Python 3 (support was only added in 3.5). I also remember back when the system didn't even have support for self-hoisting, so you couldn't make recursive type definitions and would have to do string annotations like `(x: 'LinkedListNode')`. Fun times.
Assuming that strongly typing the library in some way is beneficial (which we believed), let's look into the options we're provided here. Python's current type hint system requires external tools to enforce it and isn't enforced at runtime or "compilation." The system we have in our library creates a ton of objects that end up enforcing runtime constraints on input values. Failing at runtime because of invalid input is good. I've worked on Python stacks that totally do not use type hints (and my Emacs setup probably didn't back then either), and would have been saved tons of time debugging if the library just told me I was doing things wrong. This is at a definite cost of verbosity. There are definitely ways we can cut verbosity in this model (enums was actually a great example). Considering we were working on 5 languages at the same time though, it was difficult to do everything we wanted before shipping.
There's also the final reality that the generator we chose to use defaults to this behavior. We didn't find a better OpenAPI generator out there, and we weren't opposed to this generated output. There wasn't much wheel invention here, but we did attempt to make it spin smoother at times :D.
Hello! I'm assuming you're talking about Python type hints: https://docs.python.org/3/library/typing.html.
I love these :). I remember back in uni I would fill my program with them, but then fail the autograder because they were using an older version of Python 3 (support was only added in 3.5). I also remember back when the system didn't even have support for self-hoisting, so you couldn't make recursive type definitions and would have to do string annotations like `(x: 'LinkedListNode')`. Fun times.
Assuming that strongly typing the library in some way is beneficial (which we believed), let's look into the options we're provided here. Python's current type hint system requires external tools to enforce it and isn't enforced at runtime or "compilation." The system we have in our library creates a ton of objects that end up enforcing runtime constraints on input values. Failing at runtime because of invalid input is good. I've worked on Python stacks that totally do not use type hints (and my Emacs setup probably didn't back then either), and would have been saved tons of time debugging if the library just told me I was doing things wrong. This is at a definite cost of verbosity. There are definitely ways we can cut verbosity in this model (enums was actually a great example). Considering we were working on 5 languages at the same time though, it was difficult to do everything we wanted before shipping.
There's also the final reality that the generator we chose to use defaults to this behavior. We didn't find a better OpenAPI generator out there, and we weren't opposed to this generated output. There wasn't much wheel invention here, but we did attempt to make it spin smoother at times :D.