SharpClaw's Python WENO path silently only uses the slow reconstructor

[mandli]

clawpack.pyclaw.limiters.reconstruct — the wrapper around the compiled PyWENO reconstructor — cannot be imported at all, in a checkout or an install:

>>> import clawpack.pyclaw.limiters.reconstruct
ModuleNotFoundError: No module named 'pyclaw'

Its only import, src/pyclaw/limiters/reconstruct.py:12, is pre-namespace:

import pyclaw.limiters.weno.reconstruct as recon    # needs `clawpack.` prefix

At src/pyclaw/sharpclaw/solver.py:13-18 it catches this and falls back to the older version.

The C extension itself build and installs fine so it looked like a one-line fix, but according to claude (see below) this is insufficient.

[mandli]

The C extension is fine. src/pyclaw/meson.build:278-284 builds it and it installs correctly as clawpack/pyclaw/limiters/weno/reconstruct.cpython-312-darwin.so, exporting the five families the wrapper looks up (smoothness_k*, weights_left_k*, weights_right_k*, reconstruct_left_k*, reconstruct_right_k*). The single import line is the whole defect.

What restoring it buys. Patching only that line in an installed copy:

• weno(5, q) then runs and agrees with the fallback to round-off — max|ql_C - ql_py| ≈ 3e-15 (smooth sine), 7e-15 (step), 3e-14 (uniform random), on interior points of a (1, 60) array. So this is a performance fix, not a change in results, at the order SharpClaw uses.
• It is 3.8x faster on a (3, 500) array: 0.017 ms/call vs 0.065 ms/call (200 calls, one machine — treat the ratio as indicative, not a benchmark).
• The C module also supports k=7 and k=9, which the fallback rejects. No current impact: solver.py:787 hardcodes recon.weno(5, q).

Why the one-line fix is not sufficient on its own. Only the fallback defines weno5_wave, which solver.py:792 calls for char_decomp == 1:

function	limiters/recon.py (fallback)	limiters/reconstruct.py (C)
weno(k, q)	yes (k=5 only)	yes (k=5,7,9)
weno5_wave(q, wave, s)	yes	no

Prefixing clawpack. would therefore swap a silent slowdown for an AttributeError on the wave-based reconstruction path. Options, in maintainers' hands since this is reconstruction code:

1. Import both and dispatch per function (weno from the C module,
   weno5_wave from recon).
2. Add weno5_wave to limiters/reconstruct.py.
3. Keep the try/except but make the fallback loud (warn) rather than silent.

Scope. Python kernel path only (lim_type == 2 in SharpClawSolver.dq_hyperbolic); the Fortran kernels use their own reconstruct.f90 and are unaffected.

Suggested test. Whatever the fix, assert which reconstructor is bound — a silent fallback is what let this sit unnoticed:

def test_sharpclaw_uses_the_compiled_reconstructor():
    from clawpack.pyclaw.sharpclaw import solver
    assert solver.recon.__name__.endswith('limiters.reconstruct')

Assisted-by: claude claude-opus-5[1m]