-
-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
CLN/API: implemented to_html in terms of .style #11700
Comments
Some discussion related to this was going on in #14975 (comment). Summarizing some elements here: Barriers: some missing features are needed before such a replacement is possible (see also some elements in #11610)
Advantages:
Disadvantages:
cc @TomAugspurger For basic html output / notebook repr, it would maybe be useful to have a base class that has a simpler template and does not support all the different customization methods? For example, I can imagine that leaving out all the |
100% agree with your comments here. This wouldn't really be implementing Also, Jinja depends on MarkupSafe, so that becomes another dependency. |
Was there ever any progression on these ideas? FYI the performance disadvantage above is much improved from 2017. 19.6s vs 2.7s, I now get about 3.9s versus 1.9s. Also note #39951 |
I don't agree with the advantage mentioned by @jorisvandenbossche: While I'm all for one convergent formatting system, a templating engine is not the solution. It just does not work for everything: Also, I am not enthusiastic about making Jinja a hard dependence to render templates (for both HTML and LaTex, or anything else). EDIT: My idea is that the various (styleable) *Formatters (HTMLFormatter, NotebookFormatter, ExcelFormatter, ...) should be extended to get the ability to optionally apply styles to their output (like I described in #21673). |
Isn't |
I don't believe the objective here is to have one convergent system for everything, rather this post is about having one convergent formatting system for
Since |
I'm conflicted. On one hand, it's nice to remove code. On the other, I'm not sure of how much code we would really save in exchange for a "stronger" dependency on The possibility to export to other formats via I would be happy to be proven wrong though. How difficult would it be, in #40312, to run the test suite with |
You're right if it is certain that |
@moi90 If the goal is to replicate all of the functionality from
@toobaz I progressed the MVP to state where it now has a lot of general conditional styling capability for latex tables. See my response here
Quite easy, just need to redirect the method, when I push it I will ping you to take a look at test results. |
Actually I think the opposite. The docstring for |
Sure, but passing the notebook a table with millions of rows will just make it crash, whether or not you scroll. We can discuss the optimal numer of rows to show (notice that you can easily customize it), but I'm afraid "no limit" is not an option.
Sure, the point is indeed about notebooks. |
Do pandas set a limit of the size of a DataFrame you can construct, or is its limit just naturally determined by system constraints? Same logic could be argued here, albeit one is inside native python and the the other is rendering in external application like Jupyter in a browser (so error might not be as obvious) I have seen multiple use cases of wanting to visualise large tables one is here with the other upto 20,000 rows. To be honest thats the largest I've seen so even if I'm not convinced a limit is necessary I think having one above that would not have affected any use case I have seen so far - and from memory that only took seconds to render, so would be happy with that. |
I regularly use tables with a couple of million rows inside Jupyter and it's great to see them easily. I would hate to crash my notebook every time I view them without thinking about truncating them. I'm sure many people use pandas with much larger databases. Again, I think deprecating the truncated visualization is not an option. I might be wrong on the need to truncate |
Indeed, removing truncation from the default html repr is currently not an option I think (unless we would use a more advanced widget that eg does that automatically, but that's another discussion). There are already settings to change the number of rows to show, if you want to change this as a user. So if we want to replace the |
OK seems well supported, adding this to the list of things needed. |
This wasn't really closed by #40312, which only added a |
In #45382 I'm proposing changing the signature of
and this will perform the following:
This has the advantage of:
Is this reasonable and would it be appropriate to aim for something similar with |
Implement
to_html
/ notebook repr based on.style
.prob need to expand this to take a
use
argument (to select the style, needs to be 'classic' for a while, to replicate the current.to_html
one).The text was updated successfully, but these errors were encountered: