Rank-typing
@jorenham ci sta già lavorando.
Dal 4/5/2025.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
Shape-typing is often described as being able to distinguish between axes or their their sizes. But in Python's current type-system, that isn't realistically possible. If you remove the individual axes from a shape, you end up with just a rank, a.k.a. ndim. At runtime it's trivially simple, because it's just an int. But helpfully describing it using static typing is quite the opposite, and is probably the biggest typing-challenge I've ever had to solve.
For a long time, I thought that integer tuples would be the only option we could use for this. But for many situations, that would be very impractical to use, and limited in its expressiveness. I'm not sure if it would have even been worth it.
But I recently figured out an overpowered trick that I've been calling "static embedding", with which I was able to encode the complete set of NEP 50 promotion rules within the scalar types. That made it possible to write a couple of Casts* type-aliases (powered by typing.Protocol), which, when applied to the binary scalar operator methods, reduced __init__.pyi by over 5,000 LOC (!). That made me realize that the underlying "static embedding" principle could also be used for the broadcasting rules, i.e. the main use-case of shape- rank-typing.
And so far, it's looking pretty promising. It may also provide a way to simplify the array-like typing aliases for specific ndim, by associating e.g. Sequence[Sequence[T]] with the 2-d rank-type, Rank2.
This issue is intended as a tracker for the rank-typing progress. See the PR's below for the juicy details:
- #538
- #544
- #545
- #550
- #552
- #559
- #714
For relevant discussion with additional details, see:
- numpy/numpy#16544
- python/typing#513
- #578
- Lingua principale
- Python
- Stelle
- 79
- Fork
- 8
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di numpy/numtype
-
topic: documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
topic: documentation
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
long pyright analysis timesForse di nuovo libera @jorenham l’ha presa 421 giorni fa e non c’è nessuna pull request aperta. Apertablame: Pyright tool: basedpyright
-
numpy.generic stubs: Incomplete
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
-
_numtype stubs: Refactor
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
Tutte le issue di numpy/numtype
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
NousResearch/hermes-plugin-claude-subscription-directsdk#94 ·
I maintainer di solito rispondono entro 1 giorno
-
namespace operations
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
EclipseFdn/open-vsx.org#13702 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
modelscope/ms-swift#10287 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
modelscope/FunASR#3757 ·
I maintainer di solito rispondono entro 1 giorno