Rust처럼 안전하게 Python 코드 작성하기

Posted on Edited on In , ,

Kobzol’s blog의 Writing Python like it’s Rust를 번역한 글입니다.

왜 Python을 Rust처럼 적게되었나?

저는 몇 년 전부터 Rust로 프로그래밍을 시작했고, 다른 프로그래밍 언어로 (특히 Python으로) 프로그램을 설계할 때 Rust 프로그램의 설계 방식을 사용하고 있습니다. Rust를 사용하기 전 까지는, 저도 여느 사람들과 같이 Python으로 프로그래밍을 할 때는 타입 힌트 없이 함수를 작성하거나 느슨한 타입을 사용하는 코드를 작성하고, 사방에 dict를 전달하고 반환하며, 때때로 ‘str 타입’ 인터페이스를 사용하는 경우도 많았습니다. 그러나 Rust로부터 타입 시스템의 엄격함을 경험하고 수많은 문제들을 설계상 방지할 수 있다는 것을 발견한 후, 저는 Python 프로그래밍에서 Rust처럼 동일한 안전 수준이 보장되지 않는 것이 상당히 불안해졌습니다.

여기서 ‘보장’이란 메모리 안전성을 의미하는 것이 아니라 (Python은 현재도 상당히 메모리 안전합니다), 오용이 매우 어렵거나 완전히 불가능한 API를 설계하여 정의되지 않은 동작 및 다양한 버그를 방지하는 개념인 ‘타입 건전성‘을 의미합니다. Rust에서는 잘못 사용된 API의 경우 일반적으로 컴파일 단계에서 에러를 유발함으로써 잘못된 코드가 실행되는 것을 방지합니다. Python에서는 이러한 컴파일 단계가 없어 잘못된 코드를 실행할 수도 있지만, pyright 같은 타입 체커나 PyCharm과 같은 타입 분석기가 있는 IDE를 사용하면 타입 건정성을 사전에 체크할 수 있습니다.

결국 저는 Python 프로그램에 Rust의 몇 가지 개념을 도입하기 시작했습니다. 기본적으로 타입 힌트를 최대한 많이 사용하고, illegal state가 없게 만듬으로써 두 가지 원칙으로 요약할 수 있습니다. 장기간 유지보수 해야 할 프로그램뿐만 아니라, 일회성 유틸리티 스크립트에도 이 원칙을 적용하려고 노력합니다. 제 경험상 후자는 종종 전자로 바뀌기 때문입니다 :) 제 경험상 이 접근 방식은 이해하고 변경하기 더 쉬운 프로그램으로 이어집니다.

이 글에서는 Python 프로그램에 적용된 이러한 패턴의 몇 가지 예를 보여드리겠습니다. 엄청나게 대단한 기술은 아니지만 그래도 문서화하는 것이 유용할 것 같았습니다.

참고: 이 글에는 Python 코드 작성에 대한 많은 개인적인 의견이 포함되어 있습니다. 모든 문장에 “IMHO”를 붙이고 싶지는 않으므로 이 글의 모든 내용은 보편적인 진리를 주장하려는게 아닌, 단순히 해당 문제에 대한 제 의견으로 받아들여주세요 :) 또한 제시된 아이디어가 모두 Rust에서 발명되었다고 주장하는 것은 아니며 다른 언어에서도 물론 이미 사용되고 있는 개념일 수 있습니다.

 

타입 힌트

가장 중요한 것은 가능한 경우, 특히 함수 서명과 클래스 속성에서 타입 힌트를 사용하는 것입니다. 다음과 같은 함수 시그니처를 읽으면 다음과 같습니다:

1
def find_item(records, check):

함수 시그니처만 읽었을 때 무슨 일이 벌어지고 있는지 전혀 알 수 없습니다. records는 list일까요? dict일까요? 아니면 데이터베이스 연결일까요? check는 bool인가요, 아니면 함수인가요? 이 함수는 무엇을 반환하나요? 실패하면 어떻게 되나요, 예외를 발생시키나요, 아니면 None을 반환하나요?

이러한 질문에 대한 답을 찾으려면 함수 본문(그리고 종종 함수가 호출하는 다른 함수의 본문까지 재귀적으로 읽어야 하는데, 이는 매우 귀찮은 일입니다.)을 읽거나 문서(있는 경우)를 읽어야 합니다. 문서에는 함수가 수행하는 작업에 대한 유용한 정보가 포함되어 있을 수 있지만, 이전 질문에 대한 답변을 문서화하는 데까지 사용할 필요는 없습니다.

대부분의 질문은 내장된 메커니즘인 타입 힌트를 통해 답을 찾을 수 있습니다.

1
2
3
4
def find_item(
  records: List[Item],
  check: Callable[[Item], bool]
) -> Optional[Item]:

함수 시그니처를 작성하는 데 시간이 더 걸렸나요? 네. 그게 문제가 될까요? 아니요, 분당 작성하는 문자 수로 인해 코딩이 병목 현상을 일으키지 않는 한, 실제로 그런 일은 일어나지 않습니다. 타입을 명시적으로 작성하면 함수가 제공하는 실제 인터페이스가 무엇인지, 호출자가 함수를 잘못된 방식으로 사용하지 못하도록 최대한 엄격하게 만들 수 있는 방법이 무엇인지 생각하게 됩니다. 위의 함수 시그니처를 사용하면 함수를 어떻게 사용할 수 있는지, 인자로 무엇을 전달해야 하는지, 함수를 통해 무엇을 반환할 수 있는지 명확하게 알 수 있습니다. 또한 코드가 변경되면 쉽게 구식이 될 수 있는 문서 주석과 달리, 타입을 변경하고 함수 호출자를 업데이트하지 않으면 정적 타입 검사기가 저에게 수많은 에러를 쏟아낼겁니다. Item이 무엇인지 궁금하다면 해당 클래스의 정의로 이동하여 해당 타입이 어떻게 생겼는지 즉시 확인할 수 있습니다.

하나의 매개변수를 설명하기 위해 엄청나게 복잡한 타입을 사용해야한다면 (e.g. 5개의 중첩된 타입 힌트가 필요하다면), 때에 따라 엄격함을 포기하고 부정확하지만 더 간단한 타입을 제공할 수 있습니다 (저는 이 점에서 절대 꽉 막히고 빡빡하게 사는 사람이 아닙니다). 하지만 제 경험상 이러한 상황은 자주 발생하지 않습니다. 함수 매개변수가 숫자, str tuple 또는 {str:int} dict일 수 있다면 코드에 문제가 있다는 신호일 수 있으므로, 이는 함수를 리팩토링해서 단순하게 바꿔야하는 또 다른 주제의 문제일 수 있습니다.

 

Tuple이나 Dict 대신 Dataclass 사용

타입 힌트를 사용하는 것도 한 가지 방법이지만, 이는 함수의 인터페이스가 무엇인지 설명할 뿐입니다. 그 다음 단계는 실제로 이러한 인터페이스를 가능한 한 명확한 데이터 타입으로 ‘고정’하는 것입니다.

일반적인 예로 함수에서 여러 값(또는 하나의 복합 값)을 반환하는 것을 들 수 있습니다. 가장 느슨하게 짜는 방식 (많은 파이썬 유저들이 채택하는 방식)은 Tuple을 반환하는 것입니다:

1
def find_person(...) -> Tuple[str, str, int]:

좋습니다, 세 개의 값을 반환한다는 것을 알았습니다. 하지만 이 값들은 무엇을 의미할까요? 첫 번째 문자열은 사람의 이름인가요? 두 번째 문자열은 성인가요? 숫자는 무엇인가요? 나이인가요? 목록에서 어떤 위치인가요? 사회보장번호?

이런 종류의 입력은 불투명하며 함수 본문을 들여다보지 않는 한 여기서 무슨 일이 일어나는지 알 수 없습니다.

이를 개선하기 위한 다음 단계는 Dict를 반환하는 것입니다 (하지만 이 방법 역시 좋은 방법은 아닙니다):

1
2
3
4
5
6
7
def find_person(...) -> Dict[str, Any]:
    ...
    return {
        "name": ...,
        "city": ...,
        "age": ...
    }

이제 실제로 반환된 개별 속성이 무엇인지 알 수 있지만, 이를 알아내기 위해 다시 함수 본문을 검사해야 합니다. 이제 우리는 개별 속성의 개수와 타입조차 모르기 때문에 어떤 의미에서는 타입이 더 나빠졌습니다. 게다가 함수가 변경되어 반환된 dict의 키가 이름이 바뀌거나 제거되면 타입 검사기로 쉽게 알 수 있는 방법이 없기 때문에, 보통 매우 수동적이고 번거로운 디버깅을 통해 함수가 호출되는 모든 코드를 변경해야 합니다.

적절한 해결책은 타입이 첨부된 명명된 매개변수와 함께 강타입화된 (Strong-typed) 객체를 반환하는 것입니다. Python에서는 클래스를 만들어야 한다는 뜻입니다. 이러한 상황에서 Tuple과 Dict가 자주 사용되는 이유는 클래스를 정의하고(그리고 이름을 생각해서), 매개변수가 있는 생성자를 만들고, 매개변수를 필드 등에 저장하는 것보다 훨씬 쉽기 때문이라고 생각합니다. Python 3.7(그리고 package polyfill을 사용하면 더 빨리)부터는 훨씬 더 빠른 솔루션인 Dataclass가 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@dataclasses.dataclass
class City:
    name: str
    address: int


dataclasses.dataclass
class Person :
    name: str
    city: City
    age: int


def find_person(...) -> Person:

여전히 생성된 클래스의 이름을 생각해야 하지만, 그 외에는 최대한 간결하고 모든 속성에 대한 타입을 부여할 수 있습니다.

Dataclass를 사용하면 함수가 반환하는 객체와 그 세부 타입들에 대한 명시적인 설명이 있습니다. 이 함수를 호출하고 반환된 값으로 작업하면 IDE 자동 완성 기능이 해당 타입의 이름과 타입을 표시해 줍니다. 사소하게 들릴지 모르지만 제게는 생산성 향상에 큰 도움이 됩니다. 또한 코드가 리팩터링되어 속성이 변경되면 제가 프로그램을 실행할 필요 없이 IDE와 타입 검사기가 변경해야 하는 모든 위치를 표시해 줍니다. 일부 간단한 리팩터링(예: 속성 이름 바꾸기)의 경우 IDE가 이러한 변경을 대신 수행하기도 합니다. 또한 명시적으로 이름이 지정된 타입을 사용하면 다른 함수 및 클래스와 공유할 수 있는 용어 어휘집(Person, City)을 만들 수 있습니다.

필드가 있는 객체를 입력하는 다른 방법도 있습니다. 예를 들어 TypedDict 또는 NamedTuple이 있습니다.

 

Algebraic data type

대부분의 주류 언어에서 가장 부족한 점이 있다면 아마도 Algebraic data type (ADT)일 것입니다. ADT는 제 코드에서 작업하는 데이터의 형태를 명시적으로 설명할 수 있는 매우 강력한 도구입니다.

예를 들어 Rust에서 Packet 객체를 만들 때 (i.e. 소켓통신 프로그래밍을 할 때) 수신할 수 있는 다양한 종류의 Packet을 모두 명시적으로 열거하고 각 Packet에 서로 다른 데이터(필드)를 할당할 수 있습니다. Pattern matching을 사용하면 개별 타입에 반응할 수 있고 컴파일러는 실수를 하지 않았는지 확인합니다:

1
2
3
4
5
6
7
8
9
10
11
12
13
enum Packet {
  Header {
    protocol: Protocol,
    size: usize
  },
  Payload {
    data: Vec<u8>
  },
  Trailer {
    data: Vec<u8>,
    checksum: usize
  }
}
1
2
3
4
5
6
7
fn handle_packet(packet: Packet) {
  match packet {
    Packet::Header { protocol, size } => ...,
    Packet::Payload { data } |
    Packet::Trailer { data, ...} => println!("{data:?}")
  }
}

이는 illegal state를 표현할 수 없도록 하여 많은 런타임 오류를 방지하는 데 매우 유용합니다. 정적으로 타입이 지정된 언어에서 ADT는 특히 유용하며, 통일된 방식으로 일련의 타입으로 작업하려면 이를 참조할 공유 ‘이름’이 필요합니다. ADT가 없으면 일반적으로 OOP 인터페이스 및/또는 상속을 사용하여 이 작업을 수행합니다. 인터페이스와 가상 메서드는 사용되는 타입 집합이 개방형일 때 적합하지만, 타입 집합이 폐쇄형이고 가능한 모든 변형을 처리해야 하는 경우에는 ADT와 패턴 매칭이 훨씬 더 적합합니다.

Python과 같이 동적으로 타입이 지정된 언어에서는 애초에 프로그램에서 사용되는 타입에 이름을 지정할 필요가 없기 때문에 타입 집합에 공유 ‘이름’을 지정할 필요는 없습니다. 하지만 유니온 타입을 생성하여 ADT와 유사한 것을 사용하는 것이 여전히 유용할 수 있습니다:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@dataclass
class Header:
  protocol: Protocol
  size: int

@dataclass
class Payload:
  data: str

@dataclass
class Trailer:
  data: str
  checksum: int

Packet = typing.Union[Header, Payload, Trailer]
# or `Packet = Header | Payload | Trailer` since Python 3.10

여기서 Packet은 Header, Payload, Trailer와 같이 Packet이 될 수 있는 새로운 타입을 정의합니다. 이제 이 세 가지 클래스만 유효하도록 하고 싶을 때 나머지 프로그램에서 이 타입(이름)을 사용할 수 있습니다. 클래스에 명시적인 “태그”가 첨부되어 있지 않으므로 클래스를 구분하려면 instanceof 또는 Pattern matching 등을 사용해야 합니다:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
def handle_is_instance(packet: Packet):
    if isinstance(packet, Header):
        print("header {packet.protocol} {packet.size}")
    elif isinstance(packet, Payload):
        print("payload {packet.data}")
    elif isinstance(packet, Trailer):
        print("trailer {packet.checksum} {packet.data}")
    else:
        assert False

def handle_pattern_matching(packet: Packet):
    match packet:
        case Header(protocol, size): print(f"header {protocol} {size}")
        case Payload(data): print("payload {data}")
        case Trailer(data, checksum): print(f"trailer {checksum} {data}")
        case _: assert False

안타깝게도 여기서는 예기치 않은 데이터를 수신할 때 함수가 터지도록 성가신 assert False 브랜치를 포함해야 합니다. Rust에서는 이렇게 만들 필요 없이 컴파일 타임 에러로 대체할 수 있습니다.

Reddit의 여러 사람들이 최적화 빌드(python -O …)에서는 실제로 assert False가 완전히 최적화되어 있다는 점을 알려주었습니다. 따라서 예외를 직접 발생시키는 것이 더 안전할 것입니다. Python 3.11의 typing.assert_never도 있는데, 이는 타입 검사기에 이 브랜치로 떨어지는 것이 “컴파일 타임” 에러가 되어야 한다고 명시적으로 알려줍니다.

Union 타입의 좋은 특성은 Union의 일부인 클래스 외부에 정의된다는 것입니다. 따라서 클래스는 자신이 Union에 포함된다는 사실을 알지 못하므로 코드의 강결합이 줄어듭니다. 또한 동일한 타입을 사용하여 여러 개의 다른 Union을 만들 수도 있습니다:

1
2
Packet = Header | Payload | Trailer
PacketWithData = Payload | Trailer

Union 타입은 자동 (역)직렬화에도 매우 유용합니다. 최근에 저는 유서 깊은 Rust의 serde 직렬화 프레임워크를 기반으로 하는 pyserde라는 멋진 직렬화 라이브러리를 발견했습니다. 다른 많은 멋진 기능 중에서도 코드 주석을 활용하여 추가 코드 없이 Union 타입을 직렬화 및 역직렬화할 수 있습니다:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
import serde

...
Packet = Header | Payload | Trailer

@dataclass
class Data:
    packet: Packet

serialized = serde.to_dict(Data(packet=Trailer(data="foo", checksum=42)))
# {'packet': {'Trailer': {'data': 'foo', 'checksum': 42}}}

deserialized = serde.from_dict(Data, serialized)
# Data(packet=Trailer(data='foo', checksum=42))

serde와 마찬가지로 Union 태그를 어떻게 직렬화할지 선택할 수도 있습니다. Union 타입을 (역)직렬화하는 데 매우 유용하기 때문에 비슷한 기능을 오랫동안 찾고 있었습니다. 그러나 제가 시도한 대부분의 다른 직렬화 라이브러리(예: dataclasses_json 또는 dacite)에서 구현하는 것이 상당히 번거로웠습니다.

예를 들어, 머신 러닝 모델로 작업할 때 Union을 사용하여 다양한 유형의 신경망(예: classification 또는 segmentation CNN 모델)을 단일 config 파일 형식 안에 저장하고 있습니다. 또한 이와 같이 다양한 형식의 데이터(제 경우에는 config 파일)를 버전별로 저장하는 것이 유용하다는 것을 알게 되었습니다:

1
Config = ConfigV1 | ConfigV2 | ConfigV3

Config를 역직렬화하면 이전 버전의 모든 config 형식을 읽을 수 있으므로 이전 버전과의 호환성을 유지할 수 있습니다.

 

newtype 사용하기

Rust에서는 일반적인 데이터 타입 (e.g. 정수)에 새로운 동작을 추가하지 않고, 도메인에 걸맞는 용도로 새롭게 이름을 지정하는 데이터 타입을 정의하는게 일반적입니다. 이 패턴을 “newtype”이라고 하며 Python에서도 사용할 수 있습니다.

아래의 상황을 한번 봅시다.

1
2
3
4
5
6
7
8
9
class Database:
  def get_car_id(self, brand: str) -> int:
  def get_driver_id(self, name: str) -> int:
  def get_ride_info(self, car_id: int, driver_id: int) -> RideInfo:

db = Database()
car_id = db.get_car_id("Mazda")
driver_id = db.get_driver_id("Stig")
info = db.get_ride_info(driver_id, car_id)

오류를 발견하셨나요?

…

…

get_ride_info의 인수가 잘못들어갔습니다 (db.get_rider_info(car_id, driver_id)가 되어야합니다). 하지만, 차량 ID와 운전자 ID는 모두 정수에 불과하므로 의미상 함수 호출이 잘못되었더라도 타입 자체는 올바르므로 타입 오류는 없습니다.

이 문제는 “NewType”을 사용하여 서로 다른 종류의 ID에 대해 별도의 타입을 정의함으로써 해결할 수 있습니다:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
from typing import NewType

# Define a new type called "CarId", which is internally an `int`
CarId = NewType("CarId", int)
# Ditto for "DriverId"
DriverId = NewType("DriverId", int)

class Database:
  def get_car_id(self, brand: str) -> CarId:
  def get_driver_id(self, name: str) -> DriverId:
  def get_ride_info(self, car_id: CarId, driver_id: DriverId) -> RideInfo:


db = Database()
car_id = db.get_car_id("Mazda")
driver_id = db.get_driver_id("Stig")
# Type error here -> DriverId used instead of CarId and vice-versa
info = db.get_ride_info(<error>driver_id</error>, <error>car_id</error>)

이렇게 매우 간단한 방식으로 다른 방법으로는 발견하기 어려운 오류를 포착하는 데 도움이 될 수 있습니다. 예를 들어, 여러 종류의 ID(CarId 대 DriverId)를 다루거나, 함께 섞어서는 안 되는 일부 메트릭(Speed, Length, Temperature 등)을 처리하는 경우 특히 유용합니다.

 

생성자 함수 사용하기

제가 Rust에서 아주 좋아하는 점 중 하나는 생성자 자체가 없다는 점입니다. 대신 일반 함수를 사용해 구조체의 인스턴스(이상적으로는 적절하게 초기화된 인스턴스)를 생성하는 경향이 있습니다. Python에서는 생성자 오버로딩이 없기 때문에 객체를 여러 가지 방법으로 생성해야 하는 경우, 때로는 초기화를 위해 여러 가지 방법으로 사용되는 매개변수가 많은 __init__ 메서드를 사용해야 하는데 실제로는 함께 사용할 수 없습니다.

대신, 저는 객체를 구성하는 방법과 어떤 데이터에서 객체를 구성하는지 명확히 알 수 있는 명시적인 이름을 가진 “생성” 함수를 만드는 것을 좋아합니다:

1
2
3
4
5
6
class Rectangle:
    @staticmethod
    def from_x1x2y1y2(x1: float, ...) -> "Rectangle":
    
    @staticmethod
    def from_tl_and_size(top: float, left: float, width: float, height: float) -> "Rectangle":

위와 같은 방법을 통해 객체를 훨씬 명확하고 깔끔하게 생성할 수 있으며, 클래스 사용자가 객체를 구성할 때 잘못된 데이터를 전달할 수 없습니다(예: y1과 width를 결합하는 경우).

 

타입을 사용해 불변성 인코딩하기

타입 시스템 자체를 사용해 런타임에만 추적할 수 있는 불변성을 인코딩하는 것은 매우 일반적이고 강력한 개념입니다. Python(뿐만 아니라 다른 주류 언어에서도)에서는 mutable한 데이터가 얽히고 섥혀서 사용되는 클래스들을 자주 볼 수 있습니다. 이러한 현상의 원인 중 하나는 객체의 불변성을 런타임에 추적하려고 하기 때문입니다. 타입 시스템에서 금지시킨 것이 아니기 때문에 (i.e. 컴파일 단계에서 설계상 막아둔 것이 아니기 때문에), 발생할 수 있는 많은 상황을 가정하고 각각의 상황에 대한 대처 방식을 고려해야 합니다(“클라이언트가 연결을 끊으라는 요청을 받았는데 누군가 메시지를 보내려고 하는데 소켓이 여전히 연결되어 있으면 어떻게 할까요?” 등).

클라이언트

다음은 전형적인 예입니다:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Client:
  """
  Rules:
  - Do not call `send_message` before calling `connect` and then `authenticate`.
  - Do not call `connect` or `authenticate` multiple times.
  - Do not call `close` without calling `connect`.
  - Do not call any method after calling `close`.
  """
  def __init__(self, address: str):

  def connect(self):
  def authenticate(self, password: str):
  def send_message(self, msg: str):
  def close(self):

…쉽죠? 문서를 주의 깊게 읽고, 언급된 규칙을 위반하지 않도록(정의되지 않은 동작이나 충돌을 유발하지 않도록) 주의하기만 하면 됩니다 (껄껄). 다른 대안은 런타임에 언급된 모든 규칙을 검사하는 다양한 assertion으로 클래스를 채우는 것인데, 이는 코드가 지저분해지고 edge-case를 놓치며 문제가 발생했을 때 피드백이 느려집니다(컴파일 타임과 런타임 비교). 문제의 핵심은 클라이언트가 다양한(상호 배타적인) 상태로 존재할 수 있지만 이러한 상태를 개별적으로 모델링하는 대신 모두 단일 타입으로 병합한다는 것입니다.

다양한 상태를 별도의 타입으로 분할하여 이 문제를 개선할 수 있는지 살펴봅시다.

  • 우선, 아무 것도 연결되지 않은 ‘Client’를 갖는 것이 합리적일까요? 그렇지 않은 것 같습니다. 연결되지 않은 client는 어차피 connect를 호출할 때까지 아무것도 할 수 없습니다. 그렇다면 왜 이런 상태가 존재하도록 허용할까요? ConnectedClient를 생성하고 반환하는 connect라는 함수를 만들 수 있습니다:

함수가 성공하면 “연결됨” 불변성을 유지하는 클라이언트를 반환합니다. 이러한 구조는 우리가 실수로 다시 connect를 호출했을 때 다시 connect를 하려는 이상한 상태 변화를 피할 수 있게 됩니다. connect가 실패하면 함수는 예외를 발생시키거나 None 또는 명시적인 오류를 반환할 수 있습니다.

1
2
3
4
5
6
7
def connect(address: str) -> Optional[ConnectedClient]:
  pass

class ConnectedClient:
  def authenticate(...):
  def send_message(...):
  def close(...):
  • 인증된 상태에도 비슷한 접근 방식을 사용할 수 있습니다. 클라이언트가 연결되고 인증되었다는 (authenticate) 불변성을 보유하는 다른 타입을 도입할 수 있습니다:

실제로 AuthenticatedClient의 인스턴스가 있어야만 실제로 메시지 전송을 시작할 수 있습니다.

1
2
3
4
5
6
ConnectedClient 클래스:
  def authenticate(...) -> Optional["AuthenticatedClient"]:

클래스 AuthenticatedClient:
  def send_message(...):
  def close(...):
  • 마지막 문제는 close 메서드에 있습니다. Rust에서는 (destructive move semantics 때문에) close 메서드가 호출되면, Client를 더 이상 사용할 수 없다는 사실을 표현할 수 있습니다. Python에서는 이러한 표현 방식이 불가능하므로 몇 가지 우회 방법을 사용해야 합니다. 한 가지 해결책은 런타임 트래킹으로 돌아가서 Client에 bool 속성을 도입하고 close 및 send_message에서 아직 닫히지 않았다고 assert하는 것입니다. 또 다른 접근 방식은 close 메서드를 완전히 제거하고 Client를 context manager로만 사용하는 것입니다:

close 메서드를 사용할 수 없게 만든다면,실수로 Client를 두 번 닫을 수 없을겁니다.

1
2
3
connect(...)를 client로 사용합니다:
    client.send_message("foo")
# 여기서 클라이언트가 닫힙니다.

강타입의 바운딩 박스

Object detection은 제가 가끔 작업하는 컴퓨터 비전 작업으로, 프로그램이 이미지에서 일련의 bounding box를 추론해야 하는 작업입니다. Bbox는 기본적으로 기본 직사각형에 left,top과 같은 추가 정보를 가지는 객체로 object detection 알고리즘을 구현할 때 항상 사용됩니다.한 가지 성가신 점은 때로는 정규화(사각형의 좌표와 크기가 [0.0, 1.0] 간격에 있음)되지만 때로는 비정규화(좌표와 크기가 첨부된 이미지의 크기에 의해 경계됨)된다는 것입니다. 예를 들어 데이터 전처리 또는 후처리를 처리하는 많은 함수에 Bbox를 보내면 이를 엉망으로 만들기 쉽고, 예를 들어 Bbox를 두 번 정규화하여 디버깅하기 매우 성가신 오류가 발생합니다.

이런 일이 몇 번 있었기 때문에 한 번은 이 두 가지 타입의 bbox를 두 개의 개별 타입으로 분할하여 이 문제를 완전히 해결하기로 결정했습니다:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@dataclass
class NormalizedBBox:
  left: float
  top: float
  width: float
  height: float


@dataclass
DenormalizedBBox 클래스:
  left: float
  top: float
  width: float
  height: float

이렇게 분리하면 정규화된 Bbox와 비정규화된 BBox가 더 이상 쉽게 섞일 수 없으므로 문제가 대부분 해결됩니다. 하지만 코드를 보다 읽기 쉽게 만들기 위해 개선할 수 있는 몇 가지 사항이 있습니다:

  • 통합(Composition) 또는 상속(Inheritance)를 통한 코드 중복 감소:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@dataclass
class BBoxBase:
  left: float
  top: float
  width: float
  height: float

# Composition
class NormalizedBBox:
  bbox: BBoxBase

class DenormalizedBBox:
  bbox: BBoxBase

Bbox = Union[NormalizedBBox, DenormalizedBBox]

# Inheritance
class NormalizedBBox(BBoxBase):
class DenormalizedBBox(BBoxBase):
  • 런타임 검사를 추가하여 정규화된 Bbox가 실제로 정규화되었는지 확인:
1
2
3
4
class NormalizedBBox(BboxBase):
  def __post_init__(self):
    assert 0.0 <= self.left <= 1.0
    ...
  • 두 타입 간의 변환 방법을 추가. 어떤 곳에서는 명시적인 표현을 알고 싶지만, 다른 곳에서는 일반 인터페이스(“모든 타입의 BBox”)로 작업하고 싶을 수도 있습니다. 이 경우 ‘모든 BBox’를 두 가지 표현 중 하나로 변환할 수 있어야 합니다:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class BBoxBase:
  def as_normalized(self, size: Size) -> "NormalizeBBox":
  def as_denormalized(self, size: Size) -> "DenormalizedBBox":

class NormalizedBBox(BBoxBase):
  def as_normalized(self, size: Size) -> "NormalizedBBox":
    return self
  def as_denormalized(self, size: Size) -> "DenormalizedBBox":
    return self.denormalize(size)

class DenormalizedBBox(BBoxBase):
  def as_normalized(self, size: Size) -> "NormalizedBBox":
    return self.normalize(size)
  def as_denormalized(self, size: Size) -> "DenormalizedBBox":
    return self

이 인터페이스를 사용하면 정확성을 위해 분리된 타입과 편의성을 동시에 취하는 통합된 인터페이스라는 두 가지 장점을 모두 누릴 수 있습니다.

참고: 부모/베이스 클래스에 해당 클래스의 인스턴스를 반환하는 일부 공유 메서드를 추가하려면 Python 3.11부터 typing.Self를 사용할 수 있습니다:

1
2
3
4
5
6
7
8
9
class BBoxBase:
  def move(self, x: float, y: float) -> typing.Self: ...

class NormalizedBBox(BBoxBase):
  ...

bbox = NormalizedBBox(...)
# The type of `bbox2` is `NormalizedBBox`, not just `BBoxBase`
bbox2 = bbox.move(1, 2)

더 안전한 뮤텍스

Rust의 뮤텍스와 잠금은 일반적으로 두 가지 이점이 있는 매우 멋진 인터페이스 뒤에 제공됩니다:

  • 뮤텍스를 잠그면 guard 객체가 반환되며, 이 객체가 파괴되면 유서 깊은 RAII 메커니즘을 활용하여 뮤텍스의 잠금을 자동으로 해제합니다: 
1
2
3
4
{
  let guard = mutex.lock(); // locked here
  ...
} // automatically unlocked here

즉, 실수로 뮤텍스 잠금을 해제하는 것을 잊어버릴 수 없습니다. C++에서도 매우 유사한 메커니즘이 일반적으로 사용되지만, guard 객체가 없는 명시적 lock/unlock 인터페이스는 std::mutex에도 사용할 수 있으므로 여전히 잘못 사용될 수 있습니다.

  • 뮤텍스에 의해 보호되는 데이터는 뮤텍스(구조체)에 직접 저장됩니다. 이 설계에서는 뮤텍스를 실제로 잠그지 않고는 보호된 데이터에 액세스할 수 없습니다. guard를 얻으려면 먼저 뮤텍스를 잠근 다음 guard 자체를 사용하여 데이터에 액세스해야 합니다:
1
2
3
let lock = Mutex::new(41); // Create a mutex that stores the data inside
let guard = lock.lock().unwrap(); // Acquire guard
*guard += 1; // Modify the data using the guard

이는 뮤텍스와 뮤텍스가 보호하는 데이터가 분리되어 있어 데이터에 액세스하기 전에 뮤텍스를 실제로 잠그는 것을 쉽게 잊어버릴 수 있는 Python을 비롯한 주류 언어의 일반적인 뮤텍스 API와는 완전히 대조적인 방식입니다:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
mutex = Lock()

def thread_fn(data):
    # Acquire mutex. There is no link to the protected variable.
    mutex.acquire()
    data.append(1)
    mutex.release()

data = []
t = Thread(target=thread_fn, args=(data,))
t.start()

# Here we can access the data without locking the mutex.
data.append(2)  # Oops

Python에서 Rust에서와 똑같은 이점을 얻을 수는 없지만 모든 이점을 잃은 것은 아닙니다. Python 잠금은 컨텍스트 관리자 인터페이스를 구현하므로 with 블록에서 잠금을 사용하여 범위가 끝날 때 자동으로 잠금이 해제되도록 할 수 있습니다. 그리고 약간의 노력만 더하면 더 대단한걸 할 수 있습니다:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
import contextlib
from threading import Lock
from typing import ContextManager, Generic, TypeVar

T = TypeVar("T")

# Make the Mutex generic over the value it stores.
# In this way we can get proper typing from the `lock` method.
class Mutex(Generic[T]):
  # Store the protected value inside the mutex 
  def __init__(self, value: T):
    # Name it with two underscores to make it a bit harder to accidentally
    # access the value from the outside.
    self.__value = value
    self.__lock = Lock()

  # Provide a context manager `lock` method, which locks the mutex,
  # provides the protected value, and then unlocks the mutex when the
  # context manager ends.
  @contextlib.contextmanager
  def lock(self) -> ContextManager[T]:
    self.__lock.acquire()
    try:
        yield self.__value
    finally:
        self.__lock.release()

# Create a mutex wrapping the data
mutex = Mutex([])

# Lock the mutex for the scope of the `with` block
with mutex.lock() as value:
  # value is typed as `list` here
  value.append(1)

이 설계를 사용하면 뮤텍스를 실제로 잠근 후에만 보호된 데이터에 액세스할 수 있습니다. 물론 이것은 여전히 Python이므로 뮤텍스 외부에 보호된 데이터에 대한 다른 포인터를 저장하는 등의 방법으로 불변성을 깨뜨릴 수 있습니다. 그러나 적대적으로 행동하지 않는 한, Python의 뮤텍스 인터페이스는 사용하기에 훨씬 더 안전합니다.

어쨌든, 제가 Python 코드에서 사용하는 “건전성 패턴”이 더 있을 거라고 확신하지만, 현재로서는 이것이 제가 생각할 수 있는 전부입니다. 비슷한 아이디어의 예가 있거나 다른 의견이 있으시면 댓글을 달아주세요.

  1. 공평하게 말하자면, 문서 주석의 매개변수 타입에 대한 설명에서 구조화된 형식(예: reStructuredText)을 사용하는 경우에도 마찬가지일 수 있습니다. 이 경우 타입 검사기가 이를 사용하여 타입이 일치하지 않는 경우 경고를 표시할 수 있습니다. 하지만 어쨌든 타입 검사기를 사용한다면 타입을 지정하는 “네이티브” 메커니즘인 타입 힌트를 활용하는 것이 더 좋을 것 같습니다.
  2. 일명 discriminated/tagged unions, sum types, sealed classes 등입니다.
  3. newtype에는 여기에 설명된 것 이외의 다른 사용 사례도 있습니다.
  4. 이를 타입 상태 패턴이라고 합니다 (typestate pattern).
  5. 예를 들어 마법의 exit 메서드를 수동으로 호출하는 등 열심히 노력하지 않는 한 말입니다.
Related Posts