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

Python 개선 제안 한국어 번역

PEP 296 – bytes 객체 타입 추가

Author:
Scott Gilbert <xscottg at yahoo.com>
Status:
Withdrawn
Type:
Standards Track
Created:
12-Jul-2002
Python-Version:
2.3
Post-History:

Table of Contents

번역·라이선스 안내

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

알림

이 PEP는 PEP 358로 대체되어 작성자가 철회했습니다.

초록

이 PEP는 ‘bytes’라는 새로운 표준 타입과 내장 생성자를 만들 것을 제안합니다. bytes 객체는 효율적으로 저장되는 바이트 배열로, 유사한 여러 구현과 구별되는 몇 가지 추가 특성을 가집니다.

근거

Python에는 현재 이 제안의 bytes 객체와 비슷한 것을 구현하는 객체가 많이 있습니다. 예를 들어 표준 문자열, 버퍼, 배열, mmap 객체는 모두 어떤 면에서 bytes 객체와 매우 비슷합니다. 또한 몇몇 주요 서드파티 확장도 비슷한 요구를 충족하기 위해 유사한 객체를 만들었습니다. 안타깝게도 이 객체들은 각각 적용 범위가 너무 좁고, 더 넓은 범주의 문제에 적용하는 데 필요한 핵심 기능이 빠져 있습니다.

명세

bytes 객체는 다음과 같은 중요한 특성을 가집니다:

  1. 표준 C 타입 “unsigned char”를 통한 효율적인 하부 배열 저장소. 이를 통해 할당되는 메모리의 양을 세밀하게 제어할 수 있습니다. 다음 항목에서 지정하는 정렬 제약 덕분에, 저수준 확장은 필요에 따라 포인터를 다른 타입으로 손쉽게 캐스트할 수 있습니다.

    또한 이 객체는 바이트 배열로 구현되므로, 현재 문자열을 다루는 표준 라이브러리의 방대한 루틴들에 bytes 객체를 전달할 수 있습니다. 예를 들어, bytes 객체를 struct 모듈과 함께 사용하면 Python 스크립트만으로 array 모듈을 완전히 대체할 수 있습니다. 이 모듈은 배열을 다루는 모듈입니다.

    네이티브 부호 없는 8비트 타입이 없는 특이한 플랫폼이 나타나면, 이 객체는 Python 스크립트 수준에서 자신을 마치 8비트 부호 없는 값의 배열인 것처럼 표현하도록 최선을 다할 것입니다. 많은 확장이 이를 올바르게 처리할지는 의문이지만, 이러한 경우에도 Python 스크립트는 이식성을 가질 수 있습니다.

  2. 할당된 바이트 배열의 정렬은 플랫폼의 malloc 구현이 보장하는 정렬을 따릅니다. 확장에서 생성한 bytes 객체는 확장 작성자가 적합하다고 판단하는 임의의 정렬을 제공할 수 있습니다.

    이 정렬 제약을 통해 bytes 객체는 PyComplex 객체나 표준 C 타입으로 이루어진 다른 구조체를 포함한 모든 표준 C 타입의 저장소로 사용될 수 있어야 합니다. 필요한 경우 확장이 추가적인 정렬 제약을 제공할 수 있습니다.

  3. bytes 객체는 문자열/배열 객체가 제공하는 시퀀스 연산의 일부를 구현하지만, 일부 경우에는 의미가 약간 다릅니다. 특히 슬라이스는 항상 새로운 bytes 객체를 반환하지만, 하부 메모리는 두 객체가 공유합니다. 이러한 슬라이스 동작을 “뷰(view)” 생성이라고 부릅니다. 또한 bytes 객체에 대해서는 반복과 이어 붙이기가 정의되어 있지 않으며, 이를 시도하면 예외가 발생합니다.

    이러한 객체는 고성능 애플리케이션에서 사용될 가능성이 높으므로, 뷰 슬라이싱을 사용하기로 결정한 동기 중 하나는 bytes 객체 간 복사가 매우 효율적이어야 하고 임시 객체를 생성할 필요가 없어야 한다는 점입니다. 다음 코드가 이를 보여 줍니다:

    # create two 10 Meg bytes objects
b1 = bytes(10000000)
b2 = bytes(10000000)

# copy from part of one to another with out creating a 1 Meg temporary
b1[2000000:3000000] = b2[4000000:5000000]

    우변 값(rvalue)의 길이가 좌변 값(lvalue)과 같지 않은 슬라이스 대입은 예외를 발생시킵니다. 그러나 슬라이스 대입은 겹치는 슬라이스에서도 올바르게 동작합니다(일반적으로 memmove로 구현됩니다).

  4. bytes 객체는 효율적인 직렬화를 위해 pickle 및 cPickle 모듈에서 네이티브 타입으로 인식될 것입니다. (사실 이것은 서드파티 확장으로는 구현할 수 없는 유일한 요구 사항입니다.)

    bytes 류 객체에 저장된 데이터를 문자열로 임시 복사하지 않고 직렬화해야 하는 요구를 해결하기 위한 부분적인 해결책은 과거에도 구현된 적이 있습니다. 배열 객체의 tofile 메서드와 fromfile 메서드가 그 좋은 예입니다. bytes 객체도 이 메서드들을 지원할 것입니다. 그러나 피클링은 shelve 모듈이나 Python 객체의 RPC 구현과 같은 다른 상황에서도 유용하며, 효율적인 데이터 전송을 위해 최종 사용자에게 서로 다른 두 가지 직렬화 메커니즘을 사용하도록 요구하는 것은 바람직하지 않습니다.

    XXX: 새 bytes 객체의 피클링을, 이전 버전의 Python이 이를 문자열 객체로 언피클링하는 방식으로 구현하도록 시도할 것입니다.

    언피클링할 때 bytes 객체는 Python이 (malloc을 통해) 할당한 메모리로부터 생성될 것입니다. 따라서 확장이 제공한 포인터가 가졌을 수 있는 추가 속성(특수한 정렬이나 특수한 유형의 메모리)은 모두 잃게 됩니다.

    XXX: bytes 타입의 C 서브클래스가 언피클링 대상이 될 메모리를 제공할 수 있도록 시도할 것입니다. 예를 들어, PageAlignedBytes라는 파생 클래스는 마찬가지로 페이지 정렬된 메모리로 언피클링될 것입니다.

    int가 32비트인 모든 플랫폼(대부분의 플랫폼)에서는 현재 31비트로 표현할 수 있는 것보다 긴 문자열을 생성하는 것이 불가능합니다. 따라서 문자열로 피클링하는 작업이 불가능한 경우에는 예외가 발생할 것입니다.

    적어도 대용량 파일을 지원하는 플랫폼(많은 플랫폼이 해당합니다)에서는 file.write() 메서드를 반복적으로 호출하여 큰 bytes 객체를 파일로 피클링할 수 있어야 합니다.

  5. bytes 타입은 PyBufferProcs 인터페이스를 지원하지만, bytes 객체는 해당 bytes 객체에 대한 참조가 유지되는 한 포인터가 할당 해제되거나 재할당되지 않는다는 추가적인 보장을 제공합니다. 이는 bytes 객체가 일단 생성되면 크기를 변경할 수 없다는 것을 의미하지만, PyBytes_Check(...) 검사를 통과하면 별도의 스레드가 포인터가 가리키는 메모리를 조작하는 동안 전역 인터프리터 잠금(GIL)을 해제할 수 있게 해 줍니다.

    bytes 객체의 이러한 특성 덕분에 비동기 파일 I/O나, PyBufferProcs를 통해 얻은 포인터가 전역 인터프리터 잠금과 독립적으로 사용되는 멀티프로세서 머신과 같은 상황에서 bytes 객체를 사용할 수 있습니다.

    GIL이 해제된 후에도 포인터가 재할당되거나 해제될 수 없다는 것을 알면, 확장 작성자는 진정한 동시성을 얻고 포인터에 대해 오래 실행되는 계산에 추가 프로세서를 활용할 수 있습니다.

  6. C/C++ 확장에서는 제공된 포인터와, 참조 횟수가 0이 될 때 메모리를 해제하는 소멸자 함수로부터 bytes 객체를 생성할 수 있습니다.

    bytes 객체의 특수한 슬라이싱 구현을 통해 여러 bytes 객체가 동일한 포인터/소멸자를 참조할 수 있습니다. 따라서 실제 포인터/소멸자에 대해 참조 횟수가 유지될 것입니다. 이 참조 횟수는 일반적으로 Python 객체와 연관된 참조 횟수와는 별개입니다.

    XXX: 내부의 참조 횟수가 관리되는 객체를 실제 Python 객체로 노출하는 것이 바람직할 수도 있습니다. 좋은 사용 사례가 생긴다면, 하위 호환성을 해치지 않고 나중에 이를 구현할 수 있을 것입니다.

  7. bytes 객체를 읽기 전용으로 지정하는 것도 가능하며, 이 경우 실제로는 변경할 수 없지만 bytes 객체의 다른 기능은 제공합니다.
  8. bytes 객체는 Python LONG_LONG 타입으로 데이터의 길이를 추적합니다. 현재 PyBufferProcs의 정의는 길이를 int 크기로 제한하지만, 이 PEP는 그 부분에 대한 어떠한 변경도 제안하지 않습니다. 대신 확장은 명시적으로 PyBytes_Check(...)를 호출하여 이 제한을 우회할 수 있으며, 호출이 성공하면 PyBytes_GetReadBuffer(...) 또는 PyBytes_GetWriteBuffer를 호출하여 포인터와 객체의 전체 길이를 LONG_LONG으로 얻을 수 있습니다.

    표준 PyBufferProcs 메커니즘이 사용되고 bytes 객체의 크기가 정수로 표현할 수 있는 것보다 크면 bytes 객체는 예외를 발생시킬 것입니다.

    Python 스크립트에서는 bytes 객체에 long으로 첨자 접근할 수 있으므로 32비트 int 제한을 피할 수 있습니다.

    len() 함수는 PyObject_Size()에 해당하며 이 역시 int를 반환하므로 여전히 문제가 있습니다. 이에 대한 해결책으로 bytes 객체는 long을 반환하는 .length() 메서드를 제공할 것입니다.

  9. bytes 객체는 Python 스크립트 수준에서 할당할 바이트 수를 int/long 값으로 bytes 생성자에 전달하여 생성할 수 있습니다. 예를 들면 다음과 같습니다.:
    b = bytes(100000) # alloc 100K bytes

    생성자는 다른 bytes 객체를 받을 수도 있습니다. 이는 언피클링을 구현할 때와 읽기-쓰기 bytes 객체를 읽기 전용 객체로 변환할 때 유용할 것입니다. 선택적인 두 번째 인자는 읽기 전용 bytes 객체를 생성하도록 지정하는 데 사용될 것입니다.

  10. C API에서는 다음 시그니처 중 어느 것을 사용해서든 bytes 객체를 할당할 수 있습니다.:
    PyObject* PyBytes_FromLength(LONG_LONG len, int readonly);
PyObject* PyBytes_FromPointer(void* ptr, LONG_LONG len, int readonly
         void (*dest)(void *ptr, void *user), void* user);

    PyBytes_FromPointer(...) 함수에서 dest 함수 포인터가 NULL로 전달되면 해당 함수는 호출되지 않습니다. 이 방식은 정적으로 할당된 공간으로부터 bytes 객체를 생성할 때만 사용해야 합니다.

    사용자 포인터는 다른 곳에서 클로저라고 불려 왔습니다. 이는 사용자가 어떤 목적으로든 사용할 수 있는 포인터입니다. 이 포인터는 정리 시에 소멸자 함수로 전달되며 여러 가지 용도로 유용하게 쓰일 수 있습니다. 사용자 포인터가 필요하지 않다면 대신 NULL을 전달해야 합니다.

  11. 모든 표준 Python 타입이 그 방향으로 나아가고 있는 것으로 보이므로 bytes 타입은 새 스타일 클래스가 될 것입니다.

기존 타입과의 비교

bytes 객체가 없다는 점을 우회하는 가장 일반적인 방법은 그 자리에 단순히 문자열 객체를 사용하는 것이었습니다. 바이너리 파일, struct/array(배열) 모듈 등 이런 예는 여러 가지가 있습니다. 이러한 용도가 대개 텍스트 문자열과 아무 관련이 없다는 스타일상의 문제는 차치하더라도, 문자열은 변경할 수 없으므로 이러한 경우에 반환된 데이터를 직접 조작할 수 없다는 실질적인 문제가 있습니다. 또한 문자열 모듈의 수많은 최적화(해시 값 캐싱이나 포인터 인터닝 등) 때문에, 확장 모듈 작성자가 문자열 객체로 규칙을 어기려 하면 매우 위태로운 상황에 놓이게 됩니다.

버퍼 객체는 bytes 객체가 달성하려는 목적을 다루기 위해 의도된 것으로 보이지만, 구현상의 여러 결함 [1] 때문에 많은 일반적인 경우에 유용성이 떨어졌습니다. 버퍼 객체는 슬라이싱 동작에서 다른 선택을 했으며(슬라이싱 및 기타 연산에 대해 버퍼 대신 새 문자열을 반환합니다), bytes 객체가 보장하는 정렬이나 GIL 해제 가능성에 관한 여러 약속을 하지 않습니다.

또한 버퍼 객체와 관련하여, 버퍼 객체를 단순히 bytes 객체로 대체하면서 하위 호환성을 유지하는 것은 불가능합니다. 버퍼 객체는 다른 객체가 PyBufferProcs로 제공하는 포인터를 가져와 자신의 것처럼 제시하는 메커니즘을 제공합니다. 다른 객체의 동작이 bytes 객체와 같은 엄격한 규칙들을 따른다고 보장할 수 없으므로, buffer 객체는 bytes 객체를 사용할 수 있는 곳에 사용할 수 없습니다.

array 모듈은 바이트 배열의 생성을 지원하지만, 확장 모듈이 제공하는 메모리에 대한 포인터와 소멸자를 전달하기 위한 C API는 제공하지 않습니다. 이 때문에 공유 메모리나, DMA 전송 같은 용도를 위해 특수한 정렬 또는 잠금이 적용된 메모리로 객체를 구성하는 데에는 사용할 수 없습니다. 또한 배열 객체는 현재 피클링되지 않습니다. 마지막으로 배열 객체는 extend 메서드를 통해 내용이 늘어날 수 있으므로, 포인터를 사용하는 동안 GIL을 보유하지 않으면 포인터가 변경될 수 있습니다.

배열 객체로부터 버퍼 객체를 생성하면, 배열 객체의 크기가 조정될 때 유효하지 않은 포인터가 남는 동일한 문제가 있습니다.

mmap 객체는 자신의 특정한 틈새 용도에는 부합하지만, 더 넓은 범주의 문제를 해결하려고 하지는 않습니다.

마지막으로, 어떠한 서드파티 확장 모듈도 표준 Python 타입의 임시 객체를 생성하지 않고서는 피클링을 구현할 수 없습니다. 예를 들어 Numeric 커뮤니티에서는 큰 배열을 피클링하려면 배열 데이터를 복제하는 큰 바이너리 문자열을 만들어야 한다는 점이 불편합니다.

하위 호환성

저자가 알고 있는 유일한 하위 호환성 문제는 새 bytes 타입이 포함된 데이터를 이전 버전의 Python에서 unpickle하려고 할 때 발생할 수 있습니다.

참조 구현

XXX: 실제 구현은 진행 중이지만, 이 PEP가 추가 검토를 거치면서 여전히 변경될 수 있습니다.

다음 새 파일들이 Python 기준 코드에 추가됩니다:

Include/bytesobject.h  # C interface
Objects/bytesobject.c  # C implementation
Lib/test/test_bytes.py # unit testing
Doc/lib/libbytes.tex   # documentation

다음 파일들도 수정됩니다:

Include/Python.h       # adding bytesmodule.h include file
Python/bltinmodule.c   # adding the bytes type object
Modules/cPickle.c      # adding bytes to the standard types
Lib/pickle.py          # adding bytes to the standard types

다른 여러 모듈도 정리하여 bytes 객체를 기반으로 구현할 수 있을 것입니다. 가장 먼저 떠오르는 것은 mmap 모듈이지만, 앞서 언급했듯이 array(배열) 모듈을 순수 Python 모듈로 다시 구현하는 것도 가능합니다. 이 PEP가 실제로 소스 코드의 양을 어느 정도 줄일 수 있다는 점은 매력적이지만, 저자는 이것이 기존 애플리케이션을 망가뜨릴 불필요한 위험을 초래할 수 있으므로 현재로서는 피해야 한다고 생각합니다.

추가 참고 사항/의견

  • Guido van Rossum은 mmap 객체로부터 bytes 객체를 생성할 수 있게 하는 것이 타당한지 의문을 제기했습니다. mmap 객체는 bytes 객체에 메모리를 제공하는 데 필요한 요구 사항을 충족하는 것으로 보입니다. (크기가 변경되지 않으며, 포인터는 객체의 수명 동안 유효합니다.) 따라서 mmap 객체로부터 bytes 객체를 직접 생성할 수 있도록 mmap 모듈에 메서드를 추가할 수 있을 것입니다. 이를 구현하는 방법에 대한 초기 구상은 앞서 설명한 PyBytes_FromPointer() 함수를 사용하고 mmap_object를 사용자 포인터로 전달하는 것입니다. 소멸자 함수는 정리를 위해 mmap_object의 참조 카운트를 감소시킵니다.
  • Todd Miller는 PyObject_AsReadBuffer() 및 PyObject_AsWriteBuffer()와 유사하지만 void* 포인터와 함께 LONG_LONG 길이도 얻을 수 있도록 지원하는 두 개의 새 함수 PyObject_AsLargeReadBuffer()와 PyObject_AsLargeWriteBuffer가 있으면 유용할 수 있다고 언급합니다. 이 함수들을 사용하면 확장 모듈 작성자가 (LONG_LONG 길이를 지원하는) bytes 객체와 (int 길이만 지원하는) 대부분의 다른 버퍼 유사 객체를 투명하게 다룰 수 있습니다. 이 함수들은 별도의 PyByte_GetReadBuffer() 및 PyBytes_GetWriteBuffer() 함수를 만드는 것을 대신하거나, 그에 더하여 제공될 수 있습니다.

    XXX: 저자는 이것이 다른 객체들도 결국 큰(64비트) 포인터를 지원할 수 있는 길을 열어 주고 abstract.c와 abstract.h에만 영향을 미칠 것이므로 매우 좋은 아이디어라고 생각합니다. 이것을 위 내용에 추가해야 하겠습니까?

  • 길이의 31비트 제한을 우회하기 위해 PyBufferProcs 인터페이스의 세그먼트 수를 남용하는 것은 좋은 편법이 아니라는 데 대체로 의견이 모였습니다. 이것이 무슨 뜻인지 모르시더라도 괜찮습니다. 많은 사람이 마찬가지입니다. Python 기준 코드의 대부분과 아마도 많은 서드파티 확장 모듈도 세그먼트 수가 1이 아니면 처리를 포기합니다.

참고 문헌