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

feat: Reimplement expr as a class that is understood by IDEs #3466

Merged
merged 23 commits into from
Jul 20, 2024

Conversation

dangotbanned
Copy link
Member

@dangotbanned dangotbanned commented Jul 9, 2024

Related #2904

expr

  • all ConstExpressions are now read-only properties stored in a metaclass
  • expr subclasses ExprRef, replacing the __call__ w/ __new__
    • No instances of expr are ever created
  • All FunctionExpressions are now classmethods
  • Each Expression can now be referenced in autocomplete, without needing IPython/Jupyter

Docs

Demo

image

Current (IPython)

2024-06-20.13-30-20.Current.IPython.mp4

Current (Static)

2024-06-20.13-31-45.-.Current.Introspection.mp4

Proposed (Static)

2024-07-09.18-08-29.-.Improved.Introspection.mp4

Proposed (API Reference)

image

image

Fixes the mypy issue referenced in `alt.__init__.py`
The results of `_populate_namespace` were only visible in a `IPython` environment
…ngleton

- all `ConstExpression`s are now read-only properties stored in a metaclass
- `expr` subclasses `ExprRef`, replacing the `__call__` w/ `__new__`
  - No instances of `expr` are ever created
- All `FunctionExpression`s are now classmethods
- Each `Expression` can now be referenced in autocomplete, without needing `IPython`/`Jupyter`
- Docstrings have been reformatted to be compatible with `sphinx`
- Broken links in docstrings fixed (e.g. for d3)
- class-level doc for `expr`, with references & doctest
Previously relied on the dynamic globals
Uses the section heading proposed in vega#3427 (comment)

Expands on vega#2904
@dangotbanned dangotbanned marked this pull request as ready for review July 9, 2024 18:15
@dangotbanned
Copy link
Member Author

dangotbanned commented Jul 9, 2024

All tests are passing now 😀

I hope the recordings/screenshots are useful. I thought demonstrating the UX would be clearer than listing all the benefits this could have.

Happy to clarify anything if you have any questions

@jonmmease
Copy link
Contributor

Hi @dangotbanned, thanks for this PR and apologies that no one has gotten back to you on it yet. This looks like a really nice quality of life improvement, and is very in line with my desire to promote the use of the expression API over using expression strings.

I'll try to get to reviewing and playing with this later in the week if no one else gets to it faster

@binste
Copy link
Contributor

binste commented Jul 16, 2024

Hi @dangotbanned, thanks for this PR and apologies that no one has gotten back to you on it yet. This looks like a really nice quality of life improvement, and is very in line with my desire to promote the use of the expression API over using expression strings.

I'll try to get to reviewing and playing with this later in the week if no one else gets to it faster

Can only second Jon's statement. Looks like a big UX improvement 🥳 but I struggle to find the time to review it. If you Jon get to it, that would be awesome! Thank you both :)

dangotbanned added a commit to dangotbanned/altair that referenced this pull request Jul 18, 2024
These will all be superseded by vega#3466
@jonmmease
Copy link
Contributor

This is an awesome improvement @dangotbanned. I like the architecture, just wondering if you have thoughts on reducing the duplication of function/constant specifications between the new class methods and the current FUNCTION_LISTING and CONST_LISTING dictionaries. I think the latter are only referenced in tests now, and it would be nice to remove them so that we don't risk them getting out of sync with the class methods.

Since we don't autogenerate these definitions right now, I want to go through the functions one-by-one before merging, and I'll do this later today or over the weekend.

Not to address in this PR, but it would be nice to eventually be able to auto-generate these function definitions, but it looks like they aren't included in the Vega or Vega-Lite jsonschema definitions, so we would need to pull them directly from the Vega repo or something.

@dangotbanned
Copy link
Member Author

dangotbanned commented Jul 19, 2024

Thanks @jonmmease

This is an awesome improvement @dangotbanned. I like the architecture, just wondering if you have thoughts on reducing the duplication of function/constant specifications between the new class methods and the current FUNCTION_LISTING and CONST_LISTING dictionaries. I think the latter are only referenced in tests now, and it would be nice to remove them so that we don't risk them getting out of sync with the class methods.

Yeah I considered this and would +1 for removing them.
I was trying to make this a drop-in replacement, as I imagined it would be easier to get merged.

The related changes I'd like to see here are:

  • Remove expr.[funcs|consts].py modules entirely
  • Rewrite the tests to iterate over wherever @classmethods are stored 65b527a (#3466)

Since we don't autogenerate these definitions right now, I want to go through the functions one-by-one before merging, and I'll do this later today or over the weekend.

Good luck! There is a lot to read.
I think some were out of sync with the current descriptions, so I updated those that I spotted.
You may also notice markup changes I had to make - to keep sphinx happy - which would be a consideration if this were autogenerated.
Although IIRC tools/.. has some handling for this already, so maybe not an issue.

Not to address in this PR, but it would be nice to eventually be able to auto-generate these function definitions, but it looks like they aren't included in the Vega or Vega-Lite jsonschema definitions, so we would need to pull them directly from the Vega repo or something.

Yeah I looked into that as well and I couldn't see a clean way of doing so, but maybe someone more familiar with vega/vega-lite could?

They're all defined in one place here https://vega.github.io/vega/docs/expressions/

But the actual source seems to be files like:

@dangotbanned
Copy link
Member Author

This is an awesome improvement @dangotbanned. I like the architecture, just wondering if you have thoughts on reducing the duplication of function/constant specifications between the new class methods and the current FUNCTION_LISTING and CONST_LISTING dictionaries. I think the latter are only referenced in tests now, and it would be nice to remove them so that we don't risk them getting out of sync with the class methods.

@jonmmease all done on that front 👍

I'll hold of on my suggestion to remove, but this can now be done at any point in the future

@dangotbanned

The related changes I'd like to see here are:

Remove expr.[funcs|consts].py modules entirely

Copy link
Contributor

@jonmmease jonmmease left a comment

Choose a reason for hiding this comment

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

lgtm!

@jonmmease jonmmease merged commit b9d3fd4 into vega:main Jul 20, 2024
11 checks passed
@dangotbanned
Copy link
Member Author

@jonmmease
Copy link
Contributor

FYI I'm working on a fix for the mypy issue that appeared on merging

Thanks!

@dangotbanned
Copy link
Member Author

dangotbanned commented Jul 20, 2024

FYI I'm working on a fix for the mypy issue that appeared on merging

Thanks!

@jonmmease

Is ready and would be able safely merge #3485 after

Thank you again for reviewing

@dangotbanned dangotbanned deleted the expr-non-dynamic branch July 21, 2024 11:02
dangotbanned added a commit to dangotbanned/altair that referenced this pull request Jul 22, 2024
Based on vega#3466 (comment)

With some additional ignores added during test runs on `/v5/schema/*.py`
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.

4 participants