PEP 3117 – 후위 타입 선언
- Author:
- Georg Brandl <georg at python.org>
- Status:
- Rejected
- Type:
- Standards Track
- Created:
- 01-Apr-2007
- Python-Version:
- 3.0
- Post-History:
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
이 PEP는 Python에 후위 타입 선언 문법을 추가할 것을 제안합니다. 또한 타입과 선언자 사이에 새로운 매핑을 만드는 데 사용하는 새로운 typedef 문을 정의합니다.
이 제안이 채택되면 Python 사용자 경험이 크게 향상될 뿐만 아니라, 다른 프로그래밍 언어 사용자가 Python으로 옮겨 오기를 주저하게 만드는 흠 중 하나도 사라질 것입니다.
근거
Python은 오랫동안 명시적 타입 선언이 없다는 문제로 고통받아 왔습니다. 이 흠은 이 언어가 자신의 Zen에서 벗어나는 몇 안 되는 부분 중 하나로서 Python 이단자들과 PSU 구성원들 사이에서 수많은 논쟁을 불러일으켰으며(몇 가지 예는 [EX1], [EX2] 또는 [EX3]를 참고하십시오), Python이 대규모 엔터프라이즈 환경에서 성공을 거두기 어렵게 만들기도 했습니다.
그러나 이 고통을 끝내고자 한다면, 제대로 된 Python다운 문법을 찾아야 합니다. 타입 선언이 있는 거의 모든 언어에서 타입 선언에는 이러한 특성이 없습니다. 장황해서 타입 하나에 여러 단어가 필요한 경우가 많거나, 이해하기 어렵습니다(예를 들어 어떤 언어는 타입 선언에 dim과 같이 전혀 무관한 [1] 형용사를 사용합니다).
따라서 이 PEP는 타입 선언 도입에 또 하나의 과감한 조치를 결합합니다. 바로 유니코드 문자를 소스 코드의 필수 구성 요소로 도입하는 것으로, 이는 Python이 미래에 대비할 뿐만 아니라 미래를 적극적으로 받아들이는 언어임을 다시 한번 증명할 것입니다.
유니코드를 사용하면 훨씬 적은 문자로 훨씬 많은 것을 표현할 수 있으며, 이는 Zen (“가독성은 중요합니다.”)에 부합합니다. 또한 별도의 타입 선언문이 필요 없어지며, 마지막으로 중요한 점으로 이미 연산자에 유니코드를 사용하는 Perl 6와 Python이 어깨를 나란히 할 수 있게 됩니다. [2]
명세
타입 선언 모드가 작동 중일 때는 각 NAME이 두 부분, 즉 이름과 정확히 한 개의 유니코드 문자인 타입 선언자로 구성되어야 하도록 문법이 변경됩니다.
선언자는 이름의 타입을 고유하게 지정하며, 선언자가 표현식의 왼쪽에 나타나면 이 타입이 강제됩니다. 반환된 타입이 선언된 타입과 일치하지 않으면 InquisitionError 예외가 발생합니다. [3]
또한 함수 호출 결과의 타입도 지정해야 합니다. 호출 결과가 선언된 타입이 아니면 InquisitionError가 발생합니다. 주의: 결과에 대한 선언자를 함수 객체에 대한 선언자와 혼동해서는 안 됩니다(아래 예제를 참고하십시오).
읽기만 하고 대입하지 않는 이름 뒤의 타입 선언자는 엄밀히 말해 필요하지 않지만, 그래도 강제됩니다(Python의 Zen을 참고하십시오: “명시적인 것이 암시적인 것보다 낫습니다.”).
타입과 선언자 사이의 매핑은 고정되어 있지 않습니다. 프로그래머가 완전히 사용자 정의할 수 있지만, 편의를 위해 일부 내장 타입에는 미리 정의된 매핑이 있습니다:
| 타입 | 선언자 |
|---|---|
object |
� (REPLACEMENT CHARACTER) |
int |
ℕ (DOUBLE-STRUCK CAPITAL N) |
float |
℮ (ESTIMATED SYMBOL) |
bool |
✓ (CHECK MARK) |
complex |
ℂ (DOUBLE-STRUCK CAPITAL C) |
str |
✎ (LOWER RIGHT PENCIL) |
unicode |
✒ (BLACK NIB) |
tuple |
⒯ (PARENTHESIZED LATIN SMALL LETTER T) |
list |
♨ (HOT SPRINGS) |
dict |
⧟ (DOUBLE-ENDED MULTIMAP) |
set |
∅ (EMPTY SET) (참고: 가득 찬 집합에도 이 문자를 사용합니다) |
frozenset |
☃ (SNOWMAN) |
datetime |
⌚ (WATCH) |
function |
ƛ (LATIN SMALL LETTER LAMBDA WITH STROKE) |
generator |
⚛ (ATOM SYMBOL) |
Exception |
⌁ (ELECTRIC ARROW) |
None 타입의 선언자는 폭 없는 공백(zero-width space)입니다.
이 문자들은 모든 프로그래머에게 명확하며, 기억하기도 입력하기도 쉬울 것입니다.
유니코드 대체 단위
현대의 세계화된 세상에도 소스 코드에 유니코드를 사용할 수 없거나 사용하고 싶어 하지 않는 구식 반항아들이 여전히 있고, Python은 관대한 언어이므로 이들을 위한 대체 수단을 제공합니다:
유니코드 문자 하나 대신 name${UNICODE NAME OF THE DECLARATOR}$를 입력할 수 있습니다. 예를 들어, 다음 두 함수 정의는 동등합니다:
def fooƛ(xℂ):
return None
그리고
def foo${LATIN SMALL LETTER LAMBDA WITH STROKE}$(x${DOUBLE-STRUCK CAPITAL C}$):
return None${ZERO WIDTH NO-BREAK SPACE}$
이 방식은 여전히 읽기 쉬우며, ASCII 신봉자들도 타입 어노테이션이 달린 Python의 모든 기능을 사용할 수 있게 해 줍니다.
typedef 문
이 새로운 문으로 타입과 선언자 사이의 매핑을 확장할 수 있습니다.
문법은 다음과 같습니다:
typedef_stmt ::= "typedef" expr DECLARATOR
여기서 expr은 타입 객체로 평가됩니다. 편의를 위해, 새 클래스의 경우 typedef 문을 다음과 같이 class 문과 섞어 쓸 수도 있습니다:
typedef class Foo☺(object�):
pass
예시
다음은 표준 os.path.normpath 함수를 타입 선언 문법으로 변환한 것입니다:
def normpathƛ(path✎)✎:
"""Normalize path, eliminating double slashes, etc."""
if path✎ == '':
return '.'
initial_slashes✓ = path✎.startswithƛ('/')✓
# POSIX allows one or two initial slashes, but treats three or more
# as single slash.
if (initial_slashes✓ and
path✎.startswithƛ('//')✓ and not path✎.startswithƛ('///')✓)✓:
initial_slashesℕ = 2
comps♨ = path✎.splitƛ('/')♨
new_comps♨ = []♨
for comp✎ in comps♨:
if comp✎ in ('', '.')⒯:
continue
if (comp✎ != '..' or (not initial_slashesℕ and not new_comps♨)✓ or
(new_comps♨ and new_comps♨[-1]✎ == '..')✓)✓:
new_comps♨.appendƛ(comp✎)
elif new_comps♨:
new_comps♨.popƛ()✎
comps♨ = new_comps♨
path✎ = '/'.join(comps♨)✎
if initial_slashesℕ:
path✎ = '/'*initial_slashesℕ + path✎
return path✎ or '.'
보시다시피, 타입 선언은 표현력을 더해 줄 뿐 아니라 코드를 훨씬 더 전문적으로 보이게 만듭니다.
호환성 문제
타입 선언 모드를 활성화하려면 다음과 같이 작성해야 합니다:
from __future__ import type_declarations
이렇게 하면 소스를 유니코드로 파싱하고 [4], typedef가 키워드가 되며, 모든 할당과 함수 호출에 올바른 타입이 강제됩니다.
거부
신중한 고려와 깊은 자기 성찰, 이를 갈고 옷을 찢는 고뇌 끝에 이 PEP를 거부하기로 결정했습니다.
참고 문헌
감사의 글
내장 타입에 가장 적합하고 기억하기 쉬운 선언자를 찾는 데 도움을 준 Armin Ronacher, Alexander Schremmer, Marek Kubica에게 깊이 감사드립니다.
그 모든 유용한 문자를 유니코드 표준에 포함해 준 유니코드 컨소시엄에도 감사드립니다.
Copyright
This document has been placed in the public domain.