Embed the dtype-like types in the scalar types

Open

#138 opened on Feb 14, 2025 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty: 5/5
Estimated time: Over a week
Newbie friendliness: 25/100

Issue type: Feature
Clarity: Mostly clear
Activity status: Stale
Tech stack: python
Domain: tooling

Research direction

Start by reviewing the scalar-type stubs and the _numtype definitions, especially the existing _numtype.ToDType* aliases and CastsWith* aliases. Check whether the proposed __dtype_like__ and CanDTypeLike signatures can be resolved by the supported type checker. Done means the individual aliases are unified without losing specificity and the affected scalar typing behavior is validated.

Written by the indexing model from the issue text.

Description

stubs: Enhancement stubs: Refactor

Similar to the NEP 50 embeddings that are powering the _numtype.CastsWith* type alias, it should be possible to create an dynamically specializing dtype-like alias. This unifies all 24 individual _numtype.ToDType* as a single generic type, without loss of specificity.

The idea is to define a type-check only method in each scalar-type, e.g in int8:

@type_check_only
def __dtype_like__(self, like: int8, /) -> tuple[
    type[int8 | ct.c_int8] | HasDType[int8] | L["int8", "i1", ...],
    Self,
]: ...

The return-types of must not overlap, and overloads cannot be used, and don't annotate like with Self.

In _numtype:

@type_check_only
class CanDTypeLike[
    +DTypeLikeT,
    +OutT: np.generic,
    -LikeT: np.generic = np.generic,
](Protocol):
    def __dtype_like__(self, like: LikeT, /) -> tuple[DTypeLikeT, OutT]: ...

And I'm hoping it can be used like this

def scalar[
    DTypeLikeT, 
    OutT: (bool_, int8, uint8, int16, ...),
    LikeT: np.generic = np.generic,
](
    dtype: _DTypeLikeT,
    *,
    like: LikeT | None = None
    __out: CanDTypeLike[DTypeLikeT, OutT, LikeT] = ...,  # type-check only
) -> OutT: ...

The LikeT is optional, but can be used to dynamically constrain OutT. It can also be provided manually, which is less verbose than having to re-define the entire "typevar with constraints".

It's not certain whether this will work in practice, as it requires pretty powerful constraint solving. I guess there's only one way to find out 🤷🏻

Dominant language: Python
Stars: 79
Forks: 8
PR merge metrics: No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

Read the whole issue, then the project's contributing guide.
Comment on the issue to say you are picking it up — it saves two people doing the same work.
Fork the repository and make your change on a branch.
Open a pull request that references the issue number.

Similar issues

[essnmx] Fix typo in NXLauetof application definition Open

essnmx good first issue

Difficulty 1/5 Under an hour Newbie friendliness 95/100

scipp/ess#760 · Opened Sep 23, 2026
[Feature] 奇物选择添加优先级 Open

Difficulty 2/5 1-3 hours Newbie friendliness 65/100

syfoud/Simulated_Scepter#174 · Opened Sep 23, 2026
garak adapter grades a NaN detector score as PASS Open

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

Giskard-AI/giskard-oss#2840 · 1 comment · Opened Sep 23, 2026
A claim comment carrying the issue number is silently declined while the workflow reports success Open

area: repo bug perceived difficulty: 2

Difficulty 2/5 1-3 hours Newbie friendliness 70/100

Nitjsefnie-Harness-Commons/daedalus#926 · Opened Sep 23, 2026
`IOCExtractor` always fails: `ioc_analyzer.build()` takes 1 argument but the agent dispatcher passes 2 Open

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

yeti-platform/yeti#1380 · Opened Sep 23, 2026

More Python issues