use protocols instead of optional 3rd party dependencies in public type annotations

[MarcoGorelli]

This was brought up here: https://discord.com/channels/1235257048170762310/1272835922924273694/1439943293860446292

is there any particular reason to use numpdy ndarrays concrete types instead of Protocols?
This is a issue I already talked about in Polars here:
pola-rs/polars#24436

If numpy is not installed in the venv, the LSP will complain each time I'm updating narwhals/polars about unknown numpy types, and I have to manually delete them to fix it.

I think it's a valid request

Dan's comment:

Yeah I think using Protocols more would help your use-case

I've been adding some for solving the same issue in narwhals._native.py - but hadn't considered numpy.

I think the main challenge with ndarray is that we'd need to define something that only matches that - but doesn't match the 8474930 other things that based their API on it 😂

TBH I'd be ok with accidentally matching something non-numpy, if it's not supported there'll be a runtime error anyway

[dangotbanned]

Oooh yeah I forgot about this one

TBH I'd be ok with accidentally matching something non-numpy, if it's not supported there'll be a runtime error anyway

Would picking a subset of array-api work?

If not, the main overlap I think we'd want to avoid is with pd.Series.
It has a lot of members that would match np.ndarray by name, but the signatures are usually incompatible

[MarcoGorelli]

Would picking a subset of array-api work?

yeah, sure