새로운:개발 일지/파이썬 타입 힌팅을 본격적으로 도입 해 본 후기

목차

1. 개요
1.1. 장점
1.1.1. 타입 헷갈려서 오는 문제를 미리 잡아줌
1.1.2. Null 문제도 잡아줌
1.1.3. 변수의 요상한 재사용을 막아줌
1.2. 단점
1.2.1. 인터프린터 언어의 장점을 깎아먹음
1.2.1.1. 쓰면서 그냥 컴파일 언어 쓰는 게 더 좋지 않나 이런 생각 듬
1.2.2. 코드가 더러워짐(...)
1.2.3. 애초에 TDD 계획을 정상으로 세워놨으면 잡힐 문제가 많음
1.2.4. 외부 라이브러리 문제는 못 잡음
2. 그 외
3. 기타

1. 개요 _{✎ ⊖}

edit_delete_file부터 타입 힌팅을 도입한 이후로 새로 짜는 코드에는 타입 힌팅을 본격적으로 도입하고 있다. 그러한 과정에서 얻는 장단점을 서술하는 공간이다. 추가로 타입 체크는 mypy를 이용해서 하고 있다.

1.1. 장점 _{✎ ⊖}

1.1.1. 타입 헷갈려서 오는 문제를 미리 잡아줌 _{✎ ⊖}

data = "test"
for for_a in range(0, 10):
    data += for_a

예를 들자면 이런 문제

1.1.2. Null 문제도 잡아줌 _{✎ ⊖}

data = re.search(r"(test)", main_data)
data = data.groups(1) # 만약 re.search에서 None이 나왔다면 오류 뜨는 데 미리 잡아줌

예를 들자면 이런 문제

1.1.3. 변수의 요상한 재사용을 막아줌 _{✎ ⊖}

db_data = "test"
db_data = 3

이런 난잡함을 미연에 막아준다. 예를 들면 이런 버그⁽¹⁾

1.2. 단점 _{✎ ⊖}

1.2.1. 인터프린터 언어의 장점을 깎아먹음 _{✎ ⊖}

인터프린터 언어의 장점은 빠르게 실행해서 TDD 실행하는 것에 있다고 생각하는 데 이렇게 미리 타입 체킹을 하니 컴파일 하는 것 만큼 느려져서... 가장 큰 장점이 사라지는 것 같은 기분이 있음⁽²⁾

1.2.1.1. 쓰면서 그냥 컴파일 언어 쓰는 게 더 좋지 않나 이런 생각 듬 _{✎ ⊖}

변수에 전부 타입 명시하면서 갑자기 든 생각이 이럴꺼면 Golang으로 다시 짜는 게 빠르지 않을까...라는 허무함이 있음

1.2.2. 코드가 더러워짐(...) _{✎ ⊖}


전	후

이런 오브젝트 기반 변수들은 유니온으로 묶어야하는데 유니온으로 묶으니 쓸 때 없이 길어지는 기분임

1.2.3. 애초에 TDD 계획을 정상으로 세워놨으면 잡힐 문제가 많음 _{✎ ⊖}

애초에 상단에 저런 타입 헷갈려서 생기는 문제는 한번이라도 동작 시켜보면 바로 잡히는 문제들이라서... 이게 필요한가 아리송한 기분이 있음⁽³⁾

1.2.4. 외부 라이브러리 문제는 못 잡음 _{✎ ⊖}

curs.execute(db_change('select set_code from bbs_data'))
db_data : list[tuple[str]] = curs.fetchall()
print(db_data[0][0]) # db_data가 None일 수도 있는데 별 말이 없다...

2. 그 외 _{✎ ⊖}

⁽⁴⁾
나쁘진 않은 것 같은데... 자바스크립트야 타입스크립트가 뜬 이유가 자바스크립트 언어 설계가 메롱해서 그렇다⁽⁵⁾치지만 파이썬은 강력한(strong) 타입 검사를 하는 지라 타입으로 일어날 오류는 한번 실행하면 딱 견적이 나온다⁽⁶⁾

그래서... 암만 생각해도 필요성이 아리송하다. 인공지능 같은 한번 실행에 굉장히 오래 걸리는 프로그램이라면 그럴만 한데 오픈나무가 그런가?에 대해서는 좀 의문이다. 좀 더 고민해볼 필요가 있는 것 같다.

3. 기타 _{✎ ⊖}

파이썬 3.9에서 3.10으로 발전

파이썬 3.10에서 3.11으로 발전

참고로 기본적으로 파이썬 3.11을 사용해서 이전 파이썬들에 비해서 오류 설명을 좀 더 잘 복잡하고 정확하게 집어줘서 이런 생각이 드는 것도 있지 않을까 생각한다.

(1) 사실 파이썬에서 const를 지원해주면 좋겠는데... 여러 방법을 사용해도 재할당을 막아주질 않는다. 그래서 결국 mypy로 잡는 수 밖에 없다.
(2) 실행, 동작에 문제 없는 것도 왜 하는 잔소리인 지는 알겠지만... 계속 잔소리를 하니 좀 피곤함 생산성이 내려가는 기분임
(3) 물론 코드가 길고 복잡하면 버그 찾는 데 도움이 되겠지만... 그건 코드 분리를 고민해봐야 하는 시점이 아닐까...? 라는 생각이 있음
(4) 여기서 C랑 C++은 강력한(strong) 타입이라는 의견이 있다. 이는 선언마다 오락가락하는 것 같다.
(5) 동적 타입 언어인데 심지어 느슨한(weak) 타입 검사를 하는 바람에 쉽게 오류 만들기 딱 좋은 환경이다. 비슷한 언어로 PHP가 있다.
(6) 그 유명한 누구나 한번 쯤 보는 TypeError

1. 개요 ✎ ⊖

1.1. 장점 ✎ ⊖

1.1.1. 타입 헷갈려서 오는 문제를 미리 잡아줌 ✎ ⊖

1.1.2. Null 문제도 잡아줌 ✎ ⊖

1.1.3. 변수의 요상한 재사용을 막아줌 ✎ ⊖

1.2. 단점 ✎ ⊖

1.2.1. 인터프린터 언어의 장점을 깎아먹음 ✎ ⊖

1.2.1.1. 쓰면서 그냥 컴파일 언어 쓰는 게 더 좋지 않나 이런 생각 듬 ✎ ⊖

1.2.2. 코드가 더러워짐(...) ✎ ⊖

1.2.3. 애초에 TDD 계획을 정상으로 세워놨으면 잡힐 문제가 많음 ✎ ⊖

1.2.4. 외부 라이브러리 문제는 못 잡음 ✎ ⊖

2. 그 외 ✎ ⊖

3. 기타 ✎ ⊖