aboutsummaryrefslogtreecommitdiff
path: root/mesonbuild/utils/universal.py
diff options
context:
space:
mode:
authorEli Schwartz <eschwartz@archlinux.org>2022-08-17 02:39:47 -0400
committerEli Schwartz <eschwartz@archlinux.org>2022-12-11 18:28:39 -0500
commite5a92720348d45df000826536ca77a4c643bb662 (patch)
treeee9c16fe0195c2a204f3102eaf758110b69c025b /mesonbuild/utils/universal.py
parentcbf4496434ef78f695c2ceca4e9e093ea14ab784 (diff)
downloadmeson-e5a92720348d45df000826536ca77a4c643bb662.zip
meson-e5a92720348d45df000826536ca77a4c643bb662.tar.gz
meson-e5a92720348d45df000826536ca77a4c643bb662.tar.bz2
typing: fix some broken Sequence annotations
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.
Diffstat (limited to 'mesonbuild/utils/universal.py')
-rw-r--r--mesonbuild/utils/universal.py2
1 files changed, 1 insertions, 1 deletions
diff --git a/mesonbuild/utils/universal.py b/mesonbuild/utils/universal.py
index 68ea0b7..220a7f4 100644
--- a/mesonbuild/utils/universal.py
+++ b/mesonbuild/utils/universal.py
@@ -1906,7 +1906,7 @@ class RealPathAction(argparse.Action):
setattr(namespace, self.dest, os.path.abspath(os.path.realpath(values)))
-def get_wine_shortpath(winecmd: T.List[str], wine_paths: T.Sequence[str],
+def get_wine_shortpath(winecmd: T.List[str], wine_paths: T.List[str],
workdir: T.Optional[str] = None) -> str:
'''
WINEPATH size is limited to 1024 bytes which can easily be exceeded when