Skip to content
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

Add read-only access to the children of a TreeNode #1495

Merged
merged 10 commits into from
Jan 6, 2023

Conversation

davep
Copy link
Contributor

@davep davep commented Jan 5, 2023

Adds a generic ImmutableSequence wrapper class (name and location totally up for debate, although the name of the class got the nod in a Slack chat so I suspect that's okay) and then goes on to use that to wrap the internal child list of a TreeNode, making it available in a non-destructive way.

See #1398.

In anticipation of satisfying Textualize#1398, this adds a generic immutable sequence
wrapper class. The idea being that it can be used to wrap up a list or
similar, that you don't want the caller to modify.

This commit aims to get the basics down for this, and also adds a minimal
set of unit tests.
@davep davep added the enhancement New feature or request label Jan 5, 2023
@davep davep linked an issue Jan 5, 2023 that may be closed by this pull request
Copy link
Collaborator

@willmcgugan willmcgugan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re naming, I think this is essentially a view. Much like the dict views.

Suggest ImmutableSequenceView as a name. I don't know if it qualifies as a collection, so I think maybe just name the file "_immutable_sequence_view.py" for the moment.

Since the use case is to provide a immutable view on to a collection. It shouldn't copy the data internally. Let's store a reference to the Sequence parameter supplied in the constructor.

src/textual/_collections.py Outdated Show resolved Hide resolved
@davep
Copy link
Contributor Author

davep commented Jan 6, 2023

re naming, I think this is essentially a view. Much like the dict views.

Suggest ImmutableSequenceView as a name. I don't know if it qualifies as a collection, so I think maybe just name the file "_immutable_sequence_view.py" for the moment.

Makes sense, I'll make those changes.

Since the use case is to provide a immutable view on to a collection. It shouldn't copy the data internally. Let's store a reference to the Sequence parameter supplied in the constructor.

I'm not sure I quite follow this though. As the code stands doesn't it store a reference if it's an indexable sequence type, and only retains a copy if the incoming sequence is one that can't be indexed, allowing it ti be indexed. Perhaps I've misunderstood what was asked for here?

@willmcgugan
Copy link
Collaborator

I'm not sure I quite follow this though. As the code stands doesn't it store a reference if it's an indexable sequence type, and only retains a copy if the incoming sequence is one that can't be indexed, allowing it ti be indexed. Perhaps I've misunderstood what was asked for here?

It's only ever going to be used as a shim on top of a sequence. Can't see any use for creating these for iterators.

@davep
Copy link
Contributor Author

davep commented Jan 6, 2023

It's only ever going to be used as a shim on top of a sequence. Can't see any use for creating these for iterators.

Ahh, okay, that makes life easier. I only took that into account because you asked that it do so (accept an iterator too) when we spoke about this yesterday. Happy to drop that part.

@davep davep requested a review from willmcgugan January 6, 2023 12:46
@davep
Copy link
Contributor Author

davep commented Jan 6, 2023

Right, that should be those couple or so issues addressed. Thanks.


def test_tree_node_children() -> None:
"""A node's children property should act like an immutable list."""
CHILDREN=23
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you run Black on this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not by hand on the tests, no. black is run by pre-commit of course so if there's a non-black-happy-ness in the above, that would suggest that both pre-commit and CI black checks avoid the unit tests?

Checking:

$ poetry run black --check .
would reformat devtools/__init__.py
would reformat snapshot_tests/snapshot_apps/horizontal_auto_width.py
would reformat snapshot_tests/snapshot_apps/multiple_css/multiple_css.py
would reformat renderables/test_sparkline.py
would reformat snapshot_tests/snapshot_apps/key_display.py
would reformat renderables/test_text_opacity.py
would reformat test_path.py
would reformat test_focus.py
would reformat test_immutable_sequence_view.py
would reformat test_node_list.py
would reformat renderables/test_underline_bar.py
would reformat test_arrange.py
would reformat test_unmount.py
would reformat test_table.py
would reformat test_dom.py
would reformat test_screens.py
would reformat tree/test_tree_node_label.py
would reformat tree/test_tree_node_children.py
would reformat test_text_backend.py
would reformat test_widget_child_moving.py
would reformat test_reactive.py
would reformat test_widget_mounting.py
would reformat test_widget_removing.py
would reformat test_geometry.py

Oh no! 💥 💔 💥
24 files would be reformatted, 66 files would be left unchanged.

Guess none of us are?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we may be excluding tests.

Can you check you are also running the latest black specified in dev dependencies.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$ poetry run black --version
black, 22.10.0 (compiled: yes)
Python (CPython) 3.11.1

Which seems to be a later version that specified in poetry.lock?

[[package]]
name = "black"
version = "22.8.0"

Although weirdly:

black = "^22.3.0,<22.10.0"  # macos wheel issue on 22.10

from pyproject.toml

@davep davep merged commit 82dcf62 into Textualize:main Jan 6, 2023
@davep davep deleted the tree-node-children-prop branch January 6, 2023 15:17
rodrigogiraoserrao pushed a commit that referenced this pull request Jan 7, 2023
Also, in doing so, drop support for unrolling iterators and making them into
indexable sequences.

See the following feedback:

  #1495 (review)
  #1495 (comment)
nitzan-shaked pushed a commit to nitzan-shaked/textual that referenced this pull request Jan 10, 2023
Also, in doing so, drop support for unrolling iterators and making them into
indexable sequences.

See the following feedback:

  Textualize#1495 (review)
  Textualize#1495 (comment)
nitzan-shaked pushed a commit to nitzan-shaked/textual that referenced this pull request Jan 10, 2023
nitzan-shaked pushed a commit to nitzan-shaked/textual that referenced this pull request Jan 10, 2023
Also, in doing so, drop support for unrolling iterators and making them into
indexable sequences.

See the following feedback:

  Textualize#1495 (review)
  Textualize#1495 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Tree] Make TreeNode an immutable Sequence to allow for walking the tree
3 participants