-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
Style concats #49212
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
Style concats #49212
Conversation
|
On question before reviewing this properly. How does this impact the CSS class names of the concatenated stylers? Using your PR i think there is a difference between
|
|
It's true. In the original implementation, you'll have _foot got the first concat, _foot_foot for the second, etc. Should we make them all different? I can try Also, I haven't seen the original behavior documented anywhere. Have I missed something, or should we document the original behavior also? If so, where? |
|
No I dont think we should make them different. I actually like the way you have implemented this so that you can chain, and any concatenated The ability to create "foot_foot_" is still available due the flexible way this has been implemented. No this was not documented previously as your issue has raised. With the "notes" section of the |
|
Sorry for the delay, I'm definitely want to push this, but didn't had time.
Will try to look at it today/tomorrow
…On Wed, 2 Nov 2022, 17:01 JHM Darbyshire, ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In pandas/io/formats/style_render.py
<#49212 (comment)>:
>
- for (r, c), v in self.concatenated.ctx.items():
+ for (r, c), v in concatenated.ctx.items():
@tsvikas <https://github.com/tsvikas> what do you think of above? This is
a good PR so I want to follow up.
—
Reply to this email directly, view it on GitHub
<#49212 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AESBIZOATDTZXI6DQSFTSVDWGJ66HANCNFSM6AAAAAARKKLHUM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Sorry for the delay. 1. I've improved the testsNow all 3 tests are concatenating 3 different styles, and verifying that they render as expected. They all pass. 2. GHA reports that "Some checks were not successful"
I have no idea why. I wouldn't expect the tests to pass on all the other systems and fail on this. 3. updating
|
3. updating concatenated.ctx inside the loopis fixed now. |
attack68
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've spotted a few issues.
- is HTML that doesn't render correctly because of non-unique cell ids.
- is repeated CSS specification. I'm not sure if this is existing issue or new with your code.
- is to do with the
ctx_lenvariable. See above question. - is with copying - although we can defer this to a follow up.
Co-authored-by: JHM Darbyshire <24256554+attack68@users.noreply.github.com>
|
I fixed everything except the copy issue, and did a rebase (hopefully it's ok). |
to explain the css of chained concats
attack68
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm - actually just need to push the whats new to 1.5.3, think we missed the window for 1.5.2.
@pandas-dev/pandas-core if anyone else has time to review this as well before merging is great.
|
@attack68 mypy fixed. there is another check (doc build and upload) that failed (some warning about numpy deprecation maybe?), and i don't know how to fix that |
|
Sorry @tsvikas, the whats new is now out of date and needs a merge, although my changes above fixed the checks. I have been waiting to see if anyone else wants to review, but the code here is quite restricted just to Styler.concat and doesnt affect anything else and is a good extension and fix so I will merge after it s updated. |
|
|
||
| def concatenated_visible_rows(obj): | ||
| row_indices: list[int] = [] | ||
| _concatenated_visible_rows(obj, 0, row_indices) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this function (and the one above) be refactored to just recursively yield each row, since it's just needed in the zip below? From first glance, it seems odd that this is modifying row_indices inplace and the result n isn't used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't appear to have been addressed (please don't resolve unresolved conversations)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree this could be considered for refactor to be made simpler. Does it have to be a blocker for the PR - it is otherwise a very nice addition that addresses a potentially common use case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure can be a follow up but it would be good to add a TODO comment here with the note to simplify
| original Styler | ||
| - ``css`` will be inherited from the original Styler, and the value of | ||
| keys ``data``, ``row_heading`` and ``row`` will be prepended with | ||
| ``foot0_``. If more concats are chained, their styles will be prepended |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if there is only 1 Styler, before foot_ would be prepended and now foot0_will be prepended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't appear to have been addressed (please don't resolve unresolved conversations)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When chaining multiple Stylers the CSS needs a unique identifier. Previously it was only possible to compound multiple styler concatenations:
styler1.concat(styler2.concat(styler3))which resulted in CSS classes None, foot_ and foot_foot_.
When allowing chained stylers you need an integer id, so
styler1.concat(styler2).concat(styler3.concat(styler4)).concat(styler5)results in None, foot0_, foot1_ and foot1_foot0_, foot2_.
The CSS classes were not documented in 1.5.0 previously and not exposed to the user.
Here they are now amended and documented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So just to confirm, a result with foot_ wasn't visible to the user previously and wouldn't see that foot0_ would now be returned?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
foot_ is returned as part of the HTML string in 1.5.0. All of the automatically generated styling CSS ids reference foot_ so that the rendered HTML table, including styles works correctly.
Now the HTML string returned will contain foot0_ and all the auto generated CSS ids will reference that instead.
Unless the user is specifically adding a CSS rule for foot either with an external stylesheet or using set_table_styles there will be no visible difference in the rendered HTML display, either in a JupyterLab or browser.
i.e.
styler2.applymap(lambda v: "color: red;")
styler1.concat(styler2)will display the same in both versions even though the CSS class names have been changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay thanks for the explanation!
mroeschke
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a 1.5.3.rst got merged already so should use the existing one instead
|
i fixed the merge conlict in the |
Co-authored-by: JHM Darbyshire <24256554+attack68@users.noreply.github.com>
mroeschke
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can merge on greenish
|
i'm not sure why |
|
the failure is unrelated: |
|
Owee, I'm MrMeeseeks, Look at me. There seem to be a conflict, please backport manually. Here are approximate instructions:
And apply the correct labels and milestones. Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon! Remember to remove the If these instructions are inaccurate, feel free to suggest an improvement. |
|
@tsvikas would you have time to follow the backport instructions above to push the code to the 1.5.x branch? |
done, up to "And apply the correct labels and milestones." and "remove the Still Needs Manual Backport label" (which i don't have permission to). |
|
done, thx |
Allow chaining of style.concat Co-authored-by: Tsvika S <tsvikas@dell> Co-authored-by: JHM Darbyshire <24256554+attack68@users.noreply.github.com> Co-authored-by: Matthew Roeschke <10647082+mroeschke@users.noreply.github.com>
doc/source/whatsnew/v1.5.2.rstfile if fixing a bug or adding a new feature.