Python 3.0의 새로운 기능¶

저자:: Guido van Rossum

이 기사는 2.6과 비교하여 Python 3.0의 새로운 기능을 설명합니다. “Python 3000” 또는 “Py3K”로도 알려진 Python 3.0은 사상 처음으로 의도적으로 하위 호환성이 없는 파이썬 릴리스입니다. Python 3.0은 2008년 12월 3일에 출시되었습니다. 일반적인 릴리스보다 더 많은 변화가 있으며, 모든 파이썬 사용자에게 중요한 변화도 많습니다. 그럼에도 불구하고 이러한 변화들을 살펴보면 파이썬이 사실 아주 많이 변하지는 않았다는 것을 알 수 있습니다. 대체적으로, 우리는 잘 알려진 불편함과 결점들을 수정하고 오래된 찌꺼기들을 제거하는 데 집중했습니다.

이 기사는 모든 새로운 기능에 대한 완전한 사양을 제공하는 대신 편리한 개요를 제공하는 것을 목표로 합니다. 자세한 내용은 Python 3.0 공식 문서 및 본문에서 언급된 다양한 PEP를 참조하십시오. 특정 기능의 전체 구현과 설계 근거를 이해하려면 일반 문서보다 더 상세한 내용을 담고 있는 경우가 많은 PEP를 참고하십시오. 다만, PEP는 대개 기능이 완전히 구현된 후에 업데이트되지 않는다는 점에 유의하십시오.

시간적 제약으로 인해 이 문서는 충분히 상세하지 않을 수 있습니다. 새로운 릴리스의 경우 늘 그렇듯이 소스 배포판의 Misc/NEWS 파일에 변경된 모든 세부 사항이 자세히 포함되어 있습니다.

흔히 겪는 문제들¶

이 섹션은 Python 2.5에 익숙한 사용자가 실수하기 쉬운 몇 가지 변화를 나열합니다.

print는 함수입니다¶

print 문이 print() 함수로 교체되었으며, 기존 print 문의 특별한 구문 대부분을 키워드 인자로 대체합니다(PEP 3105). 예시:

이전: print "The answer is", 2*2
새로운 것: print("The answer is", 2*2)

이전: print x,           # 끝에 오는 쉼표가 개행을 생략함
새로운 것: print(x, end=" ")  # 개행 대신 공백을 추가함

이전: print              # 개행 출력
새로운 것: print()            # 함수를 호출해야 합니다!

이전: print >>sys.stderr, "fatal error"
새로운 것: print("fatal error", file=sys.stderr)

이전: print (x, y)       # repr((x, y)) 출력
새로운 것: print((x, y))      # print(x, y)와 동일하지 않음!

또한 아이템 사이의 구분자를 사용자 정의할 수 있습니다. 예:

print("There are <", 2**32, "> possibilities!", sep="")

결과:

There are <4294967296> possibilities!

참고:

The print() function doesn’t support the “softspace” feature of the old print statement. For example, in Python 2.x, print "A\n", "B" would write "A\nB\n"; but in Python 3.0, print("A\n", "B") writes "A\n B\n".
처음에는 대화형 모드에서 이전 방식인 print x 를 자주 입력하게 될 것입니다. 이제는 print(x) 라고 입력하도록 손에 익히실 때입니다!
2to3 소스 변환 도구를 사용할 경우 모든 print 문이 자동으로 print() 함수 호출로 변환되므로, 규모가 큰 프로젝트에서는 거의 문제가 되지 않습니다.

리스트 대신 뷰(View)와 이터레이터 사용¶

일반적으로 잘 알려진 일부 API가 더 이상 리스트를 반환하지 않습니다:

dict 메서드인 dict.keys(), dict.items() 및 dict.values() 는 이제 리스트 대신 “뷰”를 반환합니다. 예를 들어, k = d.keys(); k.sort() 는 더 이상 작동하지 않습니다. 대신 k = sorted(d) 를 사용하십시오 (이 방식은 Python 2.5에서도 작동하며 효율성도 동일합니다).
또한, dict.iterkeys(), dict.iteritems() 및 dict.itervalues() 메서드는 더 이상 지원되지 않습니다.
map() 및 filter() 는 이터레이터를 반환합니다. 리스트가 꼭 필요하고 입력 시퀀스의 길이가 모두 동일하다면, 간단한 해결책으로 map() 을 list() 로 감싸는 것입니다(예: list(map(...))). 하지만 더 나은 방법은 종종 리스트 컴프리헨션을 사용하는 것이며(특히 기존 코드가 lambda 를 사용하는 경우), 또는 리스트가 필요 없도록 코드를 재작성하는 것입니다. 특히 함수 실행의 부수 효과(side effects)를 위해 map() 을 호출하는 경우가 까다로운데, 이 경우 올바른 변환 방식은 일반적인 for 루프를 사용하는 것입니다(리스트를 생성하는 것은 낭비이기 때문입니다).

입력 시퀀스의 길이가 서로 다르면, map() 은 가장 짧은 시퀀스가 끝나는 지점에서 중지됩니다. Python 2.x의 map() 과 완전히 호환되게 하려면 시퀀스를 itertools.zip_longest() 로 감싸십시오. 예를 들어 map(func, *sequences) 는 list(map(func, itertools.zip_longest(*sequences))) 가 됩니다.
range`는 이제 임의 크기의 값과도 작동하며 이전의 :func:()!xrange`처럼 동작합니다. 후자는 더 이상 존재하지 않습니다.
zip() 은 이제 이터레이터를 반환합니다.

대소비교(Ordering)¶

Python 3.0은 대소비교 규칙을 단순화했습니다:

The ordering comparison operators (<, <=, >=, >) raise a TypeError exception when the operands don’t have a meaningful natural ordering. Thus, expressions like 1 < '', 0 > None or len <= len are no longer valid, and e.g. None < None raises TypeError instead of returning False. A corollary is that sorting a heterogeneous list no longer makes sense – all the elements must be comparable to each other. Note that this does not apply to the == and != operators: objects of different incomparable types always compare unequal to each other.
sorted() 및 list.sort() 은 더 이상 비교 함수를 제공하는 cmp 인자를 허용하지 않습니다. 대신 key 인수를 사용하십시오. 참고로, key 와 reverse 인자는 이제 “키워드 전용(keyword-only)”입니다.
cmp() 함수는 더 이상 사용되지 않는 것으로 간주되며, __cmp__() 특수 메서드는 지원되지 않습니다. 정렬을 위해 __lt__() 를, 필요에 따라 __eq__() 와 __hash__() 및 다른 리치 비교(rich comparison)를 사용하십시오.(만약 cmp() 기능이 반드시 필요한 경우, (a > b) - (a < b) 표현식을 cmp(a, b) 의 대용으로 사용할 수 있습니다.)

정수¶

PEP 237: 기본적으로 long 이 int 로 이름이 바뀌었습니다. 즉, 내장 정수 타입은 int 하나만 존재하지만, 대부분의 동작은 이전의 long 타입과 동일합니다.
PEP 238: 1/2 와 같은 표현식은 부동소수점을 반환합니다. 버림 동작을 얻으려면 1//2 를 사용하십시오.(후자의 구문은 파이썬 2.2 이후로 수년간 존재해 왔습니다.)
정수 값에 대한 제한이 더 이상 없기 때문에 sys.maxint 상수가 제거되었습니다. 그러나, sys.maxsize`는 모든 실용적인 리스트나 문자열 인덱스보다 큰 정수로 사용될 수 있습니다. 이는 구현의 "자연스러운" 정수 크기에 맞으며 일반적으로 같은 플랫폼의 이전 릴리스에서 :data:!sys.maxint`와 동일합니다 (동일한 빌드 옵션 가정 시).
긴 정수의 repr() 에서 더 이상 끝에 L 이 붙지 않으므로, 해당 문자를 무조건 제거하는 코드는 마지막 자릿수를 삭제하게 됩니다.(대신 str() 을 사용하십시오.)
8진수 리터럴은 더 이상 0720 형태가 아니며, 대신 0o720 을 사용하십시오.

유니코드 vs 8비트 대신, 텍스트 대 데이터¶

바이너리 데이터와 유니코드에 대해 알고 있던 모든 것이 바뀌었습니다.

Python 3.0은 유니코드 문자열과 8비트 문자열 대신 텍스트 와 (바이너리) 데이터 의 개념을 사용합니다. 모든 텍스트는 유니코드이며, 단, 인코딩된 유니코드는 바이너리 데이터로 표현됩니다. 텍스트를 저장하는 데 사용되는 타입은 str 이고, 데이터를 저장하는 데 사용되는 타입은 bytes 입니다. 2.x 상황과 가장 큰 차이점은 Python 3.0에서 텍스트와 데이터를 혼합하려고 시도하면 TypeError 가 발생한다는 것이며, Python 2.x에서 유니코드와 8비트 문자열을 혼합할 경우 8비트 문자열이 우연히 7비트(ASCII) 바이트만 포함하고 있다면 작동했지만, ASCII 이외의 값이 포함되어 있으면 UnicodeDecodeError 가 발생했습니다. 이러한 값 특정 동작은 수년 동안 많은 문제를 야기해 왔습니다.
이러한 철학적 변화의 결과로 유니코드, 인코딩 또는 바이너리 데이터를 사용하는 거의 모든 코드를 수정해야 할 가능성이 높습니다. 2.x 환경에서는 인코딩된 텍스트와 인코딩되지 않은 텍스트를 혼합하는 것과 관련된 수많은 버그가 있었기 때문에 이 변화는 긍정적인 것입니다. Python 2.x에서 대비하려면 모든 인코딩되지 않은 텍스트에 unicode 를 사용하고, 바이너리 또는 인코딩된 데이터에만 str 을 사용하기 시작하십시오. 그러면 2to3 도구가 대부분의 작업을 처리해 줄 것입니다.
더 이상 유니코드 텍스트에 u"..." 리터럴을 사용할 수 없습니다. 그러나 바이너리 데이터에는 b"..." 리터럴을 사용해야 합니다.
str 과 bytes 타입은 혼합될 수 없으므로 항상 명시적으로 변환해야 합니다. str 을 bytes 로 변환하려면 str.encode() 를 사용하고, bytes 를 str 로 변환하려면 bytes.decode() 를 사용하십시오. 또한 각각 bytes(s, encoding=...) 및 str(b, encoding=erna=...) 도 사용할 수 있습니다.
str 과 마찬가지로 bytes 타입은 불변(immutable)입니다. 버퍼링된 바이너리 데이터를 저장하기 위한 별도의 가변(mutable) 타입으로 bytearray 가 있습니다. bytes 를 수용하는 거의 모든 API는 bytearray 도 수용합니다. 가변 API는 collections.MutableSequence 를 기반으로 합니다.
raw 문자열 리터럴의 모든 백슬래시는 그대로 해석됩니다. 이는 raw 문자열 내의 '\U' 및 '\u' 이스케이프가 특별하게 취급되지 않음을 의미합니다. 예를 들어, r'\u20ac' 는 Python 3.0에서 6개의 문자로 구성된 문자열인 반면, 2.6에서는 ur'\u20ac' 이 단일
내장된 basestring 추상 타입이 제거되었습니다. 대신 str 을 사용하십시오. str 과 bytes 타입은 공통의 기본 클래스를 가질 만큼 기능이 겹치지 않습니다. 2to3 도구(아래 참조)가 모든 basestring 발생 사례를 str 로 교체합니다.
텍스트 파일로 열린 파일(여전히 open`의 기본 모드)은 항상 메모리 내의 문자열과 디스크상의 바이트를 매핑하기 위해 인코딩을 사용합니다. 바이너리 파일(모드 인수에 ``b``를 넣어 엽니다)은 항상 메모리에서 바이트를 사용합니다. 이는 파일이 잘못된 모드나 인코딩으로 열릴 경우, 오류 없이 잘못된 데이터를 생성하는 대신 I/O 작업이 명확하게 실패할 가능성이 높음을 의미합니다. 또한 유닉스 사용자도 파일을 열 때 올바른 모드(텍스트 또는 바이너리)를 명시해야 함을 의미합니다. 플랫폼에 따른 기본 인코딩이 있으며, 유닉스계 플랫폼에서는 ``LANG`() 환경 변수(때로는 다른 플랫폼 특정 로캘 관련 환경 변수 포함)로 설정할 수 있습니다. 많은 경우(모두는 아님) 시스템 기본값은 UTF-8이지만, 이 기본값에 의존해서는 안 됩니다. 순수 ASCII를 넘어서는 텍스트를 읽거나 쓰는 모든 애플리케이션은 인코딩을 재정의하는 방법을 갖추어야 합니다. 더 이상 codecs 모듈의 인코딩 인식 스트림을 사용할 필요가 없습니다.
sys.stdin, sys.stdout, 그리고 sys.stderr 의 초기값은 이제 유니코드 전용 텍스트 파일입니다(즉, io.TextIOBase 의 인스턴스입니다). 이러한 스트림으로 바이트 데이터를 읽고 쓰려면 해당 객체의 io.TextIOBase.buffer 속성을 사용해야 합니다.
파일 이름은 API에 전달되거나 반환될 때 (유니코드) 문자열로 처리됩니다. 일부 플랫폼에서는 파일 이름이 임의의 바이트 문자열이기 때문에 이는 플랫폼 특유의 문제를 야기할 수 있습니다. (반대로 윈도우에서는 파일 이름이 네이티브하게 유니코드로 저장됩니다.) 해결책으로, 파일 이름을 인자로 받는 대부분의 API(예: open() 및 os 모듈의 많은 함수)는 문자열뿐만 아니라 bytes 객체도 수용하며, 일부 API는 bytes 반환 값을 요청하는 방법을 제공합니다. 따라서 os.listdir() 은 인자가 bytes 인스턴스인 경우 bytes 인스턴스의 리스트를 반환하고, os.getcwdb() 는 현재 작업 디렉터리를 bytes 인스턴스로 반환합니다. 주의할 점은 os.listdir() 이 문자열 리스트를 반환할 때 제대로 디코딩되지 않는 파일 이름은 UnicodeError 를 발생시키는 대신 생략됩니다.
os.environ 및 sys.argv`와 같은 일부 시스템 API는 시스템이 제공하는 바이트가 기본 인코딩으로 해석될 수 없을 때 문제를 일으킬 수 있습니다. ``LANG` 변수를 설정하고 프로그램을 다시 실행하는 것이 최선의 방법일 것입니다.
PEP 3138: 문자열의 repr() 이 더 이상 비(non)-ASCII 문자를 이스케이프하지 않습니다. 다만 유니코드 표준에서 인쇄 불가능한 상태인 제어 문자 및 코드 포인트는 여전히 이스케이프됩니다.
PEP 3120: 기본 소스 인코딩이 이제 UTF-8입니다.
PEP 3131: 식별자에 비(non)-ASCII 문자가 허용됩니다. (그러나 표준 라이브러리는 주석 내의 기여자 이름을 제외하고 여전히 ASCII 전용입니다.)
StringIO 및 cStringIO 모듈이 제거되었습니다. 대신 io 모듈을 임포트하여 텍스트에는 io.StringIO 를, 데이터에는 io.BytesIO 를 사용하십시오.
Python 3.0을 위해 업데이트된 유니코드 HOWTO 도 참조하십시오.

문법 변경 개요¶

이 섹션에서는 Python 3.0의 모든 구문적 변화에 대한 간략한 개요를 제공합니다.

새 문법¶

PEP 3107: 함수 인수 및 반환 값 어노테이션. 이는 함수의 매개변수와 반환 값을 주석 처리하는 표준화된 방법을 제공합니다. 이러한 어노테이션은 __annotations__ 속성을 사용하여 런타임에 조사(introspect)할 수 있다는 점 외에 별도의 의미론적 기능이 없습니다. 의도는 메타클래스, 데코레이터 또는 프레임워크를 통한 실험을 장려하는 것입니다.
PEP 3102: 키워드 전용 인자. 매개변수 목록에서 *args 난 후에 오는 이름 지정 매개변수는 호출 시 반드시 키워드 문법을 사용하여 지정해야 합니다. 또한, 변수 길이의 인자 목록을 허용하지 않지만 키워드 전용 인자는 가지고 있음을 나타내기 위해 매개변수 목록에 빈 * 를 사용할 수도 있습니다.
클래스 정의에서 기본 클래스 목록 뒤에 키워드 인자를 사용할 수 있습니다. 이는 메타클래스를 지정하기 위한 새로운 관례(다음 섹션 참조)에 사용되지만, 메타클래스가 이를 지원하는 경우 다른 목적을 위해서도 사용될 수 있습니다.
PEP 3104: nonlocal 문. nonlocal x 를 사용하면 이제 외부(그러나 전역은 아닌) 범위에 있는 변수에 직접 할당할 수 있습니다. nonlocal 은 새로운 예약어입니다.
PEP 3132: 확장 이터러블 언패킹. 이제 a, b, *rest = some_sequence``와 같은 표현을 작성할 수 있습니다. 또한 ``*rest, a = stuff``도 가능합니다. ``rest 객체는 항상 (비어 있을 수도 있는) 리스트이며, 우변은 모든 종류의 이터러블이 될 수 있습니다. 예제:
```
(a, *rest, b) = range(5)
```
이것은 a 를 0 으로, b 를 4 로, rest 를 [1, 2, 3] 으로 설정합니다.
딕셔너리 컴프리헨션: {k: v for k, v in stuff} 는 dict(stuff) 와 동일한 의미를 갖지만 더 유연합니다. (이것으로 PEP 274 가 입증되었습니다. :-)
셋 리터럴, 예: {1, 2}. {} 는 빈 딕셔너리이므로 빈 집합을 만들려면 set() 를 사용하십시오. 세트 컴프리헨션도 지원됩니다. 예를 들어, {x for x in stuff} 는 set(stuff) 와 동일한 의미를 가지지만 더 유연합니다.
새로운 8진수 리터럴, 예: 0o720 (이미 2.6에 도입됨). 이전의 8진수 리터럴(0720)은 제거되었습니다.
새로운 이진수 리터럴(예: 0b1010, 이미 2.6에 도입됨)과 그에 대응하는 새로운 내장 함수인 bin() 이 추가되었습니다.
앞에 b 또는 B 가 붙는 바이트 리터럴이 도입되었으며, 이에 대응하는 새로운 내장 함수인 bytes() 가 추가되었습니다.

변경된 문법¶

PEP 3109 및 PEP 3134: 새로운 raise 문 구문: raise [expr [from expr]]. 아래를 참조하십시오.
as 와 with 가 이제 예약어입니다. (실제로는 2.6부터 그러했습니다.)
True, False, 그리고 None 은 예약어입니다. (2.6에서 이미 None 에 대한 제한이 부분적으로 시행되었습니다.)
except exc, var 에서 except exc as var 로 변경되었습니다. PEP 3110 을 참조하십시오.
PEP 3115: 새로운 메타클래스 문법. 다음의 경우 대신:
```
class C:
    __metaclass__ = M
    ...
```
이제 반드시 ~을(를) 사용해야 합니다:
```
class C(metaclass=M):
    ...
```
모듈 전역 변수인 __metaclass__ 은 더 이상 지원되지 않습니다. (모든 클래스를 object 로부터 상속받지 않고도 새 스타일의 클래스로 기본 설정하기 쉽게 만들기 위한 임시 방편이었습니다.)
리스트 컴프리헨션은 더 이상 [... for var in item1, item2, ...] 구문을 지원하지 않습니다. 대신 [... for var in (item1, item2, ...)] 을 사용하십시오. 또한 리스트 컴프리헨션은 서로 다른 의미론을 가짐에 유의하십시오. 리스트 컴프리헨션은 list() 생성자 내의 제너레이터 표현식에 대한 구문적 설탕(syntactic sugar)에 더 가깝고, 특히 루프 제어 변수가 주변 범위로 누출되지 않습니다.
생략 부호 (ellipses)(...)는 어디서나 원자적 표현으로 사용될 수 있습니다. (이전에는 슬라이스에서만 허용되었습니다.) 또한, 이제 반드시 ... 로 표기되어야 합니다. (이전에는 문법의 우연한 결과로 . . . 로도 표성할 수 있었습니다.))

제거된 문법¶

PEP 3113: 튜플 매개변수 언패킹이 제거되었습니다. 더 이상 def foo(a, (b, c)): ... 와 같이 쓸 수 없습니다. 대신 def foo(a, b_c): b, c = b_c 를 사용하십시오.
백틱을 제거했습니다(대신 repr() 을 사용하십시오).
<> 를 제거했습니다(대신 != 를 사용하십시오).
키워드가 제거되었습니다: exec() 은 더 이상 키워드가 아니며, 함수로 유지됩니다. (다행히도 함수 구문 또한 2.x에서 허용되었습니다.) 또한 exec() 이 더 이상 스트림 인수를 받지 않음을 유의하십시오; exec(f) 대신 exec(f.read()) 를 사용할 수 있습니다.
정수 리터럴에서 뒤에 붙는 l 또는 L 을 더 이상 지원하지 않습니다.
문자열 리터럴에서 앞에 붙는 u 또는 U 를 더 이상 지원하지 않습니다.
from module import * 구문은 더 이상 함수 내부가 아닌 모듈 수준에서만 허용됩니다.
상대 임포트를 위한 유일하게 허용되는 구문은 from .[module] import name`입니다. `.``으로 시작하지 않는 모든 import 형태는 절대 임포트로 해석됩니다. (PEP 328)
고전적(classic) 클래스가 사라졌습니다.

Python 2.6에 이미 포함된 변경 사항¶

많은 사용자가 Python 2.5에서 바로 Python 3.0으로 넘어오는 경우가 많으므로, 이 섹션에서는 원래 Python 3.0을 위해 설계되었으나 Python 2.6에 백포트된 새로운 기능들을 상기시켜 줍니다. 더 자세한 설명은 Python 2.6의 새로운 기능 의 해당 섹션을 참조하십시오.

PEP 343: ‘with’ 문. 이제 with 문은 표준 기능이므로 더 이상 __future__ 에서 임포트할 필요가 없습니다. 또한 컨텍스트 관리자 작성하기 및 contextlib 모듈 도 확인해 보시기 바랍니다.
PEP 366: 메인 모듈로부터의 명시적 상대 임포트. 이 기능은 참조하는 모듈이 패키지 내에 있을 때 -m 옵션의 유용성을 높여줍니다.
PEP 370: 사용자별 site-packages 디렉터리.
PEP 371: multiprocessing 패키지.
PEP 3101: 고급 문자열 포매팅. 참고: 2.6 버전의 설명에서는 8비트 및 Unicode 문자열 모두에 대해 format() 메서드를 언급합니다. 3.0에서는 오직 str 타입(Unicode를 지원하는 텍스트 문자열)만 이 메서드를 지원하며, bytes 타입은 지원하지 않습니다. 향후 이를 문자열 포매팅을 위한 유일한 API로 만들 계획이며, Python 3.1부터 % 연산자를 폐지하기 시작할 예정입니다.
PEP 3105: print As a Function. 이제 이 기능은 표준 기능으로, 더 이상 __future__ 에서 임포트할 필요가 없습니다. 자세한 내용은 위에서 설명하였습니다.
PEP 3110: Exception-Handling Changes. 이제 except exc as var 구문이 표준이며, except exc, var*는 더 이상 지원되지 않습니다. (물론 :keyword:`!as` *var 부분은 여전히 선택 사항입니다.)
PEP 3112: Byte Literals. b"..." 문자열 리터럴 표기법(및 b'...', b"""...""", br"..." 와 같은 변형)은 이제 bytes 타입의 리터럴을 생성합니다.
PEP 3116: 새로운 I/O 라이브러리. 이제 파일 I/O를 수행하는 표준 방식은 io 모듈입니다. 내장된 open() 함수는 이제 io.open() 의 별칭이며, encoding, errors, newline, closefd 라는 추가 키워드 인수를 가집니다. 또한 유효하지 않은 mode 인자가 입력될 경우 이제 IOError 가 아닌 ValueError 를 발생시킨다는 점에 유의하십시오. 텍스트 파일 객체의 기반이 되는 바이너리 파일 객체는 f.buffer 로 접근할 수 있습니다(단, 텍스트 객체는 인코딩 및 디코딩 속도를 높이기 위해 자체 버퍼를 유지하므로 주의가 필요합니다).
PEP 3118: 개정된 버퍼 프로토콜. 기존 내장 기능인 buffer() 는 이제 완전히 삭제되었습니다. 새로운 내장 기능인 memoryview() 가 (거의) 동일한 기능을 제공합니다.
PEP 3119: 추상 베이스 클래스. 이제 abc 모듈과 collections 모듈에서 정의된 ABC가 언어 내에서 다소 더 중요한 역할을 수행하며, dict 및 list 와 같은 내장 컬렉션 타입은 각각 collections.MutableMapping 및 collections.MutableSequence ABC를 준수합니다.
PEP 3127: 정수 리터럴 지원 및 구문. 앞서 언급한 바와 같이, 새로운 8진수 리터럴 표기법만 지원되며 바이너리 리터럴이 추가되었습니다.
PEP 3129: 클래스 데코레이터.
PEP 3141: 숫자를 위한 타입 계층 구조. numbers 모듈은 ABC를 활용한 또 다른 사례로, 파이썬의 “수치 계층(numeric tower)”을 정의합니다. 또한 numbers.Rational 을 구현하는 새로운 fractions 모듈도 확인해 보십시오.

라이브러리 변경 사항¶

시간 관계상 이 문서는 표준 라이브러리의 방대한 변경 사항을 모두 다루지는 못합니다. 주요 변경 사항에 대한 참고 자료는 PEP 3108 을 확인하십시오. 다음은 핵심 요약입니다.

많은 오래된 모듈이 제거되었습니다. gopherlib (더 이상 사용되지 않음) 및 md5 (모듈 hashlib 으로 대체됨)와 같은 일부 모듈은 이미 PEP 4 에서 폐지되었습니다. 다른 것들은 Irix, BeOS, Mac OS 9 등 다양한 플랫폼 지원이 중단됨에 따라 제거되었습니다(참고: PEP 11). 또한 일부 모듈은 사용 빈도가 낮거나 더 나은 대체재가 존재하여 파이썬 3.0에서 제거 대상으로 선정되었습니다. 전체 목록은 PEP 3108 을 참조하십시오.
bsddb3 패키지는 테스트 불안정성과 Berkeley DB의 출시 일정으로 인해 핵심 개발자들에게 상당한 부담이 되는 것으로 판단되어 표준 라이브러리에서 제거되었습니다. 하지만 이 패키지는 여전히 유지되고 있으며, https://www.jcea.es/programacion/pybsddb.htm에서 외부 관리가 이루어지고 있습니다.

일부 모듈은 이전 이름이 PEP 8 을 준수하지 않거나 기타 여러 이유로 이름이 변경되었습니다. 목록은 다음과 같습니다.

기존 이름	새 이름
_winreg	winreg
ConfigParser	configparser
copy_reg	copyreg
Queue	queue
SocketServer	socketserver
markupbase	_markupbase
repr	reprlib
test.test_support	test.support

Python 2.x에서 흔히 쓰이는 패턴 중 하나는 모듈을 순수 파이썬으로 구현하고, 선택적으로 C 확장 기능을 통해 가속화된 버전을 제공하는 것입니다. 예를 들어 pickle`과 :mod:!cPickle`이 이에 해당합니다. 이 방식은 사용자가 매번 가속 버전의 임포트 여부를 확인하고 실패 시 순수 파이썬 버전으로 폴백(fallback)해야 하는 부담을 줍니다. Python 3.0에서는 이러한 가속 버전을 순수 파이썬 버전의 구현 세부 사항으로 간주합니다. 따라서 사용자는 항상 표준 버전을 임포트해야 하며, 표준 버전은 가속 버전 임포트를 시도한 후 실패하면 순수 파이썬 버전으로 폴백합니다. pickle / cPickle 쌍이 이러한 처리를 거쳤으며, profile 모듈도 3.1에서 포함될 예정입니다. 또한 StringIO 모듈은 io 모듈의 클래스로 변환되었습니다.
관련된 일부 모듈이 패키지로 그룹화되었으며, 일반적으로 서브모듈 이름이 단순화되었습니다. 결과로 생성된 새로운 패키지는 다음과 같습니다.
- dbm (anydbm, dbhash, dbm, dumbdbm, gdbm, whichdb).
- html (HTMLParser, htmlentitydefs).
- http (httplib, BaseHTTPServer, CGIHTTPServer, SimpleHTTPServer, Cookie, cookielib).
- tkinter (turtle 을 제외한 모든 Tkinter 관련 모듈). turtle 의 주요 사용자층은 tkinter 에 대해 크게 신경 쓰지 않습니다. 또한 Python 2.6부터 turtle 의 기능이 크게 향상되었음을 참고하십시오.
- urllib (urllib, urllib2, urlparse, robotparse).
- xmlrpc (xmlrpclib, DocXMLRPCServer, SimpleXMLRPCServer).

PEP 3108 에서 다루지 않은 기타 표준 라이브러리 모듈의 변경 사항:

sets 가 제거되었습니다. 내장된 set() 클래스를 사용하십시오.
sys 모듈 정리: sys.exitfunc(), sys.exc_clear(), sys.exc_type, sys.exc_value, sys.exc_traceback 이 제거되었습니다. (sys.last_type 등은 유지됩니다.)
array.array 타입 정리: read() 및 write() 메서드가 제거되었습니다. 대신 fromfile() 과 tofile() 을 사용하십시오. 또한, 배열에 대한 'c' 타입 코드가 제거되었으므로 바이트는 'b' 를, 유니코드 문자는 'u' 를 사용하십시오.
operator 모듈 정리: sequenceIncludes() 및 isCallable() 가 제거되었습니다.
thread 모듈 정리: acquire_lock() 및 release_lock() 이 제거되었습니다. 대신 acquire() 및 release() 를 사용하십시오.
random 모듈 정리: jumpahead() API가 제거되었습니다.
new 모듈이 제거되었습니다.
os.tmpnam(), os.tempnam(), os.tmpfile() 함수들이 제거되었으며, 대신 tempfile 모듈을 사용하도록 변경되었습니다.
tokenize 모듈이 바이트(bytes)와 함께 작동하도록 변경되었습니다. 주요 진입점이 generate_tokens 에서 tokenize.tokenize() 로 변경되었습니다.
string.letters 및 관련 항목(string.lowercase, string.uppercase)이 제거되었습니다. 대신 string.ascii_letters 등을 사용하십시오. (제거 사유는 string.letters 등이 로캘에 따라 다르게 동작했기 때문이며, 이름이 직관적인 전역 “상수”가 이처럼 동작하는 것은 바람직하지 않기 때문입니다.)
__builtin__ 모듈이 builtins 로 이름이 변경되었습니다(언더스코어 제거 및 ‘s’ 추가). 대부분의 글로벌 네임스페이스에서 발견되는 __builtins__ 변수는 그대로 유지됩니다. 내장 기능을 수정하려면 __builtins__ 가 아닌 builtins 를 사용해야 합니다!

PEP 3101: 문자열 포매팅을 위한 새로운 접근 방식¶

내장 문자열 포매팅 연산을 위한 새로운 시스템이 기존의 % 스트링 포매팅 연산자를 대체합니다. (그러나 % 연산자는 여전히 지원되며, Python 3.1에서 폐지되고 이후에 언어에서 제거될 예정입니다.) 자세한 내용은 PEP 3101 을 참조하십시오.

예외 관련 변경 사항¶

예외 발생 및 포착을 위한 API가 정리되었으며 새로운 강력한 기능들이 추가되었습니다.

PEP 352: 모든 예외는 (직접 또는 간접적으로) BaseException 으로부터 파생되어야 합니다. 이는 예외 계층 구조의 최상위 루트입니다. 권고 사항으로서 새롭지는 않으나, BaseException 을 상속받아야 한다는 요건 은 새롭게 추가된 것입니다. (Python 2.6에서는 여전히 일반 클래스를 발생시킬 수 있었으며 포착할 대상에 대한 제한이 없었습니다.) 그 결과로, 문자열 예외는 마침내 완전히 사라지게 되었습니다.
거의 모든 예출은 실제로는 Exception 에서 파생되어야 합니다. BaseException 은 오직 최고 수준에서 처리되어야 하는 예외(예: SystemExit 또는 KeyboardInterrupt)를 위한 기본 클래스로만 사용되어야 합니다. 후자의 범주를 제외한 모든 예외를 처리하기 위해 권장되는 관례는 except Exception 을 사용하는 것입니다.
StandardError 가 제거되었습니다.
예외는 더 이상 시퀀스로 동작하지 않습니다. 대신 args 속성을 사용하십시오.
PEP 3109: 예외 발생. 이제 raise Exception, args 대신 raise Exception(args) 를 사용해야 합니다. 또한 더 이상 트레이스백을 명시적으로 지정할 수 없습니다. 만약 이것이 반드시 필요한 경우, __traceback__ 속성에 직접 할당하면 됩니다(아래 참조).
PEP 3110: 예외 포착. 이제 except SomeException, variable 대신 except SomeException as variable 를 사용해야 합니다. 또한, except 블록을 벗어날 때 변수 가 명시적으로 삭제됩니다.
PEP 3134: 예외 체이닝. 여기에는 암시적 체이닝과 명시적 체이닝의 두 가지 사례가 있습니다. 암시적 체이닝은 except 또는 finally 처리 블록 내에서 예외가 발생할 때 발생합니다. 이는 보통 처리 블록 내의 버그로 인해 발생하며, 이를 보조(secondary) 예산이라고 부릅니다. 이 경우 원래 예외(처리 중이던 예외)는 보조 예매의 __context__ 속성으로 저장됩니다. 명시적 체이닝은 다음 구문으로 호출됩니다:
```
raise SecondaryException() from primary_exception
```
(여기서 primary_exception 은 예외 객체를 생성하는 모든 표현식으로, 대개 이전에 포획된 예외를 의미합니다). 이 경우 기본 예외는 보조 예외의 __cause__ 어트리뷰트에 저장됩니다. 처리되지 않은 예외가 발생할 때 인쇄되는 트레이스백은 __cause__ 및 __context__ 어트리뷰트 체인을 훑으며 체인의 각 구성 요소에 대해 별도의 트레이스백을 인쇄하고, 맨 위에 기본 예약을 배치합니다. (Java 사용자는 이 동작을 익숙하게 느낄 수 있습니다.)
PEP 3134: Exception objects now store their traceback as the __traceback__ attribute. This means that an exception object now contains all the information pertaining to an exception, and there are fewer reasons to use sys.exc_info() (though the latter is not removed).
Windows가 확장 모듈을 로드하는 데 실패할 때 발생하는 몇 가지 예외 메시지가 개선되었습니다. 예를 들어, error code 193 이 이제 %1 is not a valid Win32 application 으로 표시됩니다. 문자열은 이제 비영어권 로케어를 지원합니다.

기타 기타 변경 사항¶

연산자 및 특수 메서드¶

!= 는 이제 == 가 NotImplemented 를 반환하지 않는 한, == 의 반대 값을 반환합니다.
언어에서 “unbound methods” 개념이 제거되었습니다. 클래스 어트리뷰트로 메서드를 참조하면 이제 일반 함수 객체를 받게 됩니다.
__getslice__(), __setslice__(), __delslice__() 가 제거되었습니다. 이제 a[i:j] 구문은 a.__getitem__(slice(i, j)) 로 변환됩니다(각각 할당 또는 삭제 대상으로 사용될 때는 __setitem__() 또는 __delitem__() 으로 변환됨).
PEP 3114: 표준 next() 메서드가 __next__() 로 이름이 변경되었습니다.
The __oct__() and __hex__() special methods are removed – oct() and hex() use __index__() now to convert the argument to an integer.
__members__ 및 __methods__ 에 대한 지원이 제거되었습니다.
func_X 라는 이름의 함수 어트리뷰트가 __X__ 형식을 사용하도록 이름이 변경되어, 해당 이름을 사용자 정의 어트리뷰트용으로 비워두었습니다. 구체적으로, func_closure, func_code, func_defaults, func_dict, func_doc, func_globals, func_name 은 각각 __closure__, __code__, __defaults__, __dict__, __doc__, __globals__, __name__ 로 변경되었습니다.
__nonzero__() 는 이제 __bool__() 입니다.

내장 기능¶

PEP 3135: 새로운 super(). 이제 인자 없이 super() 를 호출할 수 있으며(이것이 class 문 내에 정의된 일반 인스턴스 메서드라고 가정할 때), 올바른 클래스와 인스턴스가 자동으로 선택됩니다. 인수가 있는 경우, super() 의 동작은 변하지 않습니다.
PEP 3111: raw_input() 이 input() 으로 이름이 변경되었습니다. 즉, 새로운 input() 함수는 sys.stdin 에서 한 줄을 읽어 끝에 오는 줄바꿈을 제거하고 반환합니다. 입력이 조기에 종료되면 EOFError 를 발생시킵니다. 이전의 input() 동작을 얻으려면 eval(input()) 을 사용하십시오.
객체에서 __next__() 메서드를 호출하기 위한 새로운 내장 함수 next() 가 추가되었습니다.
round() 함수의 반올림 전략과 반환 타입이 변경되었습니다. 정확히 절반인 경우 이제 0에서 멀어지는 방향이 아니라 가장 가까운 짝수 결과로 반올림됩니다. (예를 들어, round(2.5) 는 이제 3 대신 2 를 반환합니다.) round(x[, n]) 은 이제 항상 부동소수점을 반환하는 대신 x.__round__([n]) 에 위임합니다. 단일 인자로 호출될 때는 일반적으로 정수를 반환하고, 두 개의 인자로 호출될 때는 x 와 동일한 유형의 값을 반환합니다.
intern() 이 sys.intern() 으로 이동되었습니다.
apply() 가 제거되었습니다. apply(f, args) 대신 f(*args) 를 사용하십시오.
callable() 이 제거되었습니다. callable(f) 대신 isinstance(f, collections.Callable) 를 사용할 수 있습니다. operator.isCallable() 함수도 삭제되었습니다.
coerce() 가 제거되었습니다. 클래식 클래스가 사라짐에 따라 이 함수는 더 이상 목적이 없습니다.
execfile() 이 제거되었습니다. execfile(fn) 대신 exec(open(fn).read()) 를 사용하십시오.
file 타입이 제거되었습니다. 대신 open() 을 사용하십시오. 이제 io 모듈에서 open이 여러 종류의 스트림을 반환할 수 있습니다.
reduce() 가 제거되었습니다. 정말로 필요한 경우에만 functools.reduce() 를 사용하십시오. 그러나 대부분의 경우 명시적인 for 루프가 더 읽기 좋습니다.
reload`이 제거되었습니다. :func:()!imp.reload`을 사용하십시오.
제거됨. dict.has_key() 대신 in 연산자를 사용하십시오.

빌드 및 C API 변경사항¶

시간 제약으로 인해, 여기는 C API 변경 사항에 대한 매우 불완전한 목록입니다.

Mac OS 9, BeOS, RISCOS, Irix, Tru64를 포함하되 이에 국한되지 않는 여러 플랫폼에 대한 지원이 중단되었습니다.
PEP 3118: 새로운 Buffer API.
PEP 3121: 확장 모듈 초기화 및 마무리.
PEP 3123: PyObject_HEAD 를 표준 C에 부합하도록 수정.
제한된 실행(restricted execution)에 대한 C API 지원이 더 이상 없습니다.
PyNumber_Coerce(), PyNumber_CoerceEx(), PyMember_Get(), 그리고 PyMember_Set() C API가 제거되었습니다.
새로운 C API PyImport_ImportModuleNoBlock() 은 PyImport_ImportModule() 과 유사하게 작동하지만, 임포트 잠금(import lock)에서 대기하지 않고 대신 오류를 반환합니다.
C 레벨의 불리언 변환 슬롯 및 메서드의 이름이 변경되었습니다. nb_nonzero 가 이제 nb_bool 입니다.
C API에서 METH_OLDARGS 및 WITH_CYCLE_GC 를 제거했습니다.

성능¶

3.0 일반화의 결과로 파이썬 3.0은 pystone 벤치마크를 파이썬 2.5보다 약 10% 느리게 실행합니다. 가장 큰 원인은 소수 정수에 대한 특수 처리 제거일 가능성이 높습니다. 개선의 여지는 있지만, 이는 3.0 출시 이후에 이루어질 것입니다!

파이썬 3.0으로 이식하기¶

기존 파이썬 2.5 또는 2.6 소스 코드를 파이썬 3.0으로 이식하기 위한 최선의 전략은 다음과 같습니다:

(전제 조건:) 우수한 테스트 커버리지에서 시작하십시오.
파이썬 2.6으로 이식하십시오. 이는 파이썬 2.x에서 파이썬 2.(x+1)로 이식하는 것보다 더 많은 작업이 필요하지 않을 것입니다. 모든 테스트가 통과하는지 확인하십시오.
(여전히 2.6을 사용하는 경우:) -3 명령줄 스위치를 켜십시오. 이 설정은 3.0에서 제거되거나 변경될 기능에 대한 경고를 활성화합니다. 테스트 스위트를 다시 실행하고, 더 이상 경고가 남지 않고 모든 테스트가 통과할 때까지 경고가 발생하는 코드를 수정하십시오.
소스 코드 트리 전체에 걸쳐 2to3 소스 변환기를 실행하십시오. 번역 결과를 파이썬 3.0에서 실행하십시오. 남아 있는 문제를 수동으로 수정하고, 모든 테스트가 다시 통과할 때까지 문제들을 해결하십시오.

파이썬 2.6과 3.0 모두에서 수정 없이 실행되는 소스 코드를 작성하는 것을 권장하지 않습니다. 이를 위해서는 print 문이나 메타클래스 등을 피해야 하는 매우 복잡한 코딩 스타일을 사용해야 하기 때문입니다. 파이썬 2.6과 파이썬 3.0 모두를 지원해야 하는 라이브러리를 관리하는 경우, 가장 좋은 방법은 3.0 버전의 소스 코드를 수정하는 대신 위의 3단계에서 2.6 버전의 소스 코드를 수정하고 2to3 변환기를 다시 실행하는 것입니다.

C 확장 모듈을 파이썬 3.0으로 이식하려면 확장 모듈을 파이썬 3에 이식하기 를 참조하십시오.