Sviluppatori di progetti Python proposta (PEP 594) per effettuare una profonda pulizia della libreria standard. Sia le funzionalità chiaramente obsolete che quelle altamente specializzate e i componenti che presentano problemi di architettura e non possono essere unificati per tutte le piattaforme vengono offerti per la rimozione dalla libreria standard Python.
Ad esempio, si propone di escludere dalla libreria standard moduli come crypt (indisponibilità per Windows e dipendenza della disponibilità degli algoritmi di hashing dalle librerie di sistema), cgi (architettura non ottimale, richiede l'avvio di un nuovo processo per ogni richiesta), imp (si consiglia di utilizzare importlib), pipe (si consiglia di utilizzare il modulo subprocess), nis (si consiglia di utilizzare NSS, LDAP o Kerberos/GSSAPI), spwd (non è consigliabile lavorare direttamente con il database degli account). Anche i moduli binhex, uu, xdrlib sono contrassegnati per la rimozione.
AIFC,
audio,
pezzo
imghdr,
ossaaudiodev,
sndhdr,
sunau
asinchattare,
asincrono,
cgitb,
smtpd
nntplib, percorso mac,
formattatore, msilib e parser.
Il piano proposto è di deprecare i moduli di cui sopra in Python 3.8, emettere un avviso in Python 3.8 e rimuoverli dai repository CPython in Python 3.10.
È prevista la rimozione del modulo parser nella versione 3.9, poiché era deprecato nella versione Python 2.5, e del modulo macpath nel ramo 3.8. Dopo essere stato rimosso dal codice principale, il codice verrà spostato in un repository legacylib separato e il suo destino dipenderà dall'interesse dei membri della comunità. Si prevede che il ramo Python 3.9 sarà supportato fino al 2026, il che fornirà ampio tempo ai progetti per migrare verso alternative esterne.
Inizialmente, era stata proposta la rimozione anche dei moduli ftplib, optparse, getopt, colorsys, fileinput, lib2to3 e wave, ma si è deciso di lasciarli per ora come parte della libreria standard, poiché sono diffusi e rimangono rilevanti, nonostante la presenza di alternative più avanzate o vincoli a funzionalità specifiche dei sistemi operativi.
Ricordiamo che il progetto Python inizialmente ha adottato un approccio “batterie incluse”, offrendo un ricco set di funzioni nella libreria standard per una varietà di applicazioni. Tra i vantaggi di questo approccio c'è la semplificazione della manutenzione dei progetti Python e del monitoraggio della sicurezza dei moduli utilizzati nei progetti. Le vulnerabilità nei moduli spesso diventano una fonte di vulnerabilità nelle applicazioni che li utilizzano. Se le funzioni sono incluse nella libreria standard è sufficiente monitorare lo stato del progetto principale. Quando si suddivide la libreria standard, gli sviluppatori sono tenuti a utilizzare moduli di terze parti, le cui vulnerabilità in ciascuno dei quali devono essere monitorate separatamente. Con un elevato grado di frammentazione e un gran numero di dipendenze esiste il pericolo di attacchi che compromettono l'infrastruttura degli sviluppatori di moduli.
D'altra parte, ogni modulo aggiuntivo nella libreria standard richiede risorse da parte del team di sviluppo Python per la manutenzione. La libreria ha accumulato un gran numero di funzioni duplicate e ridondanti, la cui eliminazione può ridurre i costi di manutenzione. Man mano che il catalogo si sviluppa e semplificando il processo di installazione e download di pacchetti aggiuntivi, l'uso di moduli esterni è ormai diventato comune quanto le funzioni integrate.
Sempre più sviluppatori utilizzano sostituzioni esterne più funzionali per i moduli standard, ad esempio utilizzando il modulo lxml invece di xml. La rimozione dei moduli abbandonati dalla libreria standard aumenterà la popolarità delle alternative sviluppate attivamente dalla comunità. Inoltre, la riduzione della libreria standard porterà a una riduzione delle dimensioni della distribuzione di base, il che è importante quando si utilizza Python su piattaforme embedded con dimensioni di archiviazione limitate.
Fonte: opennet.ru