question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Expose IValidator via PEP544 Protocols

See original GitHub issue

I have an issue similar to #239 but somewhat different. I would like to be able to reach IValidator to use type-hinting in functions.

If I want to create a function where a validator can be passed in parameter, it cannot be type-hinted:

def handle_ndjson(
  path:str, 
  validator:jsonschema.IValidator, 
  valid_object_fn: Callable[[dict], None], 
  invalid_object_fn: Callable[[dict, jsonschema.ValidationException], None]):

fails because jsonschema.IValidator isn’t exposed (as explained in #239). The purpose is not to allow the creation of new validator, but to allow the user to chose between the different draft. Is there a graceful way to do that?

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Comments:22 (13 by maintainers)

github_iconTop GitHub Comments

3reactions
sirosencommented, Dec 16, 2021

With this now in 4.3.0 (huge thanks @Julian for the steady review feedback and quick release!), I think we can close this issue.

I have a PR open in typeshed to add this, after which it should be possible to use jsonschema.Validator for type annotations.

For those who did not see the PR, I’ll also note here that jsonschema.Validator is runtime_checkable, meaning you can use it for isinstance checks.

2reactions
sirosencommented, Feb 22, 2022

Yes, having jsonschema publish types would also be a solution. Arguably the best solution for library consumers. But, not to downplay the value it offers, I don’t think it’s likely to happen in the near term.

jsonschema dynamically generates classes, and type checkers struggle to support dynamic cases like this. I see problems with trying to have jsonschema publish types based on its runtime logic. And I would argue that stubs will end up better maintained in typeshed than here.

Read more comments on GitHub >

github_iconTop Results From Across the Web

PEP 544 – Protocols: Structural subtyping (static duck typing)
In this case methods are resolved using normal MRO and a type checker verifies that all subtyping are correct. The semantics of @abstractmethod ......
Read more >
Building Implicit Interfaces in Python with Protocol Classes
Protocol classes allow us to define an interface, called a protocol, and use static type-checking via mypy to verify that objects satisfy the ......
Read more >
jsonschema - Bountysource
I would like to use a schema base.json that defines basic properties together with a schema derived.json which adds further validation to the...
Read more >
Protocols and structural subtyping - mypy 0.991 documentation
Mypy provides support for structural subtyping via protocol classes described below. See PEP 544 for the detailed specification of protocols and structural ...
Read more >
Example in PEP 544 seems to be wrong · Issue #1231 - GitHub
I am on Python 3.8 and use MyPy 0.740 I consider the following example from PEP 544: from typing import Any, Protocol class ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found