PEP 594 – 표준 라이브러리에서 사용되지 않는 배터리 제거

Author:: Christian Heimes <christian at python.org>, Brett Cannon <brett at python.org>
Discussions-To:: Discourse thread
Status:: Final
Type:: Standards Track
Created:: 20-May-2019
Python-Version:: 3.11
Post-History:: 21-May-2019, 04-Feb-2022
Resolution:: Discourse message

Table of Contents

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain or CC0-1.0, whichever is more permissive 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

초록

이 PEP는 표준 라이브러리에서 제거할 표준 라이브러리 모듈 목록을 제안했습니다. 모듈은 대부분 역사적인 데이터 형식(예: Commodore 및 SUN 파일 형식), 오래전에 대체된 API와 운영 체제(예: Mac OS 9), 또는 보안 문제가 있고 더 나은 대안이 존재하는 모듈(예: password 및 login)입니다.

이 PEP는 PEP 3108과 같은 다른 PEP들의 전철을 따릅니다. 표준 라이브러리 재구성 제안은 Python 3.0에서 여러 모듈을 제거했습니다. 2007년에 이 PEP는 유지 관리 부담을 다음과 같이 언급했습니다:

“수년에 걸쳐 일부 모듈은 python-dev가 유지 관리하기에 큰 부담이 되었습니다. 이와 같은 상황에서는 python-dev가 언어 지원과 표준 라이브러리의 다른 모듈에 집중할 수 있도록 해당 모듈의 유지 관리를 커뮤니티에 맡겨, 과도한 시간과 노력이 들지 않도록 하는 편이 낫습니다.”

2000년에 철회된 PEP 206은 Python 표준 라이브러리의 문제를 가감 없고 솔직한 방식으로 표현합니다:

“[…] 표준 라이브러리 모듈이 어떤 작업에나 항상 최선의 선택인 것은 아닙니다. 일부 라이브러리 모듈은 임시방편으로 빠르게 만들어졌고(예: calendar, commands), 일부는 설계가 좋지 않아 이제는 수정하기가 거의 불가능하며(cgi), 일부는 더 완전한 다른 모듈 때문에 더 이상 사용되지 않게 되었습니다 […].”

근거

Python 초기에는 인터프리터에 유용한 모듈이 대규모로 포함되어 있었습니다. 이를 흔히 “배터리 포함” 철학이라고 불렀으며, Python 성공 신화의 초석 중 하나였습니다. 사용자는 간단한 웹 서버를 작성하거나 이메일을 구문 분석하기 위해 별도의 패키지를 다운로드하고 설치하는 방법을 알아낼 필요가 없었습니다.

시대가 변했습니다. PyPI(이전 명칭 Cheeseshop), setuptools, 그리고 이후 pip가 도입되면서 패키지를 다운로드하고 설치하는 일이 간단하고 수월해졌습니다. 오늘날 Python에는 풍부하고 활발한 서드파티 패키지 생태계가 있습니다. PyPI에서 패키지를 설치하거나 수많은 Python 또는 Linux 배포판 중 하나를 사용하는 것이 사실상 표준입니다.

반면 Python의 표준 라이브러리에는 불필요한 잔재와 기능의 불필요한 중복, 그리고 없어도 되는 기능이 계속 쌓이고 있습니다. 이는 여러 가지 이유로 바람직하지 않습니다.

모듈이 하나 추가될 때마다 Python 핵심 개발 팀의 유지 관리 비용이 증가합니다. 팀의 자원은 제한되어 있으므로 유지 관리 비용이 줄어들면 다른 개선 작업에 개발 시간을 할애할 수 있습니다.
표준 라이브러리의 모듈은 일반적으로 선호되며 문제에 대한 사실상의 해결책으로 여겨집니다. 대다수 사용자는 설득력 있는 이유가 있을 때에만 표준 라이브러리 모듈을 대체할 서드파티 모듈을 선택합니다. 예를 들어 xml 대신 lxml을 선택하는 경우입니다. 유지 관리되지 않는 표준 라이브러리 모듈을 제거하면 커뮤니티가 기여한 모듈이 널리 사용될 가능성이 높아집니다.
간결하고 효율적인 표준 라이브러리는 저장 공간이 수백 킬로바이트에 불과한 장치(예: BBC Micro:bit)와 같이 자원이 제한된 플랫폼에 도움이 됩니다. BeeWare나 WebAssembly(예: pyodide)와 같은 모바일 플랫폼의 Python도 다운로드 크기가 줄어들면 이점을 얻습니다.

이 PEP의 모듈들은 제거가 논란의 여지가 가장 적거나 가장 큰 이점을 제공하기 때문에 사용 중단 대상으로 선정되었습니다. 예를 들어 가장 논란의 여지가 적은 것은 sunau 오디오 형식과 같은 30년 된 멀티미디어 형식으로, 1980년대 후반에 SPARC 및 NeXT 워크스테이션에서 사용되었습니다. crypt 모듈에는 표준 라이브러리 외부에서 해결하는 편이 나은 근본적인 결함이 있습니다.

이 PEP는 일부 모듈을 제거 예정이 아닌 것으로도 지정합니다. 일부 모듈은 여러 릴리스 동안 사용 중단되었거나 처음 보기에는 불필요해 보입니다. 그러나 특히 PyPI에서 패키지를 설치할 수 없는 환경에서는 모듈을 표준 라이브러리에 유지하는 것이 유익합니다. 이러한 환경에는 외부 코드를 법적 승인 없이 허용하지 않는 기업 환경이나 교실이 포함될 수 있습니다.

FTP의 사용은 감소하고 있지만 일부 파일은 여전히 FTP 프로토콜을 통해 제공되거나 호스팅 업체가 콘텐츠 업로드를 위한 FTP를 제공합니다. 따라서 ftplib은 계속 유지됩니다.
optparse와 getopt모듈은 널리 사용됩니다. 이 모듈들은 유지 관리 부담이 매우 낮은 성숙한 모듈입니다.
David Beazley [5]에 따르면 wave모듈은 아이들에게 가르치기 쉽고 엉뚱한 소리를 만들 수 있습니다. 컴퓨터가 소리를 생성하도록 만드는 것은 개발자를 꿈꾸는 아홉 살 어린이에게 강력하고 동기를 크게 부여하는 연습입니다. 계속 유지할 만한 재미있는 배터리입니다.

사용 중단 일정

3.11

Python 3.11부터 사용 중단된 모듈은 DeprecationWarning을 발행하기 시작합니다. 경고가 없는 마지막 버전인 Python 3.10의 예상 EOL은 2026년 10월입니다.

3.12

Python 3.11과 비교하여 특별한 변경 사항은 없어야 합니다. 이 버전은 사용 중단된 모듈이 포함된 마지막 Python 버전이며, 예상 EOL은 2028년 10월입니다.

3.13

이 PEP에서 사용 중단된 모든 모듈은 CPython 저장소의 main 브랜치에서 제거되며 더 이상 Python의 일부로 배포되지 않습니다.

사용 중단된 모듈

모듈은 데이터 인코딩, 멀티미디어, 네트워크, OS 인터페이스 및 기타 모듈로 분류됩니다. 대부분의 모듈은 오래된 데이터 형식이나 오래된 API를 위한 것입니다. 다른 일부는 거의 쓸모가 없으며 PyPI에 더 나은 대체재가 있습니다. 예를 들어 이미지 처리를 위한 Pillow나 오디오 처리를 다루는 NumPy 기반 프로젝트가 있습니다.

표 1: 제안된 모듈 폐기
모듈	폐기 시점	제거 예정	추가 시점	관리자 있음?	대체재
aifc	3.11 (3.0*)	3.13	1993	yes (inactive)	-
asynchat	3.6 (3.0*)	3.12	1999	yes	`asyncio`
asyncore	3.6 (3.0*)	3.12	1999	yes	`asyncio`
audioop	3.11 (3.0*)	3.13	1992	yes	-
cgi	3.11 (2.0**)	3.13	1995	no	-
cgitb	3.11 (2.0**)	3.13	1995	no	-
chunk	3.11	3.13	1999	no	-
crypt	3.11	3.13	1994	yes (inactive)	legacycrypt, bcrypt, argon2-cffi, `hashlib`, passlib
imghdr	3.11	3.13	1992	no	filetype, puremagic, python-magic
mailcap	3.11	3.13	1995	no	-
msilib	3.11	3.13	2006	no	-
nntplib	3.11	3.13	1992	no	-
nis	3.11 (3.0*)	3.13	1992	no	-
ossaudiodev	3.11	3.13	2002	no	-
pipes	3.11	3.13	1992	no	`subprocess`
smtpd	3.4.7, 3.5.4	3.12	2001	yes	aiosmtpd
sndhdr	3.11	3.13	1994	no	filetype, puremagic, python-magic
spwd	3.11	3.13	2005	no	python-pam
sunau	3.11 (3.0*)	3.13	1993	no	-
telnetlib	3.11 (3.0*)	3.13	1997	no	telnetlib3, Exscript
uu	3.11	3.13	1994	no	-
xdrlib	3.11	3.13	1992/1996	no	-

3.0에 대한 PEP 3108과 2.0에 대한 PEP 206에서 제안된 일부 모듈 폐기입니다. added in 열은 모듈이 원래 설계되어 표준 라이브러리에 추가된 시기를 보여 줍니다. has maintainer 열은 DevGuide의 도메인 전문가 및 유지 관리자 목록인 expert index를 가리킵니다.

데이터 인코딩 모듈

uu 및 uu 인코딩

Python의 uu 모듈은 1980년에 이메일용으로 사용되던 오래된 바이너리 인코딩 형식인 uuencode 형식을 제공합니다. uu 형식은 MIME으로 대체되었습니다. uu 코덱은 binascii 모듈에서 제공합니다. 동일한 인코딩을 위한 코덱인 encodings/uu_codec.py도 있으며, 이 역시 더 이상 사용되지 않도록 해야 합니다.

xdrlib

Python의 xdrlib 모듈은 Sun External Data Representation Standard를 지원합니다. XDR은 1987년에 만들어진 오래된 바이너리 직렬화 형식입니다. 오늘날에는 NFS와 같은 전문 분야 외에서는 거의 사용되지 않습니다.

멀티미디어 모듈

aifc

Python의 aifc 모듈은 AIFF 및 AIFF-C 파일을 읽고 쓰는 기능을 제공합니다. Audio Interchange File Format은 Amiga IFF를 기반으로 1988년에 만들어진 오래된 오디오 형식입니다. Apple Macintosh에서 가장 흔히 사용되었습니다. 오늘날에는 소수의 전문 애플리케이션만 AIFF를 사용합니다.

한 사용자가 [6]에서 영화 후반 작업 업계가 AIFC 파일 형식을 많이 사용한다고 밝혔습니다. 이 PEP가 처음 게시되기 전에는 폐쇄 소스 및 내부 소프트웨어에서 aifc 모듈이 사용되는 사실이 알려지지 않았습니다. 이는 aifc 모듈을 표준 라이브러리에 유지해야 한다는 강력한 근거가 될 수 있습니다. 파일 형식은 안정적이며 모듈 유지 관리에 많은 노력이 필요하지 않습니다. Python에 대한 전략적 이점이 그 부담을 능가할 수 있습니다.

audioop

Python의 audioop 모듈에는 원시 오디오 데이터와 적응형 차동 펄스 부호 변조 오디오 데이터를 조작하는 도우미 함수가 포함되어 있습니다. 이 모듈은 추가 종속성 없이 C로 구현되어 있습니다. aifc, sunau, 및 wave 모듈은 일부 연산을 위해 audioop에 의존합니다.

wave 모듈의 바이트 스왑 연산은 약간의 추가 작업으로 대체할 수 있습니다. aifc도 더 이상 사용되지 않도록 하지 않는 경우, audioop 모듈의 축소 버전을 비공개 구현 세부 사항으로 변환할 수 있습니다. 예를 들어 byteswap, alaw2lin, ulaw2lin, lin2alaw, lin2ulaw, 및 lin2adpcm을 포함하는 _audioop로 만들 수 있습니다.

chunk

Python의 chunk 모듈은 Electronic Arts의 Interchange File Format을 읽고 쓰는 기능을 제공합니다. IFF는 원래 Commodore 및 Amiga용으로 도입된 오래된 오디오 파일 형식입니다. 이 형식은 더 이상 관련성이 없습니다.

imghdr

Python의 imghdr 모듈은 파일 또는 버퍼의 처음 32바이트에서 이미지 파일 형식을 추측하는 간단한 도구입니다. 제한된 수의 형식만 지원하며 해상도와 색 심도 어느 것도 반환하지 않습니다.

ossaudiodev

Python의 ossaudiodev 모듈은 사운드 재생 및 캡처 장치 인터페이스인 Open Sound System을 지원합니다. OSS는 처음에는 자유 소프트웨어였지만, 이후 새로운 사운드 장치에 대한 지원과 개선 사항은 독점 소프트웨어가 되었습니다. Linux 커뮤니티는 OSS를 버리고 ALSA [1]를 채택했습니다. OpenBSD와 NetBSD 같은 일부 운영 체제는 OSS의 불완전한 [2] 에뮬레이션을 제공합니다.

제가 아는 한, 현재 Open Sound System을 사용하는 널리 배포된 운영 체제는 FreeBSD가 유일합니다. ossaudiodev에는 2003년 이후 어떠한 개선이나 새로운 기능도 추가되지 않았습니다. 2003년 이후의 모든 커밋은 프로젝트 전반의 코드 정리와 몇 가지 버그 수정입니다. 이 모듈을 아끼고 사용하는 사람들이 유지 관리하고 배포한다면 FreeBSD 커뮤니티와 핵심 개발 모두에 도움이 될 것입니다.

표준 라이브러리에는 과거에 오디오 관련 모듈이 더 많이 포함되어 있었습니다. 다른 오디오 장치 인터페이스(audiodev, linuxaudiodev, sunaudiodev)는 PEP 3108 표준 라이브러리 재구성의 일환으로 2007년에 제거되었습니다.

sndhdr

Python의 sndhdr 모듈은 오디오 형식에 대해 imghdr 모듈과 유사합니다. 파일 또는 버퍼의 처음 512바이트에서 파일 형식, 채널, 프레임 속도 및 샘플 너비를 추측합니다. 이 모듈은 AU, AIFF, HCOM, VOC, WAV 및 기타 고대 형식만 지원합니다.

sunau

Python의 sunau 모듈은 Sun AU 사운드 형식을 지원합니다. 이는 또 하나의 오래되고 폐기된 파일 형식입니다.

네트워킹 모듈

asynchat

Python의 asynchat 모듈은 asyncore 모듈을 기반으로 구축되었으며 Python 3.6부터 사용 중단되었습니다.

asyncore

Python의 asyncore 모듈은 비동기 소켓 서비스 클라이언트와 서버를 위한 최초의 모듈이었습니다. 이 모듈은 asyncio로 대체되었으며 Python 3.6부터 사용 중단되었습니다.

asyncore 모듈은 표준 라이브러리 테스트에서도 사용됩니다. ftplib, logging, smptd, smtplib 및 ssl에 대한 테스트는 일부가 asyncore를 기반으로 합니다. 이러한 테스트는 asyncio 또는 threading을 사용하도록 업데이트해야 합니다.

cgi

Python의 cgi 모듈은 Common Gateway Interface (CGI) 스크립트를 지원하는 모듈입니다. CGI는 모든 수신 요청이 새 프로세스에서 처리되므로 비효율적인 것으로 간주됩니다. PEP 206에서는 이 모듈을 다음과 같이 평가합니다:

“[…] 형편없이 설계되었으며 이제는 수정하기가 거의 불가능합니다(cgi) […]”

코드 실행과 직접 관련되지 않은 cgi의 다양한 부분에 대한 대체 항목은 다음과 같습니다:

parse를 urllib.parse.parse_qs와 함께 사용합니다 (parse는 단지 래퍼일 뿐입니다).
parse_header를 email.message.Message와 함께 사용합니다 (아래 예시를 참조하십시오).
parse_multipart를 email.message.Message와 함께 사용합니다 (동일한 MIME RFC입니다).
FieldStorage/MiniFieldStorage에는 직접적인 대체 항목이 없지만, 일반적으로 multipart를 사용하여 (POST 및 PUT 요청의 경우) 또는 urllib.parse.parse_qsl을 사용하여 (GET 및 HEAD 요청의 경우) 대체할 수 있습니다.
valid_boundary (문서화되지 않음)를 re.compile("^[ -~]{0,200}[!-~]$")로 대체합니다.

parse_header와 email.message.Message가 얼마나 유사한지 보여 주는 명시적인 예는 다음과 같습니다:

>>> from cgi import parse_header
>>> from email.message import Message
>>> parse_header(h)
('application/json', {'charset': 'utf8'})
>>> m = Message()
>>> m['content-type'] = h
>>> m.get_params()
[('application/json', ''), ('charset', 'utf8')]
>>> m.get_param('charset')
'utf8'

cgitb

Python의 cgitb 모듈은 구성 가능한 트레이스백을 위한 cgi 모듈의 도우미입니다.

cgitb 모듈은 주요 Python 웹 프레임워크(Django, Pyramid, Plone, Flask, CherryPy 또는 Bottle)에서 사용되지 않습니다. 선택적 디버깅 미들웨어에서 Paste만 이를 사용합니다.

smtpd

Python의 smtpd 모듈은 간단한 SMTP 메일 서버 구현을 제공합니다. 모듈 문서에서는 해당 모듈을 사용 중단된 것으로 표시하고 aiosmtpd를 대신 사용하도록 권장합니다. 사용 중단 메시지는 3.4.7, 3.5.4 및 3.6.1 릴리스에 추가되었습니다.

nntplib

관련 nntplib 모듈은 네트워크 뉴스 전송 프로토콜(nntp)의 클라이언트 측을 구현합니다. 뉴스 그룹은 한때 온라인 토론을 위한 지배적인 플랫폼이었습니다. 지난 20년 동안 뉴스는 메일링 리스트와 웹 기반 토론 플랫폼으로 느리지만 꾸준히 대체되었습니다. Twisted도 planning을 통해 NNTP 지원을 사용 중단할 계획이며, pynntp는 2014년 이후 아무런 활동도 하지 않았습니다. 이는 NNTP 지원에 대한 대중의 관심이 감소하고 있음을 보여 주는 좋은 지표입니다.

nntplib 테스트는 최근 추가 작업의 원인이 되어 왔습니다. Python에는 NNTP의 클라이언트 측만 포함되어 있으므로 테스트는 외부 뉴스 서버에 연결합니다. 서버는 때때로 사용할 수 없거나, 너무 느리거나, IPv6에서 올바르게 작동하지 않습니다. 이 상황으로 인해 빌드봇에서 불안정한 테스트 실행이 발생합니다.

telnetlib

Python의 telnetlib 모듈은 Telnet 프로토콜을 구현하는 Telnet 클래스를 제공합니다.

운영 체제 인터페이스

crypt

Python의 crypt 모듈은 Unix 계열 플랫폼에서 libcrypt 또는 libxcrypt의 crypt(3) 함수를 기반으로 비밀번호 해싱을 구현합니다. 알고리즘은 대부분 오래되었고, 품질이 낮으며 안전하지 않습니다. 사용자는 해당 알고리즘을 사용하지 않도록 권고됩니다.

이 모듈은 Windows에서 사용할 수 없습니다. 크로스 플랫폼 애플리케이션에는 어차피 대체 구현이 필요합니다.
DES 암호화만 사용 가능하다고 보장됩니다. DES의 키 공간은 2**56으로 극도로 제한적입니다.
MD5, 솔트가 적용된 SHA256, 솔트가 적용된 SHA512 및 Blowfish는 선택적 확장 기능입니다. SSHA256 및 SSHA512는 glibc 확장 기능입니다. Blowfish (bcrypt)는 여전히 안전한 유일한 알고리즘입니다. 그러나 이는 glibc에 포함되어 있으므로 Linux에서 일반적으로 사용할 수 없습니다.
플랫폼에 따라 crypt 모듈은 스레드 안전하지 않습니다. crypt_r(3)를 사용하는 구현만 스레드 안전합니다.
이 모듈은 시스템 사용자 및 암호 데이터베이스와 상호 작용하는 데 유용했던 적이 없습니다. BSD, macOS 및 Linux에서는 모든 사용자 인증 및 암호 변경 작업이 PAM(플러그형 인증 모듈)을 거쳐야 합니다. spwd의 지원 중단을 참조하십시오.

nis

Python의 nis 모듈은 NIS/YP 지원을 제공합니다. 네트워크 정보 서비스 / 옐로 페이지는 Sun Microsystems에서 개발한 오래되고 지원 중단된 디렉터리 서비스 프로토콜입니다. 1992년에 설계된 후속 제품인 NIS+는 결코 성공하지 못했습니다. 오랫동안 libc의 Name Service Switch, LDAP 및 Kerberos/GSSAPI는 NIS보다 강력하고 안전한 대체 수단으로 여겨져 왔습니다.

spwd

Python의 spwd 모듈은 비표준 API를 사용하여 Unix shadow 비밀번호 데이터베이스에 직접 액세스할 수 있도록 합니다.

일반적으로 spwd를 사용하는 것은 좋지 않습니다. 이는 시스템 보안 정책을 우회하고 PAM 스택을 사용하지 않으며, NSS를 무시하므로 로컬 사용자 계정과만 호환됩니다. spwd 모듈을 액세스 제어에 사용하는 것은 PAM의 액세스 제어를 우회하므로 보안 버그로 간주해야 합니다.

또한 spwd 모듈은 shadow(3) API를 사용합니다. getspnam(3)과 같은 함수는 /etc/shadow 파일에 직접 액세스합니다. 이는 위험하며 SELinux 또는 AppArmor와 같은 보안 엔진이 있는 시스템에서 제한된 서비스에는 금지되기까지 합니다.

기타 모듈

mailcap

Python의 mailcap 패키지는 이메일의 파일 첨부를 처리하는 데 도움을 주는 mail capability 파일을 읽습니다. 대부분의 최신 운영 체제에서는 이메일 클라이언트 자체가 파일 첨부에 대한 처리를 담당합니다. 운영 체제에도 파일 이름 확장자로 파일 처리를 등록하는 자체 방법이 있습니다. 마지막으로 이 모듈에는 이를 수정할 관리자가 없는 상태에서 CVE-2015-20107에 대한 취약점이 보고되어 있습니다.

msilib

Python의 msilib 패키지는 Windows 전용 패키지입니다. Microsoft Installer(MSI)를 생성할 수 있도록 지원합니다. 이 패키지는 캐비닛 파일(CAB)을 생성하기 위한 추가 API도 제공합니다. 이 모듈은 bdist_msi 명령을 사용하여 distutils가 MSI 설치 관리자를 생성하도록 지원하는 데 사용됩니다. 과거에는 CPython의 공식 Windows 설치 관리자를 생성하는 데에도 사용되었습니다.

Microsoft는 새로운 배포 모델로서 Windows 10 앱(AppX)을 선호하여 MSI에서 서서히 벗어나고 있습니다 [3].

pipes

Python의 pipes 모듈은 한 명령의 입력을 다른 명령의 출력으로 파이프하는 도우미를 제공합니다. 이 모듈은 os.popen 위에 구축되어 있습니다. 대신 subprocess 모듈을 사용하십시오.

유지할 모듈

일부 모듈은 원래 폐기 대상으로 제안되었으나 이 PEP에서는 더 이상 그렇게 나열되지 않습니다.

표 2: 철회된 폐기
모듈	폐기 시점	대체재
colorsys	-	colormath, colour, colorspacious, Pillow
fileinput	-	argparse
getopt	-	argparse, optparse
optparse	3.2	argparse
wave	-

colorsys

Python의 colorsys 모듈은 RGB, YIQ, HSL 및 HSV 좌표계 간의 색 변환 함수를 정의합니다.

Walter Dörwald, Petr Viktorin 및 다른 사람들은 colorsys를 유지해 달라고 요청했습니다. 이 모듈은 CSS 색상을 좌표계 간에 변환하는 데 유용합니다. 구현이 단순하고 성숙했으며 핵심 개발에 유지 관리 부담을 주지 않습니다.

PyPI 패키지인 colormath, colour 및 colorspacious는 더 많고 고급화된 기능을 제공합니다. Pillow 라이브러리는 색상 시스템 간에 이미지를 변환하는 데 더 적합합니다.

fileinput

Python의 fileinput 모듈은 sys.argv에서 가져온 파일 목록을 순회하는 도우미를 구현합니다. 이 모듈은 optparse 및 argparse 모듈보다 먼저 만들어졌습니다. 동일한 기능을 argparse 모듈로 구현할 수 있습니다.

여러 핵심 개발자는 빠른 스크립트 작성에 편리하다는 이유로 이 모듈을 표준 라이브러리에 유지하는 데 관심을 표명했습니다.

getopt

Python의 getopt 모듈은 C의 getopt() 옵션 파서를 모방합니다.

사용자에게는 대신 argparse를 사용하도록 권장하지만, getopt 모듈은 여전히 널리 사용됩니다. 이 모듈은 작고 단순하며 C 개발자가 간단한 Python 스크립트를 작성하는 데 편리합니다.

optparse

Python의 optparse 모듈은 argparse 모듈의 전신입니다.

여러 해 동안 사용 중단이 권고되었지만, 제거하기에는 여전히 너무 널리 사용되고 있습니다.

wave

Python의 wave 모듈은 WAV 사운드 형식을 지원합니다.

WAV 형식은 현재도 여전히 유효하므로 이 모듈은 사용 중단되지 않았습니다. wave 모듈은 교육에도 사용됩니다. 예를 들어 아이들에게 컴퓨터로 소리를 내는 방법을 보여 주는 데 사용됩니다.

이 모듈은 audioop 모듈의 간단한 함수 하나를 사용하여 리틀 엔디언 형식과 빅 엔디언 형식 간에 바이트 순서를 교환합니다. 24비트 WAV 지원이 추가되기 전에는 array 모듈을 사용하여 바이트 순서 교환을 구현했습니다. wave의 audioop에 대한 의존성을 제거하려면 바이트 순서 교환 함수를 다른 모듈(예: operator)로 옮기거나, array 모듈에 24비트(3바이트) 배열 지원을 추가할 수 있습니다.

논의

Elana Hashman과 Alyssa Coghlan은 getopt 모듈을 유지할 것을 제안했습니다.
Berker Peksag는 msilib를 사용 중단하고 제거할 것을 제안했습니다.
Brett Cannon은 imp와 같은 모듈에 대한 적극적인 사용 중단 경고와 제거를 Python 3.10까지 연기할 것을 권고했습니다. 버전 3.8은 Python 2의 지원 종료 직전에 출시될 예정입니다. 연기하면 Python 2에서 3.8로 마이그레이션하는 사용자에게 변경 부담이 줄어듭니다.
한때 distutils가 이 PEP와 같은 문장에 언급되었습니다. 긴 논의와 PEP의 지연을 피하기 위해 distutils를 다루지 않기로 결정했습니다. distutils 패키지의 사용 중단은 다른 PEP에서 처리할 예정입니다.
여러 사람(그레고리 P. Smith, David Beazley, Alyssa Coghlan 등)이 wave 모듈을 유지하도록 설득했습니다. [4]
Gregory P. Smith는 nntplib를 사용 중단할 것을 제안했습니다. [4]
Andrew Svetlov는 socketserver 모듈이 문제가 있을 수 있다고 언급했습니다. 그러나 이 모듈은 http.server와 xmlrpc.server를 구현하는 데 사용됩니다. 표준 라이브러리에는 아직 해당 서버를 대체할 수 있는 것이 없습니다.

거부된 아이디어

사용 중단된 모듈을 위한 별도의 저장소를 생성하고 유지 관리하기

이전에 설치할 수 있도록 패키징한 사용 중단 모듈을 포함하는 별도의 저장소를 만들자는 제안이 있었습니다. PEP 작성자 중 한 명은 demo repository까지 만들었습니다. 결국 이러한 저장소를 공식적으로 만들고 유지 관리하는 데 추가되는 작업은 정당화되지 않는다고 결정했습니다. 필요한 경우 사람들이 벤더링할 수 있도록 소스 코드가 계속 CPython 저장소에서 제공될 것이기 때문입니다. 이전 모듈이 사용 중단되고 제거되었을 때에도 유사한 작업은 수행되지 않았으며, 이는 커뮤니티에 부당한 부담이 아니었던 것으로 보입니다.

업데이트 기록

업데이트 1

parser 모듈 사용 중단
fileinput 모듈 유지 vel.
crypt 및 spwd가 위험하고 문제가 많은 이유를 자세히 설명합니다.
cgitb, colorsys, nntplib, smtpd 모듈에 대한 섹션을 개선합니다.
colorsys, crypt, imghdr, sndhdr, spwd 섹션에 이제 적절한 대체 항목을 나열합니다.
socketserver는 http.server 및 xmlrpc.server를 위해 계속 유지될 예정임을 언급합니다.
향후 유지 관리 섹션에 더 이상 사용되지 않는 모듈을 Python 커뮤니티 구성원이 채택할 수 있다고 명시합니다.

업데이트 2

colorsys 모듈을 유지합니다.
전문가를 추가합니다.
토론을 discuss.python.org로 리디렉션합니다.
telnetlib를 사용 중단으로 지정합니다.
email 패키지의 compat32 정책을 사용 중단으로 지정합니다.
개요 표에 생성 연도를 추가합니다.
다음 PEP를 언급하십시오: PEP 206 및 PEP 3108.
aifc, audioop, cgi 및 wave에 대한 섹션을 업데이트합니다.

업데이트 3

레거시 email API 모듈을 유지합니다. 내부 사용 중단은 별도로 처리합니다.

업데이트 4

Brett를 공동 저자로 추가합니다.
PEP의 대상을 Python 3.11로 변경합니다.
cgi의 관련 부분을 대체하는 방법의 예입니다(Martijn Pieters에게 감사드립니다).

참고 자료

Copyright

This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.