Purpose

Data API documentation -https://data-apis.org/array-api/latest/purpose_and_scope.html

Change List

• Array Object -class Array

  • Parameters
    • src ->x. Motivation:src is commonly used to name the source code folders and not as a parameter in the class. Other options likearr (is used in the class),a (not intuitive), orobject (likely meant by ANY object, but it is not true in this case) seem like not a good fit, so I chosex is as it is an intuitive parameter to any function. Also, it occurs in the specification, e.g.,here.
    • dims ->shape. Motivation:dims (orndim) is more commonly used asint, andshape astuple, so the change is understandable and should not cause any confusion.
    • is_device ->pointer_source. Motivation: add more intuition, already discussed with@syurkevi, but most likely is subject to change in further PRs with Device implementation.
    • dtype,offset, andstrides are left unchanged due to their pretty clear purpose.
  • RemoveBaseClass because it has only one purpose to set a defaultarr value asctypes.c_void_p, so it was moved to theArray class.
  • Added mocks for required new operators that will be implemented in follow-up PRs
  • Minor logical changes behind C functions processing in the Python class operators wrappers
  • Minor changes in__repr__ to makeArray more descriptive during the prototyping. Will be merged withdisplay() method as numpy was selected as a state-of-the-art example
  • Renamed theelement method tosize as it is more common in data APIs.
  • Renamed theto_ctype method toto_ctype_array as it actually returns the C Array
  • Removeddims as has the same functionality as theshape method and the last one is required by the specification
  • Renamednumdims tondim as it is shorter and no more mess with other dim-like synonyms included. And yes. it is mentioned in the specification
  • Removed thetype method as it has no applied sense. The value can now be retrieved by accessing the specificDtype value, e.g.,Array().dtype.c_api_value (more about data types changes below)
  • Major code refactoring to provide a code style more intuitive and fits the PEP recommendations.
  • Other methods that were implemented in the original wrapper partially will be moved to the array_api. The whole list and key changes will be provided in Change List.

• Data Types -class Dtype

  • Changed todataclass (also, subject to change) because its main purpose was to be a "bridge" between python types and C types, so the batch of different dictionaries was reduced to classes with 4 parameters and a couple of helper methods
  • Parameters
    • typecode - previouslyto_dtype()
    • c_type - previouslyto_c_type()
    • typename - left unchanged
    • c_api_value - previously was an_Enum that was a match to C++ library dtypeEnum. (P.S. naming was discussed with@syurkevi and I really liked that idea)

• Other (subject to change in follow-up PRs)

  • Changed the implementation ofdim4() which is now converted to classCShape. The main purpose was to convert Python shapes to C Shapes, so the logic remains the same, but the current solution helps to avoid extra code duplication and bugs during the type conversions.
  • Separatedc_dim_t from the arch investigation
  • Added mocks for planned follow-up changes with Device, Dtype functions, utils (all() andany() methods), and ArrayFire custom backend solution

• Testing

  • Added mypy typings that harshly burst code intuition and readability
  • Changed custom namings for types from ctypes. This adds more intuition and simplifies debugging process
  • Removedimport * to simplify debugging process and avoid recursive re-importing as it meets in the original library
  • Added primitive unit tests

• Dev Flow

  • Added CI
  • Addedflake8 andautopep8 code style checkers
  • Addedisort imports checker
  • Addedflake8-quotes for quotes usage unification to avoid the mess with docstrings and comments
  • Addedmypy for typing as dev requirements to the new dev flow sample
  • Added test suite withpytest
  • Added test coverage report (currently code coverage is about 83% - planned 100%)

Notes

This is the first PR among the series of Data API implementations. A lot of changes are subject to change in follow-ups and a bunch of bags may occur till the wholearray_api implementation. Any suggestions, bug reports, and feature requests are highly welcome (but may be implemented sooner or later due to the marked plan of development).