-
Notifications
You must be signed in to change notification settings - Fork 796
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
Introduce export methods like Chart.to_***()
#3189
Comments
A convention we used in plotly that I still like is to use |
BTW, are you picturing that |
After re-reading my comment in the linked issue, I think that was indeed what I had in mind at that time. Not sure if it still make sense. Regarding Single entry, easy to remember, easy to maintain. |
Personally, I too have a (weak) preference for keeping separate nomenclature for methods that write to files vs those that return an object. So my vote here would be to keep the current naming with |
When looking to the current code base it make sense to keep the Also with the current code base we have introduced a new Apparently we still have the Based on the discussion above, I'm fine with the approach that the |
Distilled from #3081 (comment):
Currently we can export Altair specifications as such:
.save(format=***)
.to_dict(format=***)
# defaults tovega-lite
option forvega
.to_json(format=***)
# defaults tovega-lite
option forvega
Personally, I like it when there is a grouping using
to_***()
.Using the autocomplete I can discover what this object can be evaluated into (similar to autocomplete on
.mark_***()
andtransform_***()
to see what is possible).For example:
to_svg()
to_png()
to_pdf(()
to_df()
to_pl()
to_arrow()
to_vgjson()
to_vljson()
to_json()
# isvega-lite
to_vgdict()
to_vldict()
to_dict()
# isvega-lite
The text was updated successfully, but these errors were encountered: