According to a quick But the goal of his question, Cannon explained, wasn\u2019t to decide which modules to get rid<\/em> of. Instead, it was to create guidelines on when and why new<\/em> modules should be accepted into the standard library.<\/p>\n “We need to audit the standard library, and not deprecate<\/em> it, but decide which bits should probably not have been added if we had perfect hindsight. <\/p>\n<\/blockquote>\n — Guido van Rossum, CPython Core Developer and former BDFL<\/i><\/p>\n<\/blockquote>\n Carol Willing agreed that the core dev team shouldn\u2019t be looking to remove modules en masse<\/em>, but should decide what kinds of modules they wanted to admit in the future. \u0141ukasz Langa agreed, and pointed out that it was often hard removing modules even when we wanted to, due to the fact that \u201cthe standard library is a huge import cycle\u201d.<\/p>\n Cannon himself put forward two possible answers to his question, before tossing it out to the audience:<\/p>\n The conversation was free-flowing, but a common point of consensus among the attendees was that the standard library should focus on tools and utilities that allow users to write better Python code. Hynek Schlawack cited \u201cThe default answer for \u2018Should this be in the standard library?\u2019 should be \u2018No\u2019, but we should bless smaller utilities that help people write better Python code\u201d <\/p>\n<\/blockquote>\n — Antonio Cuni, HPy Core Developer<\/i><\/p>\n<\/blockquote>\n There was a certain amount of regret in the air about modules that perhaps should never have been added to the standard library, and had proved themselves to be significant maintenance burdens in the years since, but could now never be removed. Guido van Rossum pondered whether \u0141ukasz Langa noted that modules such as Zac Hatfield-Dods, maintainer of several prominent third-party packages, said that different standard-library packages had different impacts on the Python ecosystem. Pytest<\/a>, one of the libraries he maintains, had managed to flourish and find success despite the existence of <\/p>\npython -c \"import sys; print(len(sys.stdlib_module_names))\"<\/code> call on my laptop, the standard library in Python 3.11 consists of 305 importable modules. Many of these are implementation details that, if you\u2019re a good citizen, you really shouldn\u2019t<\/em> be importing \u2013 but the point stands that the Python standard library is perhaps now larger than it should be.<\/p>\n\n
\n
Where do we go now?<\/h2>\n
\n
dataclasses<\/code><\/a> as an example of a module that made writing classes much less painful, and generally led to them writing better code as a result. (Schlawack is the author of the attrs<\/a> library, the third-party inspiration for dataclasses<\/code>, which itself is still going strong.) Filipe La\u00edns agreed, arguing that the core dev team should focus on building business implementations for third-party libraries to build on top of.<\/p>\n\n
\n
tkinter<\/code><\/a>, it was universally agreed, was the primary example here; possibly multiprocessing<\/code><\/a> also.<\/p>\nasyncio<\/code><\/a> should ever have been added to the standard library, remarking that it had been difficult to evolve asyncio<\/code> while it was in the standard library, and had possibly been added before it was \u201cfully baked\u201d. The ssl<\/code> integration had probably been a mistake, he said, and should have been left to third parties.<\/p>\nasyncio<\/code> and typing<\/code><\/a>, which had continued to evolve rapidly after being added to the standard library, had helped spur new syntax changes to Python that had been to the language\u2019s betterment. Without asyncio<\/code> in the standard library, Langa argued, we would probably never have adopted the async<\/code>\/await<\/code> syntax that is now the foundation of asynchronous Python programming.<\/p>\nunittest<\/code><\/a> in the standard library. But another library he helps out with, the asynchronous Trio<\/a> framework, had struggled to attract users while asyncio<\/code> had been part of the standard library. \u201cNobody supports alternative async implementations,\u201d he complained, despite Trio\u2019s development often being years ahead of where asyncio<\/code> is. (In the coffee break afterwards, Hatfield-Dods was keen to emphasise that he is, in fact, a fan of asyncio<\/code> and the work of the asyncio<\/code> maintainers.)<\/p>\n
![](\"https:\/\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEhNHMtg7BSQza8aOAebA4arhofrKFaaX0MulKsXjgTFBc--7H5bWHuumjdw-DMOHN_eGH1cBA4sZzumqMPp0caSMVZv2aySrlwd7R9jMgjwwsMEpluO89sKCEsbAiHli5fg_i65HkN2OJoXnCqlKQiCA9HBlICEB_NUcFOsN3WcCPKOAbU\/s320\/image_2023-05-27_223251699.png\")
<\/a><\/td>\n<\/tr>\n![\\\"IT\u96fb\u8166\u88dc\u7fd2](\\\"http:\/\/itteacheritfreelance.hk\/test\/wordpress\/wp-content\/uploads\/2016\/05\/logo2-2.png\\\"){kind=logo}