Summary

When using construct with strict static type checkers (e.g. pyright/basedpyright), users get typing friction because the package does not provide dedicated stub files and pyright reports missing type information.

Current behavior

In projects with strict checking enabled, importing common primitives can trigger diagnostics like:

• Stub file not found for "construct"

Example import:

from construct import Int8ul, Int16ul, Int32ul

Expected behavior

construct should provide pyright-friendly typing metadata so strict checkers can type-check common usage without local workaround stubs.

Possible solutions

1. Ship a py.typed marker and improve inline annotations, or
2. Provide .pyi stubs for the public API (even partial/minimal initially), especially commonly used primitives/combinators.

Why this matters

Downstream projects currently maintain local custom stubs just to satisfy strict type checking, which is hard to maintain and easy to drift.

What I checked

I searched existing issues and found:

• support of type hints #886 (support of type hints)
• "Operator not supported" type error when using singleton constructs #1115 (singleton operator-related type error)

I did not find a focused issue for pyright/basedpyright missing-stub metadata for construct package imports.

If this should be tracked elsewhere or there is an in-progress branch/package for stubs, I'd be happy to test it.