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

Python 개선 제안 한국어 번역

PEP 349 – str()이 유니코드 문자열을 반환하도록 허용

Author:
Neil Schemenauer <nas at arctrix.com>
Status:
Rejected
Type:
Standards Track
Created:
02-Aug-2005
Python-Version:
2.5
Post-History:
06-Aug-2005
Resolution:
Python-Dev message

Table of Contents

번역·라이선스 안내

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

초록

이 PEP는 str() 내장 함수를 유니코드 문자열을 반환할 수 있도록 변경할 것을 제안합니다. 이 변경으로 두 문자열 유형 중 어느 유형과도 작동하는 코드를 더 쉽게 작성할 수 있으며, 기존 코드 일부도 유니코드 문자열을 처리할 수 있게 됩니다. C 함수 PyObject_Str()는 변경되지 않고 그대로 유지되며, 대신 PyString_New() 함수가 추가됩니다.

근거

Python에는 이미 일정 기간 동안 유니코드 문자열 유형이 있었지만, 아직 널리 사용되지는 않습니다. 문자열 데이터가 str 인스턴스로 표현된다고 가정하는 Python 코드가 매우 많습니다. Python의 장기적인 계획은 str 유형을 단계적으로 폐지하고 모든 문자열 데이터에 유니코드를 사용하는 것입니다. 분명히 원활한 마이그레이션 경로를 제공해야 합니다.

str 인스턴스용으로 작성된 기존 라이브러리를 업그레이드하여 모든 문자열이 유니코드인 환경에서 작동할 수 있도록 해야 합니다. 모든 필수 라이브러리가 이를 지원할 수 있게 되기 전에는 모든 문자열이 유니코드인 환경으로 전환할 수 없습니다. 라이브러리를 한 번에 업그레이드하는 것은 실행 가능해 보이지 않습니다. 더 현실적인 전략은 현재의 모든 문자열이 str인 환경에서의 동작을 유지하면서 라이브러리 각각이 유니코드 문자열에서 작동할 수 있도록 만드는 것입니다.

첫째, 유니코드 인스턴스를 str 인스턴스로 강제 변환하려 하지 않고 받아들일 수 있는 코드를 작성할 수 있어야 합니다. 이러한 코드를 유니코드 안전 코드라고 부릅시다. 유니코드 안전 라이브러리는 모든 문자열이 유니코드인 환경에서 사용할 수 있습니다.

둘째, str 인스턴스만 제공되었을 때 유니코드 결과를 생성하지 않는 코드를 작성할 수 있어야 합니다. 이러한 코드를 str 안정 코드라고 부릅시다. str 안정 라이브러리는 아직 유니코드 안전이 아닌 라이브러리와 애플리케이션에서 사용할 수 있습니다.

때로는 str 안정성과 유니코드 안전성을 모두 갖춘 코드를 작성하는 일이 간단합니다. 예를 들어 다음 함수는 그대로 작동합니다.:

def appendx(s):
    return s + 'x'

유니코드 유형은 이 작업을 더 쉽게 만들도록 설계되었으므로 이는 그다지 놀라운 일이 아닙니다. 원칙은 str 인스턴스와 유니코드 인스턴스가 만날 때 결과가 유니코드 인스턴스가 된다는 것입니다. 한 가지 주목할 만한 어려움은 코드에서 객체의 문자열 표현을 필요로 하는 경우 발생합니다. 이는 전통적으로 str() 내장 함수를 사용하여 수행하는 작업입니다.

현재의 str()함수를 사용하면 코드가 유니코드 안전이 아니게 됩니다. str()호출을 unicode()호출로 바꾸면 코드가 str 안정이 아니게 됩니다. str()이 유니코드 인스턴스를 반환할 수 있도록 변경하면 이 문제가 해결됩니다. 추가적인 이점으로, 현재 str()을 사용하기 때문에 유니코드 안전이 아닌 일부 코드도 유니코드 안전이 됩니다.

사양

다음은 str() 내장 함수의 Python 구현입니다.:

def str(s):
    """Return a nice string representation of the object.  The
    return value is a str or unicode instance.
    """
    if type(s) is str or type(s) is unicode:
        return s
    r = s.__str__()
    if not isinstance(r, (str, unicode)):
        raise TypeError('__str__ returned non-string')
    return r

다음 함수가 C API에 추가되며 str()내장 함수와 동등하게 동작합니다. (이상적으로는 PyObject_Str라고 불러야 하지만, 해당 함수를 변경하면 막대한 호환성 문제가 발생할 수 있습니다.):

PyObject *PyString_New(PyObject *);

참조 구현은 Sourceforge [1]에서 패치로 제공됩니다.

하위 호환성

일부 코드는 str()가 str 인스턴스를 반환해야 할 수 있습니다. 표준 라이브러리에서는 지금까지 이러한 경우가 하나만 발견되었습니다. email.header_decode()함수는 str 인스턴스를 필요로 하며, email.Header.decode_header() 함수는 인자에 str()를 호출하여 이를 보장하려고 합니다. 코드는 “header = str(header)” 줄을 다음과 같이 변경하는 방식으로 수정되었습니다.:

if isinstance(header, unicode):
    header = header.encode('ascii')

decode_header()는 실제로 문자 문자열이 아니라 바이트 문자열을 대상으로 작동하므로, 이것이 진정한 버그인지는 의문스럽습니다. 여기에 유니코드 인스턴스를 전달하는 코드 자체도 버그가 있는 것으로 간주될 수 있습니다.

대안적 해결책

str()를 변경하는 대신 새로운 내장 함수를 추가할 수 있습니다. 그렇게 해도 하위 호환성 문제는 사실상 전혀 발생하지 않습니다. 그러나 호환성 문제는 드물 것으로 예상되므로, 새로운 내장 함수를 추가하는 것보다 str()를 변경하는 편이 바람직해 보입니다.

str()를 변경하는 대신 basestring 타입을 제안된 동작을 하도록 변경할 수 있습니다. 그러나 이는 추상 베이스 타입으로서는 혼란스러운 동작입니다.

참고 문헌