Twórcy projektów w Pythonie propozycję (PEP 594), aby dokonać gruntownego uporządkowania biblioteki standardowej. Zarówno wyraźnie przestarzałe, jak i wysoce wyspecjalizowane możliwości i komponenty, które mają problemy architektoniczne i nie mogą być ujednolicone dla wszystkich platform, są oferowane do usunięcia ze standardowej biblioteki Pythona.
Przykładowo proponuje się wykluczyć ze standardowej biblioteki takie moduły jak crypt (niedostępność dla Windows i zależność dostępności algorytmów hashujących od bibliotek systemowych), cgi (architektura nieoptymalna, wymaga uruchomienia nowego procesu dla każdego żądania), imp (zaleca się użycie importlib), potoki (zaleca się użycie modułu subprocess), nis (zaleca się użycie NSS, LDAP lub Kerberos/GSSAPI), spwd (nie zaleca się bezpośredniej pracy z bazą danych kont). Moduły binhex, uu, xdrlib są również oznaczone do usunięcia.
aifc,
audioop,
kawałek
imghdr,
ossaudiodev,
sndhdr,
sunau
asynchroniczny,
asyncore,
cgitb,
smtpd
nntplib, ścieżka Mac,
formater, msilib i parser.
Proponowany plan zakłada wycofanie powyższych modułów w Pythonie 3.8, wystawienie ostrzeżenia w Pythonie 3.8 i usunięcie ich z repozytoriów CPython w Pythonie 3.10.
Planuje się, że moduł parsera zostanie usunięty w wersji 3.9, ponieważ był przestarzały w wersji Python 2.5, oraz moduł macpath w gałęzi 3.8. Po usunięciu z głównego kodu, kod zostanie przeniesiony do osobnego repozytorium Legacylib, a jego los będzie zależał od zainteresowania członków społeczności. Oczekuje się, że gałąź Python 3.9 będzie obsługiwana do 2026 r., co zapewni wystarczająco dużo czasu na migrację projektów do zewnętrznych alternatyw.
Początkowo zaproponowano również usunięcie modułów ftplib, optparse, getopt, colorys, fileinput, lib2to3 i wave, ale na razie zdecydowano się pozostawić je jako część biblioteki standardowej, ponieważ są one szeroko rozpowszechnione i pozostają istotne pomimo obecności bardziej zaawansowanych alternatyw lub powiązań z konkretnymi możliwościami systemów operacyjnych.
Przypomnijmy, że projekt Python początkowo przyjął podejście „baterie w zestawie”, oferując bogaty zestaw funkcji w standardowej bibliotece do różnych zastosowań. Do zalet takiego podejścia należy uproszczenie utrzymania projektów w języku Python i monitorowanie bezpieczeństwa modułów wykorzystywanych w projektach. Luki w modułach często stają się źródłem luk w aplikacjach, które z nich korzystają. Jeśli funkcje znajdują się w bibliotece standardowej, wystarczy monitorować stan głównego projektu. Dzieląc bibliotekę standardową, programiści są zobowiązani do korzystania z modułów innych firm, a luki w każdym z nich należy monitorować osobno. Przy wysokim stopniu fragmentacji i dużej liczbie zależności istnieje zagrożenie atakami poprzez naruszenie infrastruktury twórców modułów.
Z drugiej strony każdy dodatkowy moduł w bibliotece standardowej wymaga zasobów zespołu programistów Pythona do utrzymania. W bibliotece zgromadzono dużą liczbę powielających i redundantnych funkcji, których wyeliminowanie może obniżyć koszty utrzymania. W miarę rozwoju katalogu oraz upraszczając proces instalacji i pobierania dodatkowych pakietów, korzystanie z modułów zewnętrznych stało się obecnie tak powszechne, jak funkcje wbudowane.
Coraz więcej programistów korzysta z bardziej funkcjonalnych zewnętrznych zamienników standardowych modułów, na przykład używając modułu lxml zamiast xml. Usunięcie porzuconych modułów ze standardowej biblioteki zwiększy popularność alternatyw aktywnie rozwijanych przez społeczność. Ponadto zmniejszenie standardowej biblioteki doprowadzi do zmniejszenia rozmiaru podstawowej dystrybucji, co jest ważne w przypadku używania Pythona na platformach wbudowanych o ograniczonej wielkości pamięci.
Źródło: opennet.ru