Programiści projektu Python propozycja (PEP 594) dotycząca przeprowadzenia istotnego oczyszczenia standardowej biblioteki. Do usunięcia z standardowej biblioteki Python proponowane są zarówno wyraźnie przestarzałe i wyspecjalizowane możliwości, jak i komponenty, w których występują problemy architektoniczne i które nie udaje się ujednolicić na wszystkich platformach.
Na przykład z standardowej biblioteki zaproponowano wykluczenie takich modułów jak crypt (brak dostępności dla Windows i zależność dostępności algorytmów haszujących od bibliotek systemowych), cgi (nieoptymalna architektura, wymaga uruchomienia nowego procesu przy każdym żądaniu), imp (zalecane użycie importlib), pipes (zalecane użycie modułu subprocess), nis (zalecane użycie NSS, LDAP lub Kerberos/GSSAPI), spwd (nie zaleca się bezpośredniej pracy z bazą danych kont). Na liście do usunięcia znalazły się również moduły binhex, uu, xdrlib,
aifc,
audioop,
chunk,
imghdr,
ossaudiodev,
sndhdr,
sunau,
asynchat,
asyncore,
cgitb,
smtpd,
nntplib, macpath,
formatter, msilib i parser.
Zgodnie z proponowanym planem w Pythonie 3.8 wspomniane moduły zostaną oznaczone jako przestarzałe, w Pythonie 3.8 zacznie się wyświetlać ostrzeżenie, a w Pythonie 3.10 zostaną usunięte z repozytoriów CPython.
Moduł parser planuje się usunąć w wersji 3.9, ponieważ został oznaczony jako przestarzały już w wydaniu Python 2.5, a moduł macpath w gałęzi 3.8. Po usunięciu z głównego zbioru kod zostanie przeniesiony do osobnego repozytorium legacylib, a jego przyszłość będzie zależała od zainteresowania przedstawicieli społeczności. Oczekuje się, że gałąź Pythona 3.9 będzie wspierana do 2026 roku, co zapewni wystarczająco dużo czasu na migrację projektów do alternatyw zewnętrznych.
Początkowo do usunięcia zaproponowano również moduły ftplib, optparse, getopt, colorsys, fileinput, lib2to3 i wave, ale postanowiono je na razie pozostawić w standardowej bibliotece, ponieważ są szeroko rozpowszechnione i pozostają aktualne, pomimo istnienia bardziej zaawansowanych alternatyw lub związania z specyficznymi możliwościami systemów operacyjnych.
Przypomnijmy, że początkowo w projekcie Python zastosowano podejście 'baterie w zestawie', w którym w standardowej bibliotece oferowany jest szeroki zestaw funkcji do różnych zastosowań. Do zalet tego podejścia należy uproszczenie utrzymania projektów w Pythonie oraz monitorowania bezpieczeństwa modułów używanych w projektach. Luki w modułach często stają się źródłem luk w aplikacjach, które z nich korzystają. W przypadku, gdy funkcje są zawarte w standardowej bibliotece, wystarczy kontrolować stan głównego projektu. Przy podziale standardowej biblioteki programiści muszą korzystać z zewnętrznych modułów, luki w każdym z nich należy kontrolować osobno. Przy wysokim stopniu podziału i dużej liczbie zależności pojawia się zagrożenie atakami przez kompromitację infrastruktury programistów modułów.
Z drugiej strony, każdy dodatkowy moduł w standardowej bibliotece wymaga zasobów od zespołu programistów Pythona do jego utrzymania. W bibliotece zgromadziła się duża liczba powtarzających się i zbędnych funkcji, które można by wyeliminować, aby obniżyć koszty utrzymania. W miarę rozwoju katalogu i uproszczenia procesu instalacji i ładowania dodatkowych pakietów, korzystanie z zewnętrznych modułów stało się na tyle powszechne jak funkcje wbudowane.
Coraz więcej programistów korzysta z bardziej funkcjonalnych zewnętrznych zamienników dla standardowych modułów, na przykład z modułu lxml zamiast xml. Usunięcie porzuconych modułów ze standardowej biblioteki pozwoli zwiększyć popularność aktywnie rozwijanych przez społeczność alternatyw. Ponadto skrócenie standardowej biblioteki zmniejszy rozmiar podstawowej dostawy, co jest istotne przy używaniu Pythona na wbudowanych platformach z ograniczonym rozmiarem magazynu.
Źródło: opennet.ru
