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
번역·라이선스 안내
이 비공식 한국어 번역은 원문 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 초창기에는 인터프리터에 유용한 모듈이 대거 포함되어 있었습니다. 이는 흔히 “배터리 포함(batteries included)” 철학이라고 불렸으며, Python 성공 신화의 초석 중 하나였습니다. 사용자는 간단한 웹 서버를 작성하거나 이메일을 파싱하기 위해 별도의 패키지를 다운로드하고 설치하는 방법을 알아낼 필요가 없었습니다.
시대가 바뀌었습니다. PyPI(옛 이름 Cheeseshop), setuptools, 그리고 이후 pip가 도입되면서 패키지를 다운로드하고 설치하는 일이 간단하고 수월해졌습니다. 오늘날 Python에는 풍부하고 활발한 서드파티 패키지 생태계가 있습니다. PyPI에서 패키지를 설치하거나 수많은 Python 또는 Linux 배포판 중 하나를 사용하는 것이 사실상 표준입니다.
반면에 Python의 표준 라이브러리에는 쓸모없는 잔재, 불필요한 기능 중복, 없어도 되는 기능이 쌓여 가고 있습니다. 이는 여러 가지 이유로 바람직하지 않습니다.
- 모듈이 추가될 때마다 Python 핵심 개발 팀의 유지보수 비용이 늘어납니다. 팀의 자원은 한정되어 있으므로, 유지보수 비용을 줄이면 다른 개선 작업에 쓸 개발 시간을 확보할 수 있습니다.
- 표준 라이브러리의 모듈은 일반적으로 선호되며 문제에 대한 사실상의 해결책으로 여겨집니다. 대다수 사용자는 설득력 있는 이유가 있을 때만 표준 라이브러리 모듈을 대체하기 위해 서드파티 모듈을 선택합니다. 예를 들어
xml대신lxml을 선택하는 경우입니다. 유지보수되지 않는 표준 라이브러리 모듈을 제거하면 커뮤니티가 기여한 모듈이 널리 사용될 가능성이 높아집니다. - 군더더기 없이 간결한 표준 라이브러리는 저장 공간이 수백 킬로바이트에 불과한 장치(예: BBC Micro:bit)처럼 자원이 제한된 플랫폼에 이점이 됩니다. BeeWare나 WebAssembly(예: pyodide) 같은 모바일 플랫폼의 Python도 다운로드 크기가 줄어드는 이점을 얻습니다.
이 PEP의 모듈들은 제거에 대한 논란이 가장 적거나 제거했을 때 이점이 가장 크기 때문에 폐지 대상으로 선정되었습니다. 예를 들어 논란이 가장 적은 것은 1980년대 후반 SPARC 및 NeXT 워크스테이션에서 사용되었던 sunau 오디오 형식과 같은 30년 된 멀티미디어 형식입니다. 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 기반 프로젝트가 있습니다.
| 모듈 | 폐지 버전 | 제거 대상 | 추가 버전 | 유지 관리자 유무 | 대체 항목 |
|---|---|---|---|---|---|
| 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 인코딩
uu 모듈은 1980년에 나온 오래된 이메일용 바이너리 인코딩 형식인 uuencode 형식을 제공합니다. uu 형식은 MIME으로 대체되었습니다. uu 코덱은 binascii 모듈이 제공합니다. 같은 인코딩을 위한 코덱인 encodings/uu_codec.py도 있는데, 이것 역시 폐지되어야 합니다.
xdrlib
xdrlib 모듈은 Sun External Data Representation Standard를 지원합니다. XDR은 1987년에 나온 오래된 바이너리 직렬화 형식입니다. 오늘날에는 NFS 같은 특수한 분야 밖에서는 거의 사용되지 않습니다.
멀티미디어 모듈
aifc
aifc 모듈은 AIFF 및 AIFF-C 파일의 읽기와 쓰기를 지원합니다. Audio Interchange File Format(오디오 교환 파일 형식)은 Amiga IFF에 기반한 1988년의 오래된 오디오 형식입니다. 이 형식은 주로 Apple Macintosh에서 사용되었습니다. 오늘날에는 소수의 특수한 애플리케이션만 AIFF를 사용합니다.
한 사용자는 영화 후반 작업 업계에서 AIFC 파일 형식을 많이 사용한다고 밝혔습니다 [6]. 이 PEP가 처음 게시되기 전까지는 비공개 소스 소프트웨어와 내부 소프트웨어에서 aifc 모듈이 어떻게 사용되는지 알려져 있지 않았습니다. 이는 aifc 모듈을 표준 라이브러리에 유지해야 한다는 설득력 있는 인자가 될 수 있습니다. 이 파일 형식은 안정적이며 모듈에 유지 보수가 많이 필요하지 않습니다. Python이 얻는 전략적 이점이 부담보다 클 수 있습니다.
audioop
audioop 모듈에는 원시 오디오 데이터와 적응형 차분 펄스 부호 변조 오디오 데이터를 조작하는 헬퍼 함수가 들어 있습니다. 이 모듈은 추가 의존성 없이 C로 구현되어 있습니다. aifc, sunau, wave 모듈은 일부 작업에서 audioop에 의존합니다.
wave 모듈의 byteswap 연산은 약간의 추가 작업만으로 대체할 수 있습니다. aifc도 폐지 예정으로 지정하지 않는 경우에는 audioop 모듈의 축소 버전을 비공개 구현 세부 사항으로 전환합니다. 예를 들어 byteswap, alaw2lin, ulaw2lin, lin2alaw, lin2ulaw, lin2adpcm을 포함하는 _audioop으로 전환할 수 있습니다.
chunk
chunk 모듈은 Electronic Arts의 Interchange File Format(교환 파일 형식)을 읽고 쓰는 기능을 제공합니다. IFF는 원래 Commodore와 Amiga용으로 도입된 오래된 오디오 파일 형식입니다. 이 형식은 이제 더 이상 의미가 없습니다.
imghdr
imghdr 모듈은 파일이나 버퍼의 처음 32바이트를 보고 이미지 파일 형식을 추측하는 간단한 도구입니다. 제한된 수의 형식만 지원하며 해상도도 색 심도도 반환하지 않습니다.
ossaudiodev
ossaudiodev 모듈은 사운드 재생 및 캡처 장치에 대한 인터페이스인 Open Sound System을 지원합니다. OSS는 처음에는 자유 소프트웨어였지만, 이후 새로운 사운드 장치 지원과 개선 사항은 독점 소프트웨어로 제공되었습니다. Linux 커뮤니티는 OSS를 버리고 ALSA [1]를 택했습니다. OpenBSD와 NetBSD 같은 일부 운영 체제는 OSS의 불완전한 [2] 에뮬레이션을 제공합니다.
제가 아는 한, 현재 Open Sound System을 사용하는 널리 쓰이는 운영 체제는 FreeBSD가 유일합니다. ossaudiodev에는 2003년 이후로 어떠한 개선이나 새 기능도 추가되지 않았습니다. 2003년 이후의 모든 커밋은 프로젝트 전반에 걸친 코드 정리와 몇 가지 버그 수정뿐입니다. 이 모듈에 관심을 가지고 실제로 사용하는 사람들이 모듈을 유지 관리하고 배포한다면 FreeBSD 커뮤니티와 코어 개발 모두에 도움이 될 것입니다.
표준 라이브러리에는 예전에 오디오 관련 모듈이 더 많이 있었습니다. 다른 오디오 장치 인터페이스(audiodev, linuxaudiodev, sunaudiodev)는 2007년에 PEP 3108 표준 라이브러리 재구성의 일환으로 제거되었습니다.
sndhdr
sndhdr 모듈은 imghdr 모듈과 비슷하지만 오디오 형식을 대상으로 합니다. 파일이나 버퍼의 처음 512바이트를 보고 파일 형식, 채널 수, 프레임 레이트, 샘플 폭을 추측합니다. 이 모듈은 AU, AIFF, HCOM, VOC, WAV 및 기타 아주 오래된 형식만 지원합니다.
sunau
sunau 모듈은 Sun AU 사운드 형식을 지원합니다. 이 역시 오래되어 더 이상 쓰이지 않는 파일 형식입니다.
네트워킹 모듈
asynchat
asyncore
asyncore 모듈은 비동기 소켓 서비스 클라이언트와 서버를 위한 최초의 모듈이었습니다. 이 모듈은 asyncio로 대체되었으며 Python 3.6부터 폐지되었습니다.
asyncore 모듈은 표준 라이브러리 테스트에서도 사용됩니다. ftplib, logging, smptd, smtplib, ssl 테스트는 부분적으로 asyncore를 기반으로 합니다. 이 테스트들은 asyncio나 스레딩을 사용하도록 갱신해야 합니다.
cgi
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
cgitb 모듈은 설정 가능한 트레이스백을 제공하는 cgi 모듈의 도우미입니다.
cgitb 모듈은 주요 Python 웹 프레임워크(Django, Pyramid, Plone, Flask, CherryPy, Bottle) 중 어디에서도 사용되지 않습니다. Paste만이 선택적인 디버깅 미들웨어에서 이 모듈을 사용합니다.
smtpd
smtpd 모듈은 SMTP 메일 서버의 간단한 구현을 제공합니다. 모듈 문서는 이 모듈을 폐지 예정으로 표시하고 대신 aiosmtpd를 권장합니다. 폐지 예정 메시지는 3.4.7, 3.5.4, 3.6.1 릴리스에서 추가되었습니다.
nntplib
nntplib 모듈은 네트워크 뉴스 전송 프로토콜(Network News Transfer Protocol, nntp)의 클라이언트 측을 구현합니다. 뉴스 그룹은 한때 온라인 토론의 지배적인 플랫폼이었습니다. 지난 20년 동안 뉴스는 느리지만 꾸준히 메일링 리스트와 웹 기반 토론 플랫폼으로 대체되었습니다. Twisted도 NNTP 지원을 폐지할 계획이며, pynntp는 2014년 이후로 아무런 활동이 없습니다. 이는 NNTP 지원에 대한 대중의 관심이 줄어들고 있다는 좋은 지표입니다.
nntplib 테스트는 최근 들어 추가 작업을 유발해 왔습니다. Python에는 NNTP의 클라이언트 측만 포함되어 있으므로, 테스트는 외부 뉴스 서버에 접속합니다. 이 서버들은 때때로 사용할 수 없거나, 너무 느리거나, IPv6에서 올바르게 동작하지 않습니다. 이러한 상황 때문에 빌드봇에서 테스트 실행 결과가 불안정해집니다.
telnetlib
telnetlib 모듈은 Telnet 프로토콜을 구현하는 Telnet 클래스를 제공합니다.
운영 체제 인터페이스
crypt
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(pluggable authentication module, 플러그형 인증 모듈)을 거쳐야 합니다. spwd 폐지 항목을 참조하십시오.
nis
nis 모듈은 NIS/YP 지원을 제공합니다. Network Information Service / Yellow Pages는 Sun Microsystems가 개발한, 오래되고 폐지된 디렉터리 서비스 프로토콜입니다. 1992년에 후속으로 설계된 NIS+는 끝내 자리 잡지 못했습니다. 오랫동안 libc의 Name Service Switch, LDAP, Kerberos/GSSAPI가 NIS보다 더 강력하고 더 안전한 대체 수단으로 여겨져 왔습니다.
spwd
spwd 모듈은 비표준 API를 사용하여 Unix 섀도 비밀번호 데이터베이스에 대한 직접 접근을 제공합니다.
일반적으로 spwd를 사용하는 것은 좋지 않습니다. 이 모듈은 시스템 보안 정책을 우회하고, PAM 스택을 사용하지 않으며, NSS를 무시하기 때문에 로컬 사용자 계정에서만 사용할 수 있습니다. 접근 제어에 spwd 모듈을 사용하면 PAM의 접근 제어를 우회하게 되므로 이는 보안 버그로 간주해야 합니다.
또한 spwd 모듈은 shadow(3) API를 사용합니다. getspnam(3) 같은 함수는 /etc/shadow 파일에 직접 접근합니다. 이는 위험하며, SELinux나 AppArmor 같은 보안 엔진을 사용하는 시스템에서는 격리된 서비스에 아예 금지되어 있습니다.
기타 모듈
mailcap
mailcap 패키지는 메일 기능(mail capability) 파일을 읽어 이메일 첨부 파일 처리를 돕습니다. 대부분의 최신 운영 체제에서는 이메일 클라이언트가 직접 첨부 파일을 처리합니다. 운영 체제에도 파일 이름 확장자별로 파일 처리 방식을 등록하는 자체 방법이 있습니다. 끝으로, 이 모듈에는 CVE-2015-20107가 보고되어 있지만 수정을 도울 유지 관리자가 없습니다.
msilib
msilib 패키지는 Windows 전용 패키지입니다. 이 패키지는 Microsoft 설치 프로그램(MSI) 생성을 지원합니다. 또한 이 패키지는 캐비닛 파일(CAB)을 생성하는 추가 API도 제공합니다. 이 모듈은 distutils가 bdist_msi 명령으로 MSI 설치 프로그램을 생성할 수 있도록 하는 데 사용됩니다. 과거에는 CPython의 공식 Windows 설치 프로그램을 생성하는 데에도 사용되었습니다.
Microsoft는 새로운 배포 모델인 Windows 10 앱(AppX)을 선호하여 MSI에서 서서히 벗어나고 있습니다 [3].
pipes
pipes 모듈은 한 명령의 입력을 다른 명령의 출력으로 파이프하는 도우미를 제공합니다. 이 모듈은 os.popen 위에 구현되어 있습니다. 사용자는 대신 subprocess 모듈을 사용하는 것이 좋습니다.
유지할 모듈
일부 모듈은 원래 폐지 대상으로 제안되었지만 이 PEP에서는 더 이상 폐지 대상으로 나열되지 않습니다.
| 모듈 | 폐지 버전 | 대체 항목 |
|---|---|---|
| colorsys | - | colormath, colour, colorspacious, Pillow |
| fileinput | - | argparse |
| getopt | - | argparse, optparse |
| optparse | 3.2 | argparse |
| wave | - |
colorsys
colorsys 모듈은 RGB, YIQ, HSL, HSV 좌표계 사이의 색상 변환 함수를 정의합니다.
Walter Dörwald, Petr Viktorin 등이 colorsys를 유지해 달라고 요청했습니다. 이 모듈은 CSS 색상을 한 좌표계에서 다른 좌표계로 변환하는 데 유용합니다. 구현이 단순하고 성숙했으며, 코어 개발에 유지 보수 부담을 주지 않습니다.
PyPI 패키지 colormath, colour, colorspacious는 더 많은 고급 기능을 제공합니다. 이미지를 색 체계 간에 변환하는 데는 Pillow 라이브러리가 더 적합합니다.
fileinput
fileinput 모듈은 sys.argv에서 가져온 파일 목록을 순회하는 도우미를 구현합니다. 이 모듈은 optparse 모듈과 argparse 모듈보다 먼저 만들어졌습니다. 같은 기능을 argparse 모듈로 구현할 수 있습니다.
여러 코어 개발자가 간단한 스크립트를 빠르게 작성할 때 편리하다는 이유로 이 모듈을 표준 라이브러리에 유지하고 싶다는 뜻을 밝혔습니다.
getopt
getopt 모듈은 C의 getopt() 옵션 파서를 모방합니다.
사용자에게 argparse를 대신 사용하도록 권장하고 있지만, getopt 모듈은 여전히 널리 사용됩니다. 이 모듈은 작고 단순하며, C 개발자가 간단한 Python 스크립트를 작성하기에 편리합니다.
optparse
optparse 모듈은 argparse 모듈의 전신입니다.
여러 해 전에 폐지되었지만, 여전히 너무 널리 사용되고 있어 제거할 수 없습니다.
wave
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에서 다룰 것입니다.
- 여러 사람(Gregory P. Smith, David Beazley, Alyssa Coghlan 등)이 wave 모듈을 유지하도록 저를 설득했습니다. [4]
- Gregory P. Smith는 nntplib 폐지를 제안했습니다. [4]
- Andrew Svetlov는
socketserver모듈이 문제의 소지가 있다고 언급했습니다. 하지만 이 모듈은http.server와xmlrpc.server를 구현하는 데 사용됩니다. 표준 라이브러리에는 아직 이 서버들을 대체할 수단이 없습니다.
기각된 아이디어
폐기된 모듈을 위한 별도 저장소의 생성/유지 관리
이전에 폐기된 모듈을 설치할 수 있도록 패키징하여 담은 별도 저장소를 만들자는 제안이 있었습니다. PEP 작성자 중 한 명은 데모 저장소까지 만들었습니다. 하지만 결국, 소스 코드가 CPython 저장소에서 계속 제공되어 필요한 사람이 벤더링할 수 있으므로, 그러한 저장소를 공식적으로 만들고 유지 관리하는 데 드는 추가 작업량은 정당화되지 않는다고 결정되었습니다. 이전에 모듈이 폐기되고 제거되었을 때도 비슷한 작업은 이루어지지 않았으며, 그것이 커뮤니티에 과도한 부담이 되지는 않았던 것으로 보입니다.
업데이트 이력
업데이트 1
업데이트 2
갱신 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.