trimesh and shapely objects are hasheable... so... (it allows some playful hacks)

[villares]

You can use the `functools.cache' decorator on functions that get them as arguments, and it might allow you to convert them only when they change, otherwise returning a cached py5.Py5Shape object.

import functools 

@functools.cache    # or @functools.lru_cache(maxsize=30) if you will recalculate the mesh a lot
def convert_obj(obj):
    return py5.convert_shape(obj)

[hx2A]

They are hashable but only Shapely 2.0 objects are immutable. Shapely <2.0 objects and Trimesh objects are not. Relying on hash() for mutable objects is not a good idea.

However, I see why you are asking this. Currently the user now has a chore to convert an object once with convert_shape() and then to save the output. Is there a way to relieve the user of this burden that is also safe and reliable? I don't know, but let's think about this and see what we can come up with.

[hx2A]

Ah, well, I've faced the same problem with needing to avoid repeatedly converting the same object, and I've been addressing it by converting in setup and storing the result in a global variable. This works, but it is a bit tedious when you have half a dozen objects to convert. A working caching mechanism would add a lot of value.

I want to think through some of the details of the design before implementing it so it won't go in the next release, but it will be in the release after the next one. I'll open an issue to track this.

[hx2A]

See #420

[villares]

See #420

If you worry about caching eating too much memory, maybe you could use @lru_cache with a maxlen= ...

[hx2A]

If I set a fixed size there'd need to be another method for users to set the size. I was more concerned about automatically caching Java objects that would never be used again that overwhelm the JVM. I think the guidance should be to use convert_shape() if they are going to use the converted object once and use cached_convert_shape() if they used it multiple times, with the latter being the equivalent memory impact of calling convert_shape() in setup, storing in a global variable, etc.

[hx2A]

This approach is dependent on the other libraries' hash functions being comprehensive so that there are no ways to alter the object without also changing the hash. Given the complexity of the trimesh library I'm skeptical that that is the case.

It seems the trimesh folks have thought carefully about hashing objects:

https://trimesh.org/trimesh.caching.html#trimesh.caching.TrackedArray