dwavesystems / dwavesystems/dimod
Consider making BQM.num_variables, BQM.num_interactions and BQM.shape methods rather than properties
- 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
Assessment
This issue has not been assessed yet.