[Bug]: Unnecessary assert in to_extected_text_values

[nejcskofic]

Version

1.49.1

Steps to reproduce

Create assertion on multiple elements. For example for html

<ol>
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
</ol>

write assertion as:

expect(page.locator("ol li").to_have_text(("Item 1", "Item 2", "Item 3"))

Expected behavior

No errors, assertion passes.

Actual behavior

    def to_expected_text_values(
        items: Union[
            Sequence[Pattern[str]], Sequence[str], Sequence[Union[str, Pattern[str]]]
        ],
        match_substring: bool = False,
        normalize_white_space: bool = False,
        ignoreCase: Optional[bool] = None,
    ) -> Sequence[ExpectedTextValue]:
        out: List[ExpectedTextValue] = []
>       assert isinstance(items, list)
E       AssertionError

Additional context

Code here contains unnecessary or incorrect assertion. It asserts that the argument items is of type list, while typing information requires any sequence. By the usage of items there is no reason that it should be a list, other sequences should be accepted as well. In above case, tuple triggers the error.

Environment

- Operating System: [Ubuntu 22.04]
- CPU: [arm64]
- Browser: [Chromium]
- Python Version: [3.12]
- Other info:

[ltsuda]

Please, Python list is [] and .to_have_text expects a list any of these types str | Pattern | List[str] | List[Pattern] | List[str | Pattern]

Try expect(page.locator("ol li")).to_have_text(["Item 1", "Item 2", "Item 3"])

https://playwright.dev/python/docs/api/class-locatorassertions#locator-assertions-to-have-text

[nejcskofic]

@ltsuda Please, take a look at signature in the code:

def to_expected_text_values(
    items: Union[
        Sequence[Pattern[str]], Sequence[str], Sequence[Union[str, Pattern[str]]]
    ],
    match_substring: bool = False,
    normalize_white_space: bool = False,
    ignoreCase: Optional[bool] = None,
) -> Sequence[ExpectedTextValue]:

What you wrote is simply not correct, because signature allows any sequence, so it should allow tuple as well. If it should allow only list (though as I've written above, there is no reason for this), then signature for items should be list, not sequence.