Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(typing): Improve Then annotations, autocompletion, docs #3567

Merged
merged 35 commits into from
Sep 22, 2024

Conversation

dangotbanned
Copy link
Member

@dangotbanned dangotbanned commented Sep 4, 2024

Fixes #3552

Overview of issues by @binste in comment

The draft PR is very helpful! Trying to summarise/reword it for myself:

  • Then should not inherit from SchemaBase as it muddies autocompletion
  • We need a type hint which lets a SchemaBase pass due to alt.condition and alt.when().then().otherwise(). Can be SchemaBase or a protocol
  • It's unclear to me when, as a developer, I'd use SchemaLike. If I understand it correctly, we mainly introduce it now to make these types work.
  • Purpose:
    • Fix type errors users might get right now, keeping types as narrow as possible so they are more useful
    • Improving UX: keep/improve autocompletion + provide a good visual indication that we mean conditions can be passed

How about

@runtime_checkable
class Condition(Protocol):
   """We use this protocol to signal to a user that they can pass any condition created by either `alt.condition` or `alt.when`.

   Other SchemaBase instances will pass as `Condition` as well and so for type checkers it won't matter but using this protocol when only conditions are expected at least gives a better visual indication to users.
   """
    _schema: ClassVar[_SchemaLikeDict] = {"type": "object"}

    def to_dict(self, *args, **kwds) -> Any: ...


def chart_encode(
   col_7: Optional[str | Color | Condition | Map | ColorDatum | ColorValue] = Undefined,
)

Condition is not yet used anywhere in the codebase and it makes it clearer what we intend to do with the protocol. What do you think?

Tasks

Related

Note

This PR started as a draft proposal for addressing multiple related issues.
See #3552 (comment) for further info

Draft PR Demo

Purely demonstrating type checking behavior for #3552 (comment)

Extended chart_encode

image

image

Note

mypy failing is expected and part of the demonstration

Revisting these I found it confusing that they were defined like (A, B, B, A).
They are now (A, A, B, B) so it is clearer how they are linked
Aiming to get all of these to pass, without breaking anything else.
**CI fail expected**
@dangotbanned dangotbanned linked an issue Sep 14, 2024 that may be closed by this pull request
@dangotbanned dangotbanned changed the title fix(DRAFT): Add examples for SchemaLike fix(DRAFT): Improve Then annotations, simplify autocompletion Sep 15, 2024
…-compliant

Can't define this in `OperatorMixin`, as `Expression` uses `{"type": "string"}`
Added a lot of notes here, since I was surpised `Then` would not be allowed in the cases I had planned originally
We're using a feature that didn't make it into `3.13` yet https://peps.python.org/pep-0728/
The warning raised by `pyright` here was actually quite helpful.
Essentially, a shorthand string is never allowed here

vega#3552 (comment)
We now provide more precise errors identifying exactly which call produced the issue.
Previously, the `.then("min(foo):Q")` was silently allowed - but later rejected in `.otherwise()`.
No longer inherited
@dangotbanned dangotbanned changed the title fix(DRAFT): Improve Then annotations, simplify autocompletion fix(typing): Improve Then annotations, autocompletion, docs Sep 16, 2024
@dangotbanned dangotbanned marked this pull request as ready for review September 16, 2024 15:15
@dangotbanned dangotbanned enabled auto-merge (squash) September 17, 2024 11:28
Copy link
Contributor

@binste binste left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

altair/vegalite/v5/api.py Show resolved Hide resolved
@dangotbanned
Copy link
Member Author

LGTM, thanks!

Thanks for the review @binste

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

_EncodingMixin.encode types defined too narrow
2 participants