Avoid manual cleanup of object attributes

[leofang]

Description

Try to avoid cleanup errors like this

Traceback (most recent call last):
  File "cuda/core/experimental/_memory.pyx", line 138, in cuda.core.experimental._memory.Buffer.close
SystemError: Objects/dictobject.c:2395: bad argument to internal function
Traceback (most recent call last):
  File "cuda/core/experimental/_memory.pyx", line 751, in cuda.core.experimental._memory.DeviceMemoryResource.close
SystemError: Objects/dictobject.c:2395: bad argument to internal function
Exception ignored in: 'cuda.core.experimental._memory.DeviceMemoryResource.__dealloc__'

Checklist

• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[leofang]

/ok to test 8a1ca77

[github-actions]

Doc Preview CI
🚀 View preview at https://nvidia.github.io/cuda-python/pr-preview/pr-1102/
https://nvidia.github.io/cuda-python/pr-preview/pr-1102/cuda-core/
https://nvidia.github.io/cuda-python/pr-preview/pr-1102/cuda-bindings/
https://nvidia.github.io/cuda-python/pr-preview/pr-1102/cuda-pathfinder/
Preview will be ready when the GitHub Pages deployment is complete.

[cpcloud]

This was something I had mentioned elsewhere, that we shouldn't be accessing object properties in a __dealloc__ code path.

Why is _ptr still being touched here?

From the Cython docs on __dealloc__:

In particular, don’t call any other methods of the object or do anything which might cause the object to be resurrected. It’s best if you stick to just deallocating C data.

Why not just do the minimum C-API invocation required in __dealloc__ and duplicate whatever you need to from close?

Then we're not going against the documented behavior and causing a crashing knowing that we could have avoided it all along.

[leofang]

self._ptr is a cdef attribute. I think it might be a confusion with self._ptr_obj?

Regardless, I don't believe this PR is needed. I think #1104 and #1105 together should fix everything for us.