PEP 3131 – 비ASCII 식별자 지원

Author:: Martin von Löwis <martin at v.loewis.de>
Status:: Final
Type:: Standards Track
Created:: 01-May-2007
Python-Version:: 3.0
Post-History:

Table of Contents

초록
근거
일반적인 반론
언어 변경 사양
정책 사양
구현
미해결 문제
논의
Copyright

번역·라이선스 안내

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

초록

이 PEP는 Python 식별자에서 악센트가 붙은 문자, 키릴 문자, 그리스 문자, 한자 등의 비ASCII 문자를 지원할 것을 제안합니다.

Python 코드는 영어에 익숙하지 않거나 라틴 문자 표기 체계에도 충분히 익숙하지 않은 전 세계의 많은 사람이 작성합니다. 이러한 개발자는 이름을 지정하려는 개념을 영어로 번역할 때 흔히 부정확한 번역을 만들어 내야 하기보다는, 모국어로 된 이름을 사용하여 클래스와 함수를 정의하고 싶어 하는 경우가 많습니다. 모국어로 식별자를 사용하면 해당 언어를 사용하는 사람들 사이에서 코드의 명확성과 유지 관리성이 향상됩니다.

일부 언어에는 일반적인 음역 체계가 존재합니다(특히 라틴 문자 기반 표기 체계의 경우). 다른 언어에서는 사용자가 라틴 문자를 사용하여 모국어 단어를 표기하는 데 더 큰 어려움을 겪습니다.

일반적인 반론

이 제안과 유사한 제안에 대해 몇 가지 반론이 자주 제기됩니다.

사람들은 라이브러리를 사용하려면 키보드로 입력할 수 없는 문자를 사용해야 하므로 라이브러리를 사용할 수 없을 것이라고 주장합니다. 그러나 라이브러리 사용에 대한 여러 제약을 결정하는 것은 라이브러리 설계자의 선택입니다. 사람들은 소스 코드에 물리적으로 접근할 수 없거나(공개되지 않았기 때문), 라이선스가 사용을 금지하거나, 문서가 이해할 수 없는 언어로 작성되어 있기 때문에 라이브러리를 사용하지 못할 수도 있습니다. 라이브러리를 널리 이용할 수 있도록 하려는 개발자는 공개 여부, 라이선스, 문서의 언어, 식별자의 언어 등 여러 가지 사항을 명시적으로 선택해야 합니다. 이러한 결정을 내리는 것은 항상 작성자의 선택이어야 하며, 언어 설계자의 선택이어서는 안 됩니다.

특히 널리 사용되기를 바라는 프로젝트는 모든 식별자, 주석 및 문서를 영어로 작성한다는 정책을 수립할 수 있습니다(그러한 정책의 예는 GNU 코딩 스타일 가이드를 참조하십시오). 언어를 ASCII 전용 식별자로 제한해도 주석과 문서가 영어로 작성되도록 강제하거나 식별자가 실제로 영어 단어가 되도록 강제하지는 않으므로, 어쨌든 추가 정책이 필요합니다.

언어 변경 사양

Python의 식별자 구문은 Unicode standard annex UAX-31에 기반하며, 아래에 정의된 상세 설명과 변경 사항을 적용합니다.

ASCII 범위(U+0001..U+007F)에서 식별자에 사용할 수 있는 문자는 Python 2.5에서와 동일합니다. 이 사양은 ASCII 범위 밖의 추가 문자만 도입합니다. 그 밖의 문자에 대해서는 unicodedata 모듈에 포함된 버전의 유니코드 문자 데이터베이스를 사용하여 분류합니다.

식별자 구문은 <XID_Start> <XID_Continue>*입니다.

XID_Start 또는 XID_Continue 속성을 갖는 문자에 대한 정확한 사양은 Python에서 사용하는 유니코드 데이터의 DerivedCoreProperties file에서 확인할 수 있습니다(이 PEP가 작성될 당시에는 4.1이었습니다). 참고로 이러한 집합의 구성 규칙을 아래에 제시합니다. XID_* 속성은 ID_Start/ID_Continue에서 파생되며, ID_Start/ID_Continue 자체도 다른 항목에서 파생됩니다.

ID_Start은 대문자(Lu), 소문자(Ll), 제목 대문자(Lt), 수식 문자(Lm), 기타 문자(Lo), 문자 숫자(Nl)라는 일반 범주 중 하나에 해당하는 모든 문자와 밑줄 및 Other_ID_Start 속성을 가진 문자로 정의됩니다. 그런 다음 XID_Start는 정규화 과정에서 이 집합을 닫으며, NFKC 정규화 결과가 더 이상 ID_Start ID_Continue* 형식이 아닌 모든 문자를 제거합니다.

ID_Continue는 ID_Start의 모든 문자에 비간격 표시(Mn), 간격 결합 표시(Mc), 십진수(Nd), 연결 구두점(Pc), 그리고 Other_ID_Continue 속성을 가진 문자를 추가한 것으로 정의됩니다. 다시 말해 XID_Continue는 NFKC 정규화 과정에서 이 집합을 닫으며, 카탈루냐어를 지원하기 위해 U+00B7도 추가합니다.

파싱하는 동안 모든 식별자를 정규 형식 NFKC로 변환하며, 식별자 비교는 NFKC를 기준으로 수행합니다.

Unicode 4.1의 모든 유효한 식별자 문자를 나열한 비규범적 HTML 파일은 https://web.archive.org/web/20081016132748/http://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html 에서 찾을 수 있습니다.

정책 사양

Python 코딩 스타일에 더하여 다음 정책을 규정합니다. Python 표준 라이브러리의 모든 식별자는 ASCII 전용 식별자를 반드시 사용해야 하며, 가능한 경우 영어 단어를 사용하는 것이 좋습니다(많은 경우 영어가 아닌 약어와 기술 용어가 사용됩니다). 또한 문자열 리터럴과 주석도 ASCII여야 합니다. 유일한 예외는 (a) 비ASCII 기능을 테스트하는 테스트 케이스와 (b) 작성자의 이름입니다. 이름이 라틴 문자를 기반으로 하지 않는 작성자는 이름을 라틴 문자로 음역하여 반드시 제공해야 합니다.

선택 사항으로 이 명세를 Python 2.x에 적용할 수 있습니다. 이 경우 ASCII 전용 식별자는 네임스페이스 딕셔너리에서 계속 바이트 문자열 객체로 표현되며, 비ASCII 문자가 포함된 식별자는 유니코드 문자열로 표현됩니다.

구현

파서에 다음 변경 사항을 적용해야 합니다.

소스 코드의 UTF-8 표현에서 비ASCII 문자가 발견되면, 첫 번째 ASCII 비식별자 문자(예: 공백 또는 구두점 문자)를 찾기 위해 앞쪽으로 스캔합니다.
전체 UTF-8 문자열을 함수에 전달하여 문자열을 NFKC로 정규화한 다음 식별자 구문을 따르는지 확인합니다. 순수 ASCII 식별자에는 이러한 호출을 수행하지 않으며, 순수 ASCII 식별자는 현재와 같은 방식으로 계속 파싱됩니다. 유니코드 데이터베이스는 Other_ID_{Start|Continue} 속성을 포함하기 시작해야 합니다.
이 명세를 2.x에 구현하는 경우, 유니코드 문자열이 __dict__ 슬롯에 키로 나타날 때도 리플렉션 라이브러리(예: pydoc)가 계속 작동하는지 확인해야 합니다.

미해결 문제

John Nagle은 유니코드 식별자의 보안 메커니즘을 다루는 Unicode Technical Standard #39를 검토할 것을 제안했습니다. 이것을 이 PEP에 정확히 어떻게 적용할 수 있는지는 명확하지 않으며, 가능한 결과는 다음과 같습니다.

xidmodifications.txt에 “restricted”로 나열된 문자에 대해 경고합니다.
여러 스크립트를 혼합하여 사용하는 식별자에 대해 경고합니다.
어떤 방식으로든 Confusable Detection을 수행합니다.

뒤의 두 접근 방식에서는 알고리즘이 정확히 어떻게 작동해야 하는지가 명확하지 않습니다. 여러 스크립트를 혼합하는 경우 특정 종류의 혼합은 허용되어야 할 것 같습니다. 이것이 5절에서 언급된 “Common” 및 “Inherited” 스크립트입니까? Confusable Detection의 경우 혼동 여부를 비교하려면 두 식별자가 필요한 것으로 보입니다. 이를 단일 식별자에만 어떤 방식으로든 적용하여 경고하는 것이 가능합니까?

후속 논의에서 John Nagle이 실제로 제안하려 했던 것은 “Highly Restrictive” 수준의 UTR#36였음이 밝혀졌습니다.

여러 사람이 Java, JavaScript 및 C#에서처럼 형식 제어 문자(일반 범주 Cf)를 허용하고 무시하자고 제안했습니다. 이것이 개선 효과가 있을지는 명확하지 않으며(RTL 언어에는 도움이 될 수도 있습니다), 필요하다면 나중에 추가할 수 있습니다.

일부 사람들은 런타임에 이 PEP에 대한 지원 여부를 선택하는 옵션을 원합니다. 해당 옵션이 정확히 무엇이어야 하는지와 기본값이 정확히 무엇이어야 하는지에 대해서는 의견이 다양합니다. Guido van Rossum commented은 인터프리터에 전달하는 전역 플래그는 모든 모듈에 적용되므로 허용할 수 없다고 설명했습니다.

논의

Ka-Ping Yee summarizes discussion and further objection는 논의와 추가 이의를 다음과 같이 요약합니다.

식별자에 모든 유니코드 문자를 포함하도록 허용해야 합니까?
비ASCII 식별자를 전면적으로 허용할 때의 단점은 다음과 같습니다.
1. Python은 화면이나 종이에서 사람이 읽을 수 있는 표시로 신뢰성 있게 왕복 변환할 수 있는 능력을 잃게 됩니다.
2. Python은 새로운 종류의 보안 공격에 취약해지며, 코드와 제출된 패치를 검사하기가 훨씬 더 어려워집니다.
3. 이제 사람은 Python 구문을 검증할 수 없게 됩니다.
4. Unicode는 아직 초기 단계입니다; 그 문제는 아직 충분히 이해되거나 해결되지 않았으며 도구 지원도 미약합니다.
5. ASCII가 아닌 식별자를 사용하는 언어는 서로 다른 문자 집합과 정규화 방식을 사용합니다; PEP 3131의 선택은 명확하지 않습니다.
6. Unicode bidi 알고리즘은 숫자나 연산자가 가까이 있을 때 RTL 텍스트에 대해 매우 혼란스러운 표시 순서를 만들어 냅니다.
기본 동작은 ASCII 식별자만 받아들여야 합니까, 아니면 ASCII가 아닌 문자를 포함하는 식별자도 받아들여야 합니까?
기본적으로 ASCII만 허용해야 한다는 주장:
1. 기본적으로 ASCII가 아닌 식별자를 허용하면 일반적인 관행과 가정이 미묘하게 또는 자신도 모르게 잘못됩니다; 드물게 잘못되는 것이 명백하게 잘못되는 것보다 더 나쁩니다.
2. 아마도 예상하지 못한 상황을 만났을 때 조용히 실패하기보다는 경고를 발생시키는 편이 낫습니다.
3. 현재 사용되는 모든 식별자는 ASCII 전용입니다; 앞으로 사용될 식별자의 압도적 다수도 ASCII 전용일 것입니다.
1. 편협한 것은 ASCII 옹호자들이 아니라 Unicode 도입이 일부 영역에 국한된 현상입니다.
2. Python은 탭과 공백의 일관성을 검사하는 것과 같은 이유로 ASCII 전용 식별자를 검사해야 합니다.
3. 점진적인 변경이 더 안전합니다.
4. ASCII 전용 기본값은 오픈 소스 개발과 소스 코드 공유를 촉진합니다.
5. 기존 프로젝트는 Unicode 식별자가 미치는 영향을 걱정하는 데 어떠한 정신적 수고도 낭비하지 않아도 됩니다.
ASCII가 아닌 식별자를 선택 사항으로 제공해야 합니까?
플래그를 지지하는 다양한 의견이 있습니다(기본값을 무엇으로 해야 하는지를 두고 논쟁은 있었지만, 비활성화 옵션이 없어야 한다고 말하는 사람은 아무도 없는 듯합니다).
식별자 문자 집합을 구성할 수 있어야 합니까?
사용자가 혼동하기 쉽거나 익숙하지 않은 문자의 단점 없이 자신의 언어를 사용하는 모든 이점을 얻을 수 있도록 선택 가능한 문자 집합을 제안하고 지지하는 다양한 의견이 있습니다.
어떤 식별자 문자를 허용해야 합니까?
1. bidi 형식 제어 문자는 어떻게 처리해야 합니까?
2. 다른 ID_Continue 문자는 어떻게 처리해야 합니까? 구두점처럼 보이는 문자는 어떻게 처리해야 합니까? UTS #39의 다른 권고 사항은 어떻게 처리해야 합니까? 여러 스크립트가 혼합된 식별자는 어떻게 처리해야 합니까?
NFC와 NFKC 중 어떤 정규화 형식을 사용해야 합니까?
소스 코드는 정규화된 형식이어야 합니까?

Copyright

This document has been placed in the public domain.