Sviluppatori del progetto Python proposta (PEP 594) per una significativa pulizia della libreria standard. Si propongono di essere rimossi dalla libreria standard di Python sia caratteristiche evidentemente obsolete e di nicchia, sia componenti che presentano problemi architettonici e che non possono essere unificati per tutte le piattaforme.
Ad esempio, si propone di escludere dalla libreria standard moduli come crypt (inaccessibilità per Windows e dipendenza dalla 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 raccomanda di usare importlib), pipes (si raccomanda di usare il modulo subprocess), nis (si raccomanda di usare NSS, LDAP o Kerberos/GSSAPI), spwd (non si raccomanda di lavorare direttamente con il database degli account). Sono stati anche classificati per la rimozione i moduli binhex, uu, xdrlib,
aifc,
audioop,
chunk,
imghdr,
ossaudiodev,
sndhdr,
sunau,
asynchat,
asyncore,
cgitb,
smtpd,
nntplib, macpath,
formatter, msilib e parser.
Secondo il piano proposto, in Python 3.8 i moduli sopracitati sono previsti per essere contrassegnati come obsoleti, in Python 3.8 inizieremo a mostrare un avviso e in Python 3.10 saranno rimossi dai repository CPython.
Il modulo parser è previsto per essere rimosso nella versione 3.9, poiché è stato contrassegnato come obsoleto già nella versione Python 2.5, e il modulo macpath nella release 3.8. Dopo la rimozione dalla libreria principale, il codice sarà trasferito in un repository separato legacylib e il suo futuro dipenderà dall'interesse della comunità. Si prevede che la branch Python 3.9 sarà supportata fino al 2026, fornendo così tempo sufficiente per migrare i progetti su alternative esterne.
Inizialmente, erano stati proposti per la rimozione anche i moduli ftplib, optparse, getopt, colorsys, fileinput, lib2to3 e wave, ma è stato deciso di lasciarli nel pacchetto della libreria standard, poiché sono ampiamente utilizzati e rimangono rilevanti, nonostante l'esistenza di alternative più avanzate o legate a funzionalità specifiche dei sistemi operativi.
Ricordiamo che inizialmente il progetto Python adotta un approccio "le batterie sono incluse", in cui la libreria standard offre un ampio set di funzioni per vari settori. Tra i vantaggi di questo approccio ci sono la semplificazione della manutenzione dei progetti in Python e il monitoraggio della sicurezza dei moduli utilizzati nei progetti. Le vulnerabilità nei moduli diventano spesso la fonte di vulnerabilità nelle applicazioni che li utilizzano. Se le funzioni sono incluse nella libreria standard, è sufficiente controllare lo stato del progetto principale. Con la suddivisione della libreria standard, gli sviluppatori devono utilizzare moduli di terze parti, le vulnerabilità di ciascuno dei quali devono essere monitorate separatamente. Con un alto grado di frazionamento e un numero elevato di dipendenze, si presenta il rischio di attacchi attraverso il compromesso dell'infrastruttura degli sviluppatori di moduli.
D'altra parte, ogni modulo aggiuntivo nella libreria standard richiede risorse da parte del team di sviluppo di Python per il supporto. Si è accumulato un gran numero di funzioni duplicate e superflue nella libreria, l'eliminazione delle quali può ridurre i costi di manutenzione. Con lo sviluppo del catalogo e semplificando il processo di installazione e download di pacchetti aggiuntivi, l'uso di moduli esterni è diventato tanto abituale quanto quello delle funzioni incorporate.
Sempre più sviluppatori utilizzano sostituti esterni più funzionali ai moduli standard, ad esempio utilizzano il modulo lxml invece di xml. L'eliminazione dei moduli obsoleti dalla libreria standard aumenterà la popolarità delle alternative attivamente sviluppate dalla comunità. Inoltre, ridurre la libreria standard porterà a una diminuzione della dimensione della fornitura di base, il che è rilevante quando si utilizza Python su piattaforme embedded con spazio di archiviazione limitato.
Fonte: opennet.ru
