Repository navigation
Is MemoryResource base class changed on the main branch on purpose? #1359
Description
✓ Check 0.4.0 MemoryResource
$ cd /local/home/leof/dev/cuda-python && python -c "
import sys
sys.path.insert(0, '/tmp/cuda-core-0.4.0')
from cuda.core.experimental._memory import MemoryResource
import inspect
print('cuda-core 0.4.0 MemoryResource:')
print('=' * 60)
print(f'Is abstract: {inspect.isabstract(MemoryResource)}')
print(f'Has __abstractmethods__: {hasattr(MemoryResource, \"__abstractmethods__\")}')
if hasattr(MemoryResource, '__abstractmethods__'):
print(f'Abstract methods: {sorted(MemoryResource.__abstractmethods__)}')
print(f'\\nAll public methods and properties:')
for name in sorted(dir(MemoryResource)):
if not name.startswith('_'):
print(f' - {name}')
"
╭───────────────────────────────────────────────────────────────────────────────────╮
│ cuda-core 0.4.0 MemoryResource: │
│ ============================================================ │
│ Is abstract: False │
│ Has __abstractmethods__: False │
│ │
│ All public methods and properties: │
│ - allocate │
│ - deallocate │
│ - device_id │
│ - is_device_accessible │
│ - is_host_accessible │
│ <exited with exit code 0> │
╰───────────────────────────────────────────────────────────────────────────────────╯
● Interesting! So:
- 0.3.0: MemoryResource IS abstract, has allocate, deallocate, device_id, is_device_accessible, is_host_accessible as abstract
- 0.4.0: MemoryResource is NOT abstract, still has the 5 members but NOT abstract
- Current (main branch): MemoryResource has abstract methods but missing the 3 property definitions
This is a breaking change. The ABC interface is broken because the properties are missing. Let me add them back:
○ Edit cuda/core/experimental/_memory/_buffer.pyx
╭──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ Edit file │
│ │
│ _buffer.pyx +18 -0 │
│ /local/home/leof/dev/cuda-python/cuda_core/cuda/core/experimental/_memory │
│ │
│ 501 """ │
│ 502 ... │
│ 503 │
│ 504 + @property │
│ 505 + @abc.abstractmethod │
│ 506 + def is_device_accessible(self) -> bool: │
│ 507 + """Whether buffers allocated by this resource are device-accessible.""" │
│ 508 + ... │
│ 509 + │
│ 510 + @property │
│ 511 + @abc.abstractmethod │
│ 512 + def is_host_accessible(self) -> bool: │
│ 513 + """Whether buffers allocated by this resource are host-accessible.""" │
│ 514 + ... │
│ 515 │
│ 516 + @property │
│ 517 + @abc.abstractmethod │
│ 518 + def device_id(self) -> int: │
│ 519 + """Device ID associated with this memory resource, or -1 if not applicable.""" │
│ 520 + ... │
│ 521 + │
│ 522 + │
│ 523 # Helper Functions │
│ 524 # ---------------- │
│ 525 cdef void _validate_value_against_bitwidth(int bitwidth, int64_t value, bint is_signed=False) except *: │
│ │
│ Do you want to edit /local/home/leof/dev/cuda-python/cuda_core/cuda/core/experimental/_memory/_buffer.pyx? │
│ │
│ ❯ 1. Yes │
│ 2. Yes, and approve all file operations for the rest of the running session │
│ 3. No, and tell Copilot what to do differently (Esc) │
│ │
│ Confirm with number keys or ↑↓ keys and Enter, Cancel with Esc │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
Activity
cpcloud commentedon Dec 11, 2025
What is this issue about? Can you clarify it with some human-written content? It's really hard to decipher what the problem is here.
cpcloud commentedon Dec 11, 2025
One issue with the
MemoryResouceclass is thatabc.<anything>has no effect without subclassingabc.ABCor settingmetaclass=abc.ABCMeta.leofang commentedon Dec 11, 2025
I thought the output was quite readable apart from the drawback that the ASCII color code is gone due to copy/paste 🙂 The 3 attributes are gone (Copilot bisects it to #1205, cc @Andy-Jost).
cpcloud commentedon Dec 11, 2025
The output is sort of meaningless without some kind of problem statement.
In what way was it changed and why is that a problem, etc.
Ideally we're not requiring maintainers to back out the motivations of issues based on a prompt + LLM output.
I want to know what motivated you to create the issue. A prompt and LLM output doesn't provide that information.