Replace type with Type[...] in various stubs

Now that we have Type[C] in PEP 484, many places where stubs currently use type they can be more precise. E.g. if an argument must be an exception class, Type[BaseException] is more appropriate.

This would be an easy task (but don't do many unrelated modules in one big PR -- small PRs are much easier to review and merge and don't get stale as quickly).

Require warning categories to be subclasses of Warning (python#343)

Require warning categories to be subclasses of Warning (#343)

A casual grep showed that not too many of these instances are left in typeshed.

I found the following that looked like they could be made more specific (from git grep ': type\b'):

stdlib/2/BaseHTTPServer.pyi:    MessageClass: type
stdlib/2/ConfigParser.pyi:    def _get(self, section: str, conv: type, option: str) -> Any: ...
stdlib/2/_socket.pyi:MethodType: type
stdlib/2/sys.pyi:last_type: type
stdlib/2/sys.pyi:def __excepthook__(type_: type, value: BaseException, traceback: TracebackType) -> None: ...
stdlib/2/tokenize.pyi:chain: type
stdlib/2/tokenize.pyi:double3prog: type
stdlib/2/tokenize.pyi:pseudoprog: type
stdlib/2/tokenize.pyi:single3prog: type
stdlib/2/tokenize.pyi:tokenprog: type
stdlib/2and3/logging/__init__.pyi:def setLoggerClass(klass: type) -> None: ...
stdlib/2and3/sqlite3/dbapi2.pyi:    def create_aggregate(self, name: str, num_params: int, aggregate_class: type) -> None: ...
stdlib/3/email/contentmanager.pyi:    def add_set_handler(self, typekey: type, handler: Callable[..., Any]) -> None: ...
stdlib/3/http/server.pyi:    MessageClass: type
stdlib/3/re.pyi:    _pattern_type: type
third_party/2and3/click/core.pyi:    def find_object(self, object_type: type) -> Any: ...
third_party/2and3/click/core.pyi:    def ensure_object(self, object_type: type) -> Any: ...
third_party/2and3/click/decorators.pyi:def make_pass_decorator(object_type: type, ensure: bool = ...) -> _IdentityFunction: ...
third_party/2and3/flask/app.pyi:    request_class: type = ...
third_party/2and3/flask/app.pyi:    response_class: type = ...
third_party/2and3/flask/app.pyi:    jinja_environment: type = ...
third_party/2and3/flask/app.pyi:    app_ctx_globals_class: type = ...
third_party/2and3/flask/app.pyi:    url_rule_class: type = ...
third_party/2and3/flask/app.pyi:    test_client_class: type = ...
third_party/2and3/flask/app.pyi:    test_cli_runner_class: type = ...
third_party/3/pkg_resources/__init__.pyi:def register_finder(importer_type: type, distribution_finder: _DistFinderType) -> None: ...
third_party/3/pkg_resources/__init__.pyi:def register_loader_type(loader_type: type, provider_factory: Callable[[types.ModuleType], IResourceProvider]) -> None: ...
third_party/3/pkg_resources/__init__.pyi:def register_namespace_handler(importer_type: type, namespace_handler: _NSHandlerType) -> None: ...

I wonder whether we should replace all "naked" type statements with Type[Any] (or type[Any] when PEP 585 gets implemented). This forces the contributor to actively think about the generic type to use. We could enforce this using a linter in the future.

Most usages of type in typeshed now look legitimate (they are used in places where all types are accepted). We can make more improvements in specific cases but I don't think we still need this issue.

Prepare release 4.10.0 (python#343)

Navigation Menu

Repository navigation

Replace `type` with `Type[...]` in various stubs #343

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Replace type with Type[...] in various stubs #343

Description

Activity

srittau commented on Sep 11, 2018

JelleZijlstra commented on Jun 28, 2020

srittau commented on Sep 17, 2020

JelleZijlstra commented on Dec 16, 2021

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Replace `type` with `Type[...]` in various stubs #343