fix: Fix type checker errors by ilotoki0804 · Pull Request #1203 · appium/python-client

ilotoki0804 · 2026-03-02T13:21:48Z

For a more detailed explanation, please refer to this link.

In `py.typed` modules, imported symbols considered private[^1], which is not importable by users. To become public interface, explicit `__all__` symbol is required. [^1]: https://typing.python.org/en/latest/spec/distributing.html#library-interface-public-and-private-symbols

linux-foundation-easycla · 2026-03-02T13:21:55Z

The committers listed above are authorized under a signed CLA.

✅ login: ilotoki0804 / name: ilotoki0804 (024f74f, 1e3475b, 5e0b420, 5ee2faa, 8228005, 8b1ed55)

mykola-mokhnach · 2026-03-02T15:27:58Z

appium/protocols/webdriver/can_execute_scripts.py



 class CanExecuteScripts(Protocol):
-    def pin_script(self, script: str, script_key: Optional[Any] = None) -> Any: ...


unfortunately this would be a breaking change

As I understand it, the four commented-out methods are methods that were never defined or used anywhere in the module.
Since these methods were never actually implemented, it appears they would have served no practical purpose if a user attempted to use them.

However, while it's true they did nothing, it's also true they didn't cause any errors. Therefore, technically, it does not guarantee backward compatibility. If backward compatibility of the code is a concern, instead of commenting them out, I could add if not TYPE_CHECKING to those methods. This would preserve backward compatibility while avoiding sending incorrect signals to static type checkers (though the issue would persist at runtime). Would you prefer that approach?

yes, that approach makes more sense if we want to make the change non-breaking

It may also make sense to mark these fields as deprecated so they could be removed after the next major version bump

WDYT @KazuCocoa ?

Alright. I'll implement it that way.

If I remember correctly, the original motivation for this was to give typehint for methods existed in selneium:
https://github.com/SeleniumHQ/selenium/blob/6c60a108ce7fdc3f537e62c4060c998f3cdb5c5f/py/selenium/webdriver/remote/webdriver.py#L480 as well.

So Appium Python client itself doesn't have the implementation, but their actual behavior comes from Selenium Python Binding. Appium Python client simply provides the type hint to help users to tell these hints for Web automation.

These scripts are not deprecated since selenium binging has - which is parents of this python client

I wondered if we can simply remove them since the parent selenium project already have type hints for them today. Editors can refer to the parent selenium.

[update]
Maybe the primary usage for these types are in this repository development purpose

Would #1204 help...?

Not sure if the PR error case is the actual reason, but on this project basis, the selenium deps is installed in the venv. If I have specified pyright config (which is pylance's code analytics) the error stopped.

Also, mypy doesn't have this behavior, so possibly this is pyright specific behavior, which might expect protocol-defined methods would be implemented in the children only (not parents)

After digging deeper based on your feedback, I found an issue where selenium.webdriver.Remote wasn't being recognized correctly in Pyright. However, if you import and use selenium.webdriver.remote.webdriver.Webdriver instead of selenium.webdriver.Remote, pyright correctly discovers the class, and that class properly implements the methods in the protocol, resolving the issue. I'm not sure whether this error was caused by pyright or selenium's implementation.

I reverted the protocol implementation and changed the import path.

BTW at least in my setup, trying #1204 didn't resolve the issue. I suspect that wasn't the solution to the main cause.

mypy is a reference checker for PEP 484 and it might not have this issue. So, it could be pyright specific behavior (not sure this is an issue, though)
https://docs.basedpyright.com/dev/usage/mypy-comparison/?utm_source=copilot.com

Added deprecation warnings for unimplemented methods in CanExecuteScripts protocol.

mykola-mokhnach · 2026-03-02T17:14:13Z

appium/protocols/webdriver/can_execute_scripts.py


-from typing import Any, List, Optional, Protocol
+from typing import Any, List, Optional, Protocol, TYPE_CHECKING
+from warings import deprecated


mykola-mokhnach · 2026-03-02T17:14:32Z

appium/protocols/webdriver/can_execute_scripts.py

+    # TODO: remove `if not TYPE_CHECKING` guard after properly implement them
+    # The use of these methods will produce DeprecationWarnings at runtime
+    if not TYPE_CHECKING:
+        @deprecated("pin_script is not yet implemented")


I would rather say is deprecated for removal

I assumed those methods would be implemented later. If there are no plans to do so, I will make the changes as you suggested.

I am not sure it makes sense to implement them in mobile context, but it still makes sense to confirm that with other maintainers

KazuCocoa · 2026-03-03T07:43:10Z

appium/webdriver/__init__.py

 Appium Python Client: WebDriver module
 """

+__all__ = ["Remote", "WebElement"]


This change looks reasonable to me. This fixes mypy --strict also.

KazuCocoa

Lg to me. Waiting for the CI result

ilotoki0804 added 2 commits March 2, 2026 04:51

Comment out unimplemented methods in CanExecuteScripts protocol

8b1ed55

mykola-mokhnach reviewed Mar 2, 2026

View reviewed changes

Uncomment and add deprecation warnings for unimplemented methods

8228005

Added deprecation warnings for unimplemented methods in CanExecuteScripts protocol.

mykola-mokhnach reviewed Mar 2, 2026

View reviewed changes

Update deprecation messages in CanExecuteScripts

1e3475b

KazuCocoa reviewed Mar 3, 2026

View reviewed changes

ilotoki0804 added 2 commits March 4, 2026 05:52

Restore CanExecuteScripts protocol methods

024f74f

Import Remote class from the original source

5ee2faa

KazuCocoa reviewed Mar 4, 2026

View reviewed changes



		class CanExecuteScripts(Protocol):
		def pin_script(self, script: str, script_key: Optional[Any] = None) -> Any: ...

Conversation

ilotoki0804 commented Mar 2, 2026

Uh oh!

linux-foundation-easycla bot commented Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ilotoki0804 Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mykola-mokhnach Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KazuCocoa Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KazuCocoa Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KazuCocoa Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KazuCocoa left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

linux-foundation-easycla bot commented Mar 2, 2026 •

edited

Loading

ilotoki0804 Mar 2, 2026 •

edited

Loading

mykola-mokhnach Mar 2, 2026 •

edited

Loading

KazuCocoa Mar 3, 2026 •

edited

Loading

KazuCocoa Mar 3, 2026 •

edited

Loading

KazuCocoa Mar 3, 2026 •

edited

Loading