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 all commits
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
18 changes: 18 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,24 @@ 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.index
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):
# create_field_info will be called at the end of instantiating
# the index object. This will trigger index creation, which will
# call this function again.
if self._instantiated_index is None:
self.index
return

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