Class ModuleNameAttribute
- Namespace
- NumSharp
- Assembly
- NumSharp.dll
Marks a public type as the C# host of a NumPy module surface — the type whose public
members ARE that module's functions. np itself carries "np",
NDArray carries "ndarray", and each function-namespace facade
carries its dotted Python path ("np.random" on NumPyRandom,
"np.fft" on FourierModule, "np.linalg" on the nested
np.linalg class).
[AttributeUsage(AttributeTargets.Class|AttributeTargets.Struct, AllowMultiple = false, Inherited = false)]
public sealed class ModuleNameAttribute : Attribute- Inheritance
-
ModuleNameAttribute
- Inherited Members
Remarks
Consumed by coverage/NumSharp.Tools.ApiInventory, which discovers the surfaces to
reflect by scanning for this attribute instead of hardcoding a type list — so a NEW module
facade (a hypothetical np.strings, a polynomial module) becomes part of the NumPy
coverage artifact by annotation alone, with no tool or generator edit. Before this
existed the inventory hardcoded three types and silently mis-reported the whole
np.fft and np.linalg surfaces as missing.
Apply it to the type that DECLARES the module's functions, not to the property that
exposes it (np.fft the property is just the reachability path; the functions live
on FourierModule). Single-object DSL exports — np.r_, np.s_,
np.mgrid — take NO attribute: NumPy exports each as ONE object, so the property on
np is already the whole coverage row, and annotating their classes would wrongly
count every indexer overload as a module function.
Inherited is FALSE and load-bearing:
NDArray<T> derives from NDArray and must not be swept up as a
second "ndarray" host.
Constructors
ModuleNameAttribute(string)
public ModuleNameAttribute(string name)Parameters
namestring
Properties
Name
The NumPy-side module path: "np", "ndarray", "np.random", …
public string Name { get; }