Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

PEP 9 – 플레인텍스트 PEP 템플릿 예시

Author:
Barry Warsaw <barry at python.org>
Status:
Withdrawn
Type:
Process
Created:
14-Aug-2001
Post-History:

Resolution:
Python-Dev thread

번역·라이선스 안내

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

Important

This PEP has been withdrawn.

×

2016년 1월 5일부로, 이 PEP는 공식적으로 폐기되었으며 PEP 12로 대체되었습니다. 이제 모든 PEP는 PEP 12에서 설명하는 reStructuredText 형식을 사용해야 하며, 플레인텍스트 PEP는 더 이상 승인되지 않습니다.

초록

    이 PEP는 여러분 자신의 플레인텍스트 PEP를 작성하기 위한 상용구 또는 샘플 템플릿을 제공합니다. PEP 1 [1]의 내용 가이드라인과 함께 사용하면, 아래에 제시된 형식에 맞춰 여러분 자신의 PEP를 손쉽게 작성하실 수 있을 것입니다.

    참고: 웹을 통해 이 PEP를 읽고 계시다면, 아래 단계를 완료하기 위해 먼저 이 PEP의 플레인텍스트 소스를 받아야 합니다. HTML 파일을 템플릿으로 사용하지 마십시오!

    이 (또는 다른 어떤) PEP의 소스를 얻으려면, HTML 페이지 상단에서 "Last-Modified" 줄의 날짜 및 시간을 클릭하십시오. 이는 Python 저장소의 소스 텍스트로 연결되는 링크입니다.

    PEP에서 경량 마크업을 사용하고 싶으시다면, PEP 12 "Sample reStructuredText PEP Template" [2]\ 를 참고하십시오.


근거

    PEP 제출물은 다양한 형태로 들어오며, 아래에 제시된 형식 가이드라인을 모두 따르는 것은 아닙니다. 여러분의 PEP 제출물이 형식 문제로 자동 거부되지 않도록, PEP 1의 내용 가이드라인과 함께 이 템플릿을 사용하십시오.


이 템플릿 사용 방법

    이 템플릿을 사용하려면 먼저 여러분의 PEP가 정보 제공용 PEP가 될지 표준 트랙 PEP가 될지를 결정해야 합니다. 대부분의 PEP는 Python 언어나 표준 라이브러리\ 에 새로운 기능을 제안하기 때문에 표준 트랙입니다. 확신이 서지 않는다면 자세한 내용은 PEP 1을 읽거나 PEP 편집자 <peps@python.org>에게 문의하십시오.

    여러분의 PEP가 어떤 유형이 될지 결정했다면, 아래의 지침을 따르십시오.

    - 이 파일(HTML이 아닌 .txt 파일!)의 복사본을 만들고 다음 편집을 수행하십시오.

    - "PEP: 9" 헤더를 "PEP: XXX"로 바꾸십시오. 아직 PEP 번호를 배정받지 않았기 때문입니다.

    - Title 헤더를 여러분 PEP의 제목으로 변경하십시오.

    - Version 헤더와 Last-Modified 헤더는 그대로 두십시오. 여러분의 PEP를 Python의 Subversion 저장소에 등록할 때 저희가 처리하겠습니다. 이 헤더들은 저장소에 의해 자동으로 확장되는 키워드("$" 기호로 둘러싸인 "Revision"과 "Date")로 구성됩니다. 확장된 날짜나 리비전 텍스트는 편집하지 마십시오.

    - Author 헤더를 변경하여 여러분의 이름을, 그리고 선택적으로 이메일 주소를 포함하십시오. 형식을 신중히 따르도록 주의하십시오: 이름이 먼저 나와야 하며, 괄호 안에 포함되어서는 안 됩니다. 이메일 주소는 두 번째로 나올 수 있으며(생략할 수도 있습니다), 나올 경우 꺾쇠괄호 안에 표시되어야 합니다. 이메일 주소를 난독화해도 괜찮습니다.

    - 새 기능에 대한 논의를 위한 메일링 리스트가 있다면, Author 헤더 바로 뒤에 Discussions-To 헤더를 추가하십시오. 사용할 메일링 리스트가 python-list@python.org나 python-dev@python.org 중 하나이거나, 논의가 여러분에게 직접 전달되어야 하는 경우에는 Discussions-To 헤더를 추가하지 말아야 합니다. 대부분의 Informational PEP에는 Discussions-To 헤더가 없습니다.

    - Status 헤더를 "Draft"로 변경하십시오.

    - Standards Track PEP의 경우, Type 헤더를 "Standards Track"으로 변경하십시오.

    - Informational PEP의 경우, Type 헤더를 "Informational"로 변경하십시오.

    - Standards Track PEP의 경우, 여러분의 기능이 현재 개발 중인 다른 PEP의 승인에 의존한다면, Type 헤더 바로 뒤에 Requires 헤더를 추가하십시오. 값은 여러분의 PEP가 의존하는 PEP의 번호여야 합니다. 의존하는 기능이 Final PEP에 기술되어 있다면 이 헤더를 추가하지 마십시오.

    - Created 헤더를 오늘 날짜로 변경하십시오. 형식을 신중하게 따르십시오. dd-mmm-yyyy 형식이어야 하며, 여기서 mmm은 영문 3글자 월 약어, 즉 Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec 중 하나입니다.

    - Standards Track PEP의 경우, Created 헤더 뒤에 Python-Version 헤더를 추가하고, 값을 Python의 다음 계획된 버전, 즉 여러분의 새 기능이 처음 등장하기를 바라는 버전으로 설정하십시오. 여기에 알파나 베타 릴리스 표기를 사용하지 마십시오. 따라서 Python의 마지막 버전이 2.2 alpha 1이었고 여러분의 새 기능을 Python 2.2에 넣고자 한다면, 헤더를 다음과 같이 설정하십시오.

      Python-Version: 2.2

    - "Post-History"는 지금은 그대로 두십시오. PEP를 python-list@python.org나 python-dev@python.org에 게시할 때마다 이 헤더에 날짜를 추가하게 됩니다. 예를 들어 2001년 8월 14일과 2001년 9월 3일에 PEP를 메일링 리스트에 게시했다면, Post-History 헤더는 다음과 같은 형태가 됩니다:

      Post-History: 14-Aug-2001, 03-Sept-2001

      새 날짜는 수동으로 추가하고 커밋해야 합니다. 커밋 권한이 없다면, 변경 사항을 PEP 편집자에게 보내십시오.

    - PEP가 이전 PEP를 대체한다면 Replaces 헤더를 추가하십시오. 이 헤더의 값은 새 PEP가 대체하는 PEP의 번호입니다. 이 헤더는 이전 PEP가 "최종" 상태, 즉 Accepted, Final, Rejected 중 하나인 경우에만 추가하십시오. 경쟁하는 아이디어를 제출하는 경우라면, 아직 열려 있는 이전 PEP를 대체하는 것이 아닙니다.

    - 이제 이 알아볼 수 없는 문구를 모두 자신의 글로 대체하여 PEP의 Abstract, Rationale, 그리고 그 밖의 내용을 작성하십시오. 아래의 형식 지침, 특히 탭 문자 금지와 들여쓰기 요구 사항을 반드시 준수하십시오.

    - References와 Copyright 절을 갱신하십시오. 보통은 PEP를 퍼블릭 도메인으로 공개하게 되며, 이 경우 "Copyright" 절은 그대로 두면 됩니다. 대안으로 Open Publication License[3]를 사용할 수도 있지만, 퍼블릭 도메인이 여전히 강력히 권장됩니다.

    - 이 파일 끝에 있는 폼피드 문자("^L" 또는 \f)를 포함한 자잘한 Emacs 잔재는 그대로 두십시오.

    - PEP 제출물은 PEP 편집자(peps@python.org)에게 추적 불가능한 1센트 동전 10만 달러어치와 함께 보내십시오. (농담입니다, 아직 정신 차리고 있는지 확인해 보고 싶었습니다. :)


일반 텍스트 PEP 서식 요구 사항

    PEP 제목은 0번째 열에서 시작해야 하며, 각 단어의 첫 글자는 책 제목에서처럼 대문자로 표기해야 합니다. 약어는 모두 대문자로 표기해야 합니다. 각 절의 본문은 4칸 들여써야 합니다. 본문 내의 코드 예제는 추가로 4칸 더 들여써야 하며, 텍스트를 읽기 쉽게 만들기 위해 필요한 경우 다른 들여쓰기를 사용할 수 있습니다. 절 본문의 마지막 줄과 다음 절 제목 사이에는 빈 줄 두 개를 사용해야 합니다.

    모든 문장의 끝에 공백 두 칸을 추가하는 Emacs 관례를 따라야 합니다. 문단은 70번째 열까지 채워야 하지만, 어떤 경우에도 줄이 79번째 열을 넘어서는 안 됩니다. 코드 예제가 79번째 열을 넘어갈 경우, 다시 작성해야 합니다.

    탭 문자는 문서 어디에도 절대 나타나서는 안 됩니다. PEP는 이 PEP 하단에 예시로 포함된 표준 Emacs 스탠자를 포함해야 합니다.

    PEP 본문에서 외부 웹 페이지를 참조할 때는, 텍스트에 해당 페이지의 제목을 포함하고 URL은 각주 참조로 표기해야 합니다. PEP 본문 텍스트에 URL을 포함하지 마십시오. 예:

        자세한 내용은 Python 언어 웹사이트[1]를 참조하십시오.
        ...
        [1] http://www.python.org

    PEP 1, PEP Purpose and Guidelines, Warsaw, Hylton 제목은 선택적으로 나타낼 수 있습니다. 대괄호로 묶인 번호인 각주 참조를 추가하십시오. 각주 본문에는 해당 PEP의 제목과 저자가 포함되어야 합니다. 명시적인 URL을 별도의 줄에 선택적으로 포함할 수 있으나, References 절에서만 가능합니다. pep2html.py 스크립트가 URL을 자동으로 계산한다는 점에 유의하십시오. PEP 1, PEP Purpose and Guidelines, Warsaw, Hylton

            ...
            PEP 스타일에 대한 자세한 내용은 PEP 1 [7]을 참조하십시오
            ...

        참고 문헌

            [7] PEP 1, PEP Purpose and Guidelines, Warsaw, Hylton
                http://peps.python.org/pep-0001/

    PEP에 대한 명시적인 URL을 제공하기로 결정했다면, 다음을 URL 템플릿으로 사용하십시오:

        http://peps.python.org/pep-xxxx/

    URL의 PEP 번호는 정확히 4자리가 되도록 왼쪽에 0을 채워야 하지만, 본문 텍스트의 PEP 번호는 절대로 0을 채우지 않습니다.


참고 문헌

    [1] PEP 1, PEP Purpose and Guidelines, Warsaw, Hylton
        http://peps.python.org/pep-0001/

    [2] PEP 12, Sample reStructuredText PEP Template, Goodger, Warsaw
        http://peps.python.org/pep-0012/

    [3] http://www.opencontent.org/openpub/



저작권

    이 문서는 퍼블릭 도메인으로 공개되었습니다.