Comparació del verificador de tipus Python: inferència de contenidor buit

Per què els contenidors buits trenquen els verificadors de tipus Python i què hi podeu fer

El sistema d'escriptura gradual de Python ha madurat significativament des que PEP 484 va introduir suggeriments de tipus el 2015. Avui en dia, milions de desenvolupadors confien en els verificadors de tipus estàtics per detectar errors abans que arribin a la producció. Però hi ha un racó subtil i frustrant del sistema de tipus que encara fa ensopegar fins i tot enginyers experimentats: quin tipus té un contenidor buit? Quan escriviu x = [] sense anotacions, el vostre verificador de tipus ha d'endevinar, i diferents correctores endevinen de manera diferent. Aquesta divergència crea problemes reals per als equips que mantenen grans bases de codi, on canviar o combinar els verificadors de tipus poden aparèixer centenars d'errors inesperats durant la nit.

Aquest article explica com els quatre verificadors de tipus Python principals (mypy, pyright, pytype i pyre) gestionen la inferència de contenidors buits, per què no estan d'acord i quines estratègies pràctiques podeu adoptar per escriure Python segur de tipus independentment de l'eina que trieu.

El problema bàsic: els contenidors buits són intrínsecament ambigus

Considereu aquesta línia innòcua de Python: resultats = []. Els resultats són una llista[int]? Una llista[str]? Una llista[dict[str, Qualsevol]]? Sense context addicional, realment no hi ha manera de saber-ho. El temps d'execució de Python no li importa (les llistes són heterogènies per naturalesa), però els verificadors de tipus estàtics han d'assignar un tipus concret a cada variable per fer la seva feina. Això crea una tensió fonamental entre la flexibilitat dinàmica de Python i les garanties que l'anàlisi estàtica intenta oferir.

El problema es combina amb diccionaris i conjunts. En realitat, un {} buit s'analitza com a dict, no com a conjunt, cosa que afegeix ambigüitat sintàctica a l'ambigüitat a nivell de tipus. I els contenidors imbricats (penseu a defaultdict(list) o resultats = {k: [] for k in keys}) fan que els motors d'inferència arribin als seus límits. Cada verificador de tipus ha desenvolupat les seves pròpies heurístiques i les diferències són més significatives del que s'adonen la majoria dels desenvolupadors.

En els sistemes de producció que processen càrregues de treball reals, ja sigui un CRM que gestiona els registres dels clients, un mòdul de facturació que genera línies de comanda o un canal d'anàlisi que agrega mètriques, els contenidors buits apareixen constantment com a patrons d'inicialització. Equivocar els seus tipus no només produeix advertències de linter; pot emmascarar errors genuïns que s'escampen al temps d'execució.

Mypy: inferència diferida amb qualsevol implícita

Mypy, el verificador de tipus Python més antic i més adoptat, adopta un enfocament relativament indulgent als contenidors buits. Quan troba x = [] a l'abast de la funció, intenta ajornar la decisió del tipus i inferir el tipus d'element a partir de l'ús posterior. Si escriviu x = [] seguit de x.append(42), mypy inferirà list[int]. Aquesta estratègia d'"unir-se" funciona sorprenentment bé per als casos senzills en què el contenidor s'omple dins del mateix àmbit.

No obstant això, el comportament de mypy canvia dràsticament segons el context i la configuració de rigor. A l'abast del mòdul (codi de nivell superior) o quan el contenidor es passa a una altra funció abans d'omplir-se, mypy sovint torna a list[Any]. Sota la marca --strict, això activa un error, però en el mode predeterminat passa en silenci. Això significa que els equips que executen mypy sense el mode estricte poden acumular desenes de contenidors implícits que actuen com a escotilles d'escapament del sistema de tipus, derrotant el seu propòsit.

Un comportament especialment subtil: les versions mypy anteriors a la 0.990 de vegades deduïen llista[Desconeguda] internament i després s'ampliaven a llista[Qualsevol] en l'assignació. Després de 0.990, la inferència es va endurir, però el canvi va trencar un nombre sorprenent de bases de codi del món real que havien estat confiant en el comportament permissiu sense adonar-se'n. Aquest és un tema recurrent: els canvis a la inferència de contenidors buits es troben entre les actualitzacions del verificador de tipus més disruptives perquè els patrons són molt omnipresents.

Pyright: inferència estricta i tipus "desconegut"

Pyright, desenvolupat per Microsoft i impulsant Pylance a VS Code, adopta una posició filosòfica fonamentalment diferent. En lloc de tornar en silenci a Qualsevol, pyright distingeix entre Desconegut (un tipus que encara no s'ha determinat) i Qualsevol (una desactivació explícita de la comprovació de tipus). Quan escriviu x = [] en el mode estricte de pyright, dedueix la lista[Desconeguda] i informa d'un diagnòstic, obligant-vos a proporcionar una anotació.

Pyright també és més agressiu a l'hora de reduir l'abast. Si escrius:

• x = [] seguit de x.append("hola") — pyright infereix list[str]
• x = [] seguit de x.append(1) i després x.append("hola") — pyright infereix list[int | str
• x = [] s'ha passat directament a una funció que espera list[int] — pyright dedueix list[int] del context del lloc de trucada
• x = [] retornat des d'una funció sense una anotació de tipus de retorn: pyright informa d'un error en lloc d'endevinar

Aquesta inferència bidireccional (que utilitza tant l'ús posterior com els tipus esperats dels llocs de trucades) fa que pyright sigui notablement més precís que mypy per als contenidors buits. La compensació és la verbositat: el mode estricte de pyright marca aproximadament un 30-40% més de problemes en una base de codi típica sense anotacions en comparació amb el mode estricte de mypy, segons l'anàlisi de diversos informes de migració de codi obert. Per als equips que creen sistemes de fons complexos, per exemple, una plataforma que gestiona 207 mòduls interconnectats que abasten CRM, nòmines i anàlisis, l'estricte de pyright detecta subtils desajustos d'interfície que es perdrien inferències indulgents.

Pytype i Pyre: les carreteres menys transitades

El pytype de Google potser adopta l'enfocament més pragmàtic. En lloc de requerir anotacions o de tornar a Qualsevol, pytype utilitza l'anàlisi de tot el programa per fer un seguiment de com s'utilitza un contenidor a través dels límits de la funció. Si creeu una llista buida en una funció i la passeu a una altra que afegeix nombres enters, sovint pytype pot inferir list[int] sense cap mena d'anotació. Aquesta inferència de funcions creuades és costosa computacionalment (pytype és significativament més lenta que mypy o pyright en grans bases de codi), però produeix menys falsos positius en codi no anotat.

Pytype també introdueix el concepte de "tipus parcials" per als contenidors buits. Un [] acabat de crear obté un tipus parcial que es perfecciona progressivament a mesura que el verificador troba més ús. Això és conceptualment elegant, però pot produir missatges d'error confusos quan el tipus parcial no es pot resoldre completament, com ara quan un contenidor buit passa per diverses funcions sense que s'ompli mai.

La pira de Meta, mentrestant, s'acosta més al comportament de mypy, però amb valors predeterminats més ajustats. Pyre tracta x = [] com a llista[desconeguda] i requereix anotacions en la majoria de contextos. On pyre es diferencia és en el seu maneig de literals de diccionari buits utilitzats com a kwargs, un patró comú als marcs web. Pyre té una lògica de casos especials per inferir tipus de diccionari a partir de contextos d'arguments de paraules clau, reduint la càrrega d'anotacions en bases de codi pesades en marcs. Atès que la majoria de les aplicacions web modernes impliquen un ús intensiu del desempaquetat del diccionari per a la configuració i la gestió de sol·licituds, aquest pragmatisme paga dividends.

Impacte al món real: quan la divergència de la inferència pica

Les diferències entre els verificadors de tipus poden semblar acadèmiques fins que les experimenteu en una base de codi de producció. Penseu en un patró comú a les aplicacions empresarials: inicialitzar una estructura de dades que s'omple condicionalment.