Document the name parameter in perlin() docstring#3468
Conversation
brendancol
left a comment
There was a problem hiding this comment.
Domain-aware review (API-consistency sweep, perlin module).
Scope check: the diff is exactly the docstring entry plus two focused tests. No signature, behavior, or backend-dispatch changes. The name wording and default='perlin' match the sibling generate_terrain() convention, which is the consistency target.
Blockers: none.
Suggestions: none. test_perlin_name_param covers default and custom values on the numpy path; the name plumbing in perlin() is backend-agnostic (set on the wrapping DataArray after dispatch), so a numpy-only assertion is sufficient and a per-backend matrix would add no signal.
Nits: none.
Verified: pytest xrspatial/tests/test_perlin.py passes 14/14 including the GPU paths on a CUDA host.
…tency-perlin-2026-06-23
…tency-perlin-2026-06-23 # Conflicts: # xrspatial/perlin.py # xrspatial/tests/test_perlin.py
Closes #3465
perlin()accepts anameparameter that sets the output DataArray name, but the docstring's Parameters section never mentioned it. The siblinggenerate_terrain()documents the same parameter, so this aligns the two.name : str, default='perlin'entry to theperlin()docstring, matching thegenerate_terrainstyle.namedefault and custom value are honored, and the docstring documents the parameter.Docstring only. No signature change, no behavior change. Backends unaffected (numpy / cupy / dask+numpy / dask+cupy).
Test plan:
pytest xrspatial/tests/test_perlin.py(14 passed, GPU paths included on a CUDA host)