Collin Funk wrote:
> I have also made a conscious choice not to use more abstract
> collections like 'Iterable' even though they are recommended [4].
>
> The first is because some functions check the type:
>
> def setModules(self, modules: list[str] | tuple[str]) -> None:
> '''Set the modules list.'''
> if type(modules) is list or type(modules) is tuple:
> # do something, or raise a TypeError
>
> It is temping to use Iterable here:
>
> print(iter(list()))
> <list_iterator object at 0x7f7c13f5b1c0>
> print(iter(tuple()))
> <tuple_iterator object at 0x7f7c13f5b1c0>
>
> but a what about a set?
>
> print(iter(set()))
> <set_iterator object at 0x7f7c13f56b80>
>
> We would think it is okay to pass a set, but it would fail at runtime.
> Using the uglier Union would let us know by looking or a warning if
> using a lsp program.
>
> The second reason is sorting. Since it is easy to mess up the sorting
> for the test cases against gnulib-tool.sh, it is probably best to only
> pass lists for now. We can change functions to Iterable or something
> similar once we are sure it will not affect the output.
I agree. My main considerations are:
- Can someone with little exposure to Python understand and modify the
code? When you write 'list' and the developer knows that 'list' means
what is known as "array" in other programming languages, they can work
with the code. Using the abstract interfaces that Python has does not
help in this aspect.
- In some cases, it is useful to access the data structure with indices.
Then an 'Iterable' will not suffice, a 'list' or 'tuple' is needed.
What would be the point of declaring "this function needs to traverse
the given data only from the beginning to the end, never in the opposite
direction, never with random indices"? There is no advantage. It is
useless information. So, why bother?
Bruno
