We want to audit the cuda.core API before we release 1.0 to highlight anything that we want to change to prior to release. Once cuda.core-1.0.0 release, we will be locked into a few years support cycle so if there is any APIs that we want to break we must be do it now.

@mdboom plans to do this as a series of prompts to find issues and tackle from there.

Unintended exposure

In the cuda_core package, please analyse all of the __init__.py files and find any symbols that are exposed unintendedly. Especially symbols defined outside of the cuda_core package, private members or implementation details.

• cuda_core __init__.py files expose implementation details and external symbols #1931

Find any helper classes that are not intended to be instantiated by end users and make them private.

• Privatize system.Device helper classes #1942

Use __all__ and import * together to make it easier to control exposure.

Prompt based on @Andy-Jost's guideline here about using __all__ and import * together to more easily control exposure. Most subpackages were already doing this, but graph was not.

• Restructure graph/ subpackage to use __all__ and star imports #1944

Naming

Class member naming consistency

I want to audit the naming of all members of every public class in cuda_core. You can ignore the private classes, I only care about properties and methods exposed through the public API.

• Check for PEP8 compliance

• Properties should be nouns

• Methods should be verbs

• Identify methods that could be properties (i.e. take no arguments and do minimal calculation)

• Check for any naming inconsistencies, such as when different english words or abbreviation forms are used for the same concept or datatype

• Make sure conceptual method pairs are matching, e.g. add/remove, get/set, create/delete

• cuda.core: method/member/property naming audit #1945

• cuda.core.system: Naming improvements suggested in #1945 #1946

• cuda.core: complete the naming audit from #1945 #1986

Class naming consistency

Can you please look at all classes exposed in the public API of cuda_core. I want you to look just at the names of the classes, not any members or methods. Please make sure they are all PEP8 compliant and that the same words are used for the same concepts.

• cuda.core: public API class naming audit (PEP 8 and consistency) #1950
• Rename GraphDef -> GraphDefinition and Condition -> GraphCondition #1984

Function naming consistency

Can you please look at all free functions in the public API of cuda_core and identify any that are not PEP8 compliant and also check for consistent naming of concepts (the same word is used for the same concept, and abbreviation, if any, is consistent).

(This did not produce any actionable results).

Connection to underlying API

Problematic API contracts

I asked my bot to identify API contracts against the underlying low-level APIs to see if any of them will be problematic with respect to supporting all of the underlying functionality in the future.

• cuda.core: two API contracts that could complicate future changes #1949

Reveal of C-style error-handling patterns

• cuda.core: audit of C-style error-code return patterns in public API #1951

Enums vs. strings

There are places where small sets of string values are accepted or returned, which could be enums if we choose to go that way.

• cuda.core: Replace string literals with enums in public API #1995