Spell out where views are allowed

Open
#331 15 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Stale
Tech stack
python, pytorch
Domain
documentation

Research direction

Start with the linked copies, views, and mutation section and review array_api_compat PR 298, especially the sum example. Compare the listed view-producing functions with the other operations raised in the issue, then document an explicit, agreed scope for when views are allowed; done means the standard clearly resolves these cases.

Written by the indexing model from the issue text.

Description

In https://data-apis.org/array-api/latest/design_topics/copies_views_and_mutation.html, the Standard says

Array API consumers are strongly advised to avoid any mutating operations when an array object may [...] be a “view” [...] It is not always clear, however, when a library will return a view and when it will return a copy. This standard does not attempt to specify this—libraries may do either.

The above is fine after __getitem__ , asarray(..., copy=None), astype(..., copy=False), and similar functions that are explicitly explained by the standard to potentially return views.

However, there are a few corner cases where views could be possible but a normal user is very unlikely to think about them.
I just stumbled on one in https://github.com/data-apis/array-api-compat/pull/298, where array_api_compat.torch.sum(x, dtype=x.dtype, axis=()) was accidentally returning x instead of a copy of it.

There are a few more cases where a library could try to be smart; for example

  • search functions (min, max, other?) could return a view to the minimum/maximum point
  • replacement functions (minimum, maximum, clip, where) could return one of the input arrays when there is nothing to do
  • same for arithmetic functions (__add__ / __sub__ vs. 0, __mul__ / __div__ vs. 1, etc.)
  • same for sort functions when they realise the input is already sorted
  • possibly more

In real life, I expect end users to assume that the above functions will always return a copy.
I think the standard should spell this out, limiting the possibily of views to an explicit list of allowed functions:

  • __getitem__
  • asarray
  • astype
  • __dlpack__
  • from_dlpack
  • reshape
  • broacast_to
  • broadcast_arrays
  • ...more?
Dominant language
Python
Stars
131
Forks
49
Avg merge
2d 8h
Merged PRs (30d)
6

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from data-apis/array-api-compat

All issues in data-apis/array-api-compat

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.