-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
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
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. |
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_len
variable. 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
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
@@ -316,6 +316,12 @@ def concat(self, other: Styler) -> Styler: | |||
inherited from the original Styler and not ``other``. | |||
- hidden columns and hidden index levels will be inherited from the | |||
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!
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>
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.rst
file if fixing a bug or adding a new feature.