Skip to content

API: remove ndarray.base #80

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 22, 2023
Merged

API: remove ndarray.base #80

merged 2 commits into from
Mar 22, 2023

Conversation

ev-br
Copy link
Collaborator

@ev-br ev-br commented Mar 11, 2023

closes gh-47

Base tensor relationship is tracked via pytorch'es tensor._base already, so remove ndarray.base attribute.
Checking an wrapper array base becomes then

>>> a.get()._base is b.get()

instead of numpy's

>>> a.base is b

This is the second PR in the "stack" based off gh-70.

EDIT : a.get() is gone, so it's a.tensor._base now.

closes gh-47

Copy link
Collaborator

@lezcano lezcano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this clean-up, we can also remove the .get() method (now it's just ._tensor (or .tensor if you want, no need to make that member private, it's a bit unpythonic IMO) and ndarray._from_tensor(x) can be merged into the __init__ so that we can write the more natural ndarray(t).

@ev-br
Copy link
Collaborator Author

ev-br commented Mar 11, 2023

FWIW, I'd rather keep only having an argument-less __init__ or maybe even no __init__ at all, to avoid mixing up with https://numpy.org/doc/stable/reference/generated/numpy.ndarray.html which is very much not recommended for a long time now but is still used in old scripts here and there.

W.r.t. public or private tensor attribute, I suppose my instincts are from a library maintainer perspective : anything which is not explicitly private will get (ab)used in the wild and will cause backcompat issues down the line. Are we not worried about future backcompatibility?

@lezcano
Copy link
Collaborator

lezcano commented Mar 11, 2023

Note that this ndarray is not a public API but an intermediary artefact used by a compiler, so we should write it in whichever way we find easier.
Same for __init__ really. Note that it makes sense for np.ndarray(...) not to work because you can construct an array in a thousand ways. Our arrays are only thin wrappers around tensors, so we don't have that issue.
If you want to be extra sure that it's being used as expected, you can put an assert t is None or ìsinstance(t, torch.Tensor) in the __init__ constructor.

@ev-br
Copy link
Collaborator Author

ev-br commented Mar 12, 2023

OK, thanks. Having no public API does make it easier indeed.

FTR, I still believe constructing a thing from a tensor is a prime example for a from_tensor alternative constructor. That said, this is not my hill, not today anyway, and the last commit ditches the get() getter, adds ndarray.__init__(self, t: torch.Tensor), and makes ndarray.tensor public.

Copy link
Collaborator

@lezcano lezcano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice clean-up!

@ev-br ev-br force-pushed the normalizations branch 3 times, most recently from f5e5eaf to 7dced32 Compare March 22, 2023 23:29
Base automatically changed from normalizations to main March 22, 2023 23:41
ev-br added 2 commits March 23, 2023 02:45
Base is tracked via `self._tensor._base`. Use `a.get()._base is b.get()` instead
of numpy's `a.base is b`.
@ev-br ev-br merged commit f664001 into main Mar 22, 2023
@ev-br ev-br deleted the nuke_base branch March 22, 2023 23:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ndarray.base : worth keeping?
2 participants