Since you are now raising a deprecation warning, all tests are failing. So, the tests need to be updated in line with the new API.

Performance gains look modest but are still very welcome.

I believe it is fit to review now @quaquel

Hi @quaquel
I was working on it for past days so I made some unrelated changes unintentionally. Sorry for that
Now I've reverted them to clean up the diff

The PR is now back to just the essentials:

1. Added the new dunder methods to support the NumPy array interface.
2. Added deprecation warnings to the old methods (set_cells, etc.) without removing them.

Tests have been updated to handle the warnings.

Hi @quaquel I have now removed all the dunder(magic) methods and accordingly updated the PR description

How do you want to proceed? Just merge this for now or do you want to take a second stab at the dunder methods as part of this PR. I am fine either way.

I think we should merge this first so that it would be easier for anyone(or us) working on #3072

@EwoutH, what do you think? PropertyLayer.data or PropertyLayer.values as the name for getting the numpy array behind the property layer.

I am fine either way, and we should not overthink it.

I did a quick search to check the conventions.

While Pandas uses .values, they are slowly moving away from it in favor of .to_numpy(). On the other hand, Xarray and NumPy Masked Arrays (which are arguably closer to our grid structure) both use .data to expose the underlying array.

I think sticking with .data makes more sense given those precedents.

Checkout : https://stackoverflow.com/questions/13187778/convert-pandas-dataframe-to-numpy-array#:~:text=Use%20df.,values%20%2C%20here's%20why.&text=It's%20time%20to%20deprecate%20your,Index%20and%20Series%20objects%20only.

I think .values is slightly more intuitive. But both would work.

I while I really appreciate this effort, I would really like to put of making an (breaking) API change until we have figured out how PropertyLayers are going to fit in the bigger picture.

If some changes could be made without changing the API, like by making the implementations behind the current methods more elegant or NumPy native, that could already happen.

I while I really appreciate this effort, I would really like to put of making an (breaking) API change until we have figured out how PropertyLayers are going to fit in the bigger picture.

Everything here is backward compatible, so there are no API-breaking changes; just a cleaner and faster alternative API.

We're deprecating stuff, that's basically an announced API break. Just not enforced for now.

Also I have my doubts if we should already add another API. While direct nparray access is probably useful in some cases, we might also expose it through the spaces those propertylayers are attached to.

Also I have my doubts if we should already add another API. While direct nparray access is probably useful in some cases, we might also expose it through the spaces those propertylayers are attached to.

This is exactly what this PR does: space.property_layer.data, while already working, with th is PR works much more cleanly and becomes the preferred method. That is: this PR makes doing space.property_layer.data faster by eliminating intermediate steps, and highlights to users that this faster approach is the preferred method going forward.

@codebreaker32, I had a longer in person conversation with @EwoutH. Given the ongoing conversations about spaces in Mesa 4, we decided not to deprecate anything yet. So, if you can remove those warnings, we think this should be good to go.

Thanks for the update, @quaquel.

I will go ahead and remove the deprecation warnings.

One question: Can we still optimize the existing functions (like set_cells, modify_cells)? I could rewrite them to use the direct .data operations internally, so they are faster and cleaner, even if we aren't officially deprecating them yet.

yes, feel free to rewrite them but then also profile the difference

I could rewrite them to use the direct .data operations internally, so they are faster and cleaner

Yes, this is fine and appreciated.

This also could be separate PR(s), that might make testing and reviewing easier.

Summary of Changes

This update simplifies the PropertyLayer implementation, improves performance, and makes NumPy integration more explicit and predictable.

1. Direct exposure of NumPy data

• Removed the @property data getter/setter indirection.
• data is now a public NumPy array, enabling slicing, masking, and aggregation without wrappers
• Eliminates unnecessary np.copyto overhead.

2. More efficient in-place updates

• set_cells and modify_cells now operate directly on self.data.
• Conditional updates use boolean masks instead of rebuilding arrays.

3. Improved modify_cells semantics

• Operations now update only the selected cells, not the whole grid.

Hi @quaquel @EwoutH,

I have updated the PR. I initially tried a simple rename from .data to .values, but it caused cascading failures. The reason is that the existing data attribute was actually a @property with specific setter logic (calling set_cells) that legacy code relies on.

I will change it in subsequent PRs

Can you update the original PR starting post to reflect the final version? I hope to review this later today, and if I don't see anything strange, merge it.

I will change it in subsequent PRs

I am fine with leaving it as .data for now. @EwoutH and I discussed removing the PropertyLayer class in Mesa 4 in favour of directly using numpy arrays. Additionally, changing the name now would be a deprecation and a hassle we can avoid.

Performance benchmarks:

@codebreaker32 Thanks for the PR. Could you check if the PR description is now fully up to date with the final implementation in this merged PR?

Yes, the PR description is now up to date