dwavesystems / dwavesystems/dimod

Consider making BQM.num_variables, BQM.num_interactions and BQM.shape methods rather than properties

Open
#849 8 comments 0 reactions 0 assignees View on GitHub
enhancement question
Dominant language
Python
Stars
143
Forks
91
Avg merge
1h 24m
Merged PRs (30d)
3

Description

Currently, `BQM.num_variables`, `BQM.num_interactions` and `BQM.shape` are all properties rather than methods. I think that it would be better to make them proper methods.

Pro:
* Determining `num_interactions` is an `O(num_variables)` operation, so having it as a property is misleading
* Potentially extendable in the future, e.g. `bqm.num_interactions(v)` could return the degree of `v`
* `DQM.num_variables()` and `DQM.num_cases()` are currently implemented as methods, which is inconsistent
* `num_interactions` and `num_variables` are already read-only. As a method that would be even more explicit

Con:
* Backwards compatibility break, though I think we can mitigate by making them inherit from numeric and callable (see below)
* Having `.shape` as a property is consistent with NumPy

**Additional context**
If we don't want to break backwards compatibility through a deprecation period
```
from collections.abc import Callable

class CallableInt(int, Callable):
def __call__(self):
return self
```
works out of the box. Though getting it to raise a deprecation warning if it's not treated as a callable would require something like
```
import warnings

from collections.abc import Callable
from numbers import Integral

class CallableInt(Integral, Callable):
def __init__(self, value):
self.value = int(value)

def __call__(self):
return self.value

def __add__(self, other):
warnings.warn("In the future will be callable", DeprecationWarning)
return self.value + other

...
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.