T.Sequence is a questionable concept. The idea is to hammer out generic, maximally forgiving APIs that operate on protocols, which is a fancy way of saying "I don't care if you use tuples or lists". This is rarely needed, actually, and in exchange for this fancy behavior you get free bugs. Specifically, `somestr` is of type `T.Sequence[str]`, and also `somestr[0]` is another string of type you guessed it. It's ~~turtles~~ strings all the way down. It's worth noting that trying to code for "protocols" is a broken concept if the contents have semantic meaning, e.g. it operates on "the install tags of this object" rather than "an iterable that supports efficient element access". The other way to use T.Sequence is "I don't like that T.List is invariant, but also I don't like that T.Tuple makes you specify exact ordering". This sort of works. In fact it probably does work as long as you don't allow str in your sequences, which of course everyone allows anyway. Use of Sequence has cute side effects, such as actually passing lists around, knowing that you are going to get a list and knowing that you need to pass it on as a list, and then having to re-allocate as `list(mylist)` "because the type annotations says it could be a str or tuple". Except it cannot be a str, because if it is then the application is fatally flawed and logic errors occur to disastrous end user effects, and the type annotations: - do not enforce their promises of annotating types - fail to live up to "minimal runtime penalties" due to all the `list()` Shun this broken concept, by hardening the type annotations. As it turns out, we do not actually need any of this covariance or protocol-ism for a list of strings! The whole attempt was a slow, buggy waste of time.pull/11159/head
parent
cbf4496434
commit
e5a9272034
5 changed files with 6 additions and 6 deletions
Loading…
Reference in new issue