You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Subset the data view indices to only include the selected rows
data_view_indices= [
index
forindexindata_view_indices
ifindexinselected_row_indices_set
]
, maybe we expose them via .data_view_indices(*, selected: bool = False)? (Similar to .data_view(*, selected: bool = False))
It could return a {rows: list[int], cols: list[int]} object containing all rows/cols being used (given selected value). We could add a type to describe how the values were selected, similar to the CellSelection type
# Attempt to type the list of size 2, but it is not type enforced
rows: tuple[int, int] |Annotated[list[int], 2]
cols: tuple[int, int] |Annotated[list[int], 2]
# For receiving selection info from JS:
CellSelection=Union[
CellSelectionRow,
CellSelectionCol,
CellSelectionRect,
CellSelectionNone,
]
.
For the return value, I still don't know if rows and cols should always exist (containing all values). If they always exist, it is easier to code as a user. If they do not exist, it is much clearer as to what is being subsetted but more annoying to integrate with as a user. I'm currently leaning towards always including rows and cols containing all values being used. Ex: multi row selection would return {type: "row", rows: [1,3,5], cols: [0,1,2,3,4,5]} assuming we selected rows 1, 3, and 5 and there were 6 columns.
Good news...
With a combination of
py-shiny/shiny/render/_data_frame.py
Lines 405 to 412 in 3b742a2
py-shiny/shiny/render/_data_frame.py
Lines 492 to 502 in 3b742a2
.data_view_indices(*, selected: bool = False)
? (Similar to.data_view(*, selected: bool = False)
)It could return a
{rows: list[int], cols: list[int]}
object containing all rows/cols being used (givenselected
value). We could add atype
to describe how the values were selected, similar to theCellSelection
typepy-shiny/shiny/render/_data_frame_utils/_selection.py
Lines 162 to 185 in 3b742a2
For the return value, I still don't know if
rows
andcols
should always exist (containing all values). If they always exist, it is easier to code as a user. If they do not exist, it is much clearer as to what is being subsetted but more annoying to integrate with as a user. I'm currently leaning towards always includingrows
andcols
containing all values being used. Ex: multi row selection would return{type: "row", rows: [1,3,5], cols: [0,1,2,3,4,5]}
assuming we selected rows 1, 3, and 5 and there were 6 columns.@pstorozenko Glad you like
.data_view()
!Can I get a copy of your crystal ball? 😆
I'd love to move to something like https://github.com/data-apis/dataframe-api-compat , however to get typing support, their typing specification is defined deep within another repo: https://github.com/data-apis/dataframe-api/tree/main/spec/API_specification/dataframe_api .
I do not understand why the types being used within
dataframe-api-compat
are not shipped with the package. /rantOriginally posted by @schloerke in #1345 (comment)
The text was updated successfully, but these errors were encountered: