[Question] Integer `Literal` arithmetic for, *e.g.*, physical units?
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
Línea de trabajo
Comienza leyendo el PEP 827 referenciado y compara su ejemplo de forma de array con la implementación de juguete de Unit y Quantity de este issue. Determina si integer Literal arithmetic, los generated integer Literal ranges y los dimension checks encajan en la propuesta; se considera terminado cuando se documenta el comportamiento compatible y cualquier cambio necesario en el sistema de tipos.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Hello! Apologies beforehand for polluting the repo's issues with questions tangential to PEP 827.
For the past few days I've been banging my head against Python's type system trying to replace a dependency on the otherwise excellent pint library with my own bare-bones implementation. I'm by no means a computer scientist nor a professional programmer, so I've struggled to come up with a way to express physical units' dimensionality through the type system.
While racking my brain I came upon PEP 827 and I found the array shape example particularly fitting. Does your current proposal allow for performing arithmetic operations on integer literals? E.g., Literal[1] + Literal[2] resolving to Literal[3]. Is there even a way to represent any integer literal similarly to LiteralString?
For further context, here is a toy example of what I'm trying to achieve:
from decimal import Decimal
from fractions import Fraction
from typing import Any, Literal, Self, final, overload, reveal_type
from typemap_extensions import GetArg, IsAssignable, RaiseError
type Range[T] = tuple[Literal[i] for i in ...] # How would one generate a tuple of integer `Literal`s?
type AddDims[T, S] = (
tuple[GetArg[T, tuple, i] + GetArg[S, tuple, i] for i in Range[Length[T]]] # Can integer `Literal`s be added?
if IsAssignable[Length[T], Length[S]] # Units belong to same system
else RaiseError[Literal["Incompatible unit system"], T, S]
)
type EqDims[T, S] = (
T
if IsAssignable[T, S]
else RaiseError[Literal["Incompatible dimensions"], T, S]
)
@final
class Unit[*T]:
"""Physical unit abstraction."""
def __init__(self: Self, dimensions: tuple[*T], /) -> None:
"""Infer dimensionality from exponents."""
self.dimensions: tuple[*T] = dimensions
@overload
def __mul__[*S](
self: Self, other: Unit[*S], /
) -> Unit[AddDims[tuple[*T], tuple[*S]]]: ...
@overload
def __mul__[S: (Decimal, Fraction)](
self: Self, other: S, /
) -> Quantity[S, *T]: ...
def __mul__(self: Self, other: Any, /) -> Any:
"""Return `Unit` with computed dimensions or `Quantity`."""
raise NotImplementedError()
def __rmul__[S: (Decimal, Fraction)](
self: Self, other: S, /
) -> Quantity[S, *T]:
"""Return `Quantity` from scalar and `Unit`."""
raise NotImplementedError()
@final
class Quantity[T: (Decimal, Fraction), *S]:
"""Physical quantity abstraction."""
def __init__(self: Self, magnitude: T, unit: Unit[*S], /) -> None:
"""Infer dimensionality from `Unit`."""
self.magnitude: T = magnitude
self.unit: Unit[*S] = unit
def __add__[*U](
self: Self, other: Quantity[T, *U], /
) -> Quantity[T, EqDims[tuple[*S], tuple[*U]]]:
"""Disallow addition when dimensions do not match."""
raise NotImplementedError()
# Expected behavior:
s = Unit((0, 1))
mps = Unit((1, -1))
reveal_type(s) # Unit[Literal[0], Literal[1]]
reveal_type(mps) # Unit[Literal[1], Literal[-1]]
m = s * mps
reveal_type(m) # Unit[Literal[1], Literal[0]]
dist = Decimal(10) * m
speed = Decimal(1) * mps
reveal_type(dist) # Quantity[Decimal, Unit[Literal[1], Literal[0]]
reveal_type(speed) # Quantity[Decimal, Unit[Literal[1], Literal[-1]]]
reveal_type(dist + dist) # Quantity[Decimal, Unit[Literal[1], Literal[0]]]
reveal_type(dist + speed) # Error: Incompatible dimensions
Range and AddDims are pseudo-code; I'm not exactly sure whether the operation would be allowed and whether that's how you'd retrieve the exponent from the tuple.
Does this kind of behavior fit within the scope of the PEP? Or would it require additional modifications to the type system such as allowing subclassing or changing how Literals are inferred?
Looking forward to hearing what becomes of the PEP regardless; we're all sure to find some interesting applications for the proposed additions!
- Lenguaje dominante
- Python
- Estrellas
- 25
- Forks
- 3
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de vercel-labs/python-typemap
-
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
vercel-labs/python-typemap#123 ·
Todos los issues de vercel-labs/python-typemap
Issues similares
-
bug confirmed issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
open-webui/open-webui#30750 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
OpenwaterHealth/openmotion-bloodflow-app#604 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
good first issue
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100