Skip to content

Convert field_info into a property so it can be created on first access. #5250

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.

Sign up for GitHub

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

Merged
merged 2 commits into from
Aug 29, 2025
Merged

Convert field_info into a property so it can be created on first access. #5250

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5376892
Convert field_info into a property so it can be created on first access.
brittonsmith Aug 4, 2025
33db412
Refactor to allow create_field_info to only be executed once.
brittonsmith Aug 4, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions yt/data_objects/static_output.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -171,6 +171,7 @@ class Dataset(abc.ABC):
field_units: dict[AnyFieldKey, Unit] | None = None
derived_field_list = requires_index("derived_field_list")
fields = requires_index("fields")
_field_info = None
conversion_factors: dict[str, float] | None = None
# _instantiated represents an instantiation time (since Epoch)
# the default is a place holder sentinel, falsy value
Expand Down Expand Up @@ -654,7 +655,18 @@ def print_stats(self):
def field_list(self):
return self.index.field_list

@property
def field_info(self):
if self._field_info is None:
self.create_field_info()
return self._field_info

@field_info.setter
Copy link
Member

Choose a reason for hiding this comment

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

Is this necessary ?
Immutability has a lot of value when dealing with parallelism, so I would advise to avoid introducing mutability where it's not needed.

Copy link
Member Author

@brittonsmith brittonsmith Aug 4, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

We are already doing this in far more critical places, e.g., the index. In fact, I would argue that we want some measure of this here.

Copy link
Member

Choose a reason for hiding this comment

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

But what for ? Unless there's a test exercising it I don't understand the point.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sorry, I replied without really thinking this through. We don't do this with index, but we probably do want to allow this to be settable.

Copy link
Member Author

Choose a reason for hiding this comment

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

Specifically, without this, we can't do what's in the tests in PR #5211.

Copy link
Member

Choose a reason for hiding this comment

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

I think I'm even more confused now. I don't see the connection with #5211

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm referring to how the tests in that PR manually alter entries in field_info. You wouldn't be able to do that without having the setter.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've come around on not having a setter for field_info. When it wasn't a property we allowed it to be set by anyone, but maybe it's better to be safe since we can.

Copy link
Member Author

Choose a reason for hiding this comment

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

Just to tie this off, the setter is necessary if we want to avoid modifying all the places in the frontends that setup the field_info on their own, which I believe we do. I also think we should not worry about immutability since we didn't have that before anyway. There's no reason to impose this restriction now. This change doesn't modify existing behavior and only allows us to refer to ds.field_info without having to think about whether it has been created yet. I don't see a reason not to do this.

def field_info(self, value):
self._field_info = value

def create_field_info(self):
self.index
Copy link
Member Author

Choose a reason for hiding this comment

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

I'm going to admit that this isn't a great thing to do as instantiating the index called create_field_info. What I think would be better is renaming this _create_field_info to remove the expectation that anyone ever call it. I would then change line 661 above to simply self.index.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've refactored this so that we only ever do one pass through create_field_info.

self.field_dependencies = {}
self.derived_field_list = []
self.filtered_particle_types = []
Expand Down
Loading