3 ms·
Hmm it might take some getting used to but I've actually found it quite straight-forward to comprehend and reason about. The nice thing is that, since TypeVars
by codethief 5y ago
Hmm it might take some getting used to but I've actually found it quite straight-forward to comprehend and reason about.
The nice thing is that, since TypeVars are ordinary variables, you can re-use them / import them in multiple modules and avoid a lot of boilerplate code.
- throwaway894345 5y ago> The nice thing is that, since TypeVars are ordinary variables, you can re-use them / import them in multiple modules and avoid a lot of boilerplate code. Maybe I'm missing something, but the boilerplate only exists because Python makes you define them as ordinary variables in the first place. So while you can have a `foo.py` file like this: T = TypeVar("T") And a `bar.py` file like this: from foo import T class Bar(Generic[T]): ... So are you saying that this is less boilerplate than a `bar.py` that just defines its own `T` TypeVar? Because that seems like a pretty comparable amount of boilerplate. Or are you saying that it's less boilerplate than languages that don't treat TypeVars as ordinary variables, e.g., Rust? Because in Rust our `bar.rs` file would look like this: `struct Bar<T> {...}` (and the scoping rules are patently obvious, to boot).
- codethief 5y agoNo, in this particular example, there's no real advantage. What I meant were situations where the TypeVar gets a little more complicated, compare the additional parameters on https://docs.python.org/3/library/typing.html#typing.TypeVar https://docs.python.org/3/library/typing.html#typing.TypeVar . Then importing TypeVars starts to pay off because you only have to define your bounds etc. once.
- throwaway894345 5y agoAh, that makes sense. Thanks for clarifying.