Python 은 왜 switch 문장의 원리 에 대한 상세 한 설명 을 지원 하지 않 습 니까?

이 글 에서 우 리 는 왜 Python 이 switch 문 구 를 지원 하지 않 기로 결 정 했 는 지 에 대해 이야기 할 것 이다.
왜 이 얘 기 를 하고 싶 으 세 요?
주로 switch 는 다른 언어 에서 너무 흔히 볼 수 있 지만 Python 은 지원 하지 않 기 때문에 이러한 독특 성 자체 가 주목 할 만하 다.이 질문 에 대답 하면 Python 이 프로그램 디자인 에서 의 이념 을 더욱 잘 보고 Python 이 문법 디자인 에서 의 결정 과정 을 이해 할 수 있다.
본 고 는 PEP-275 와 PEP-3103 을 상세 하 게 분석 할 뿐만 아니 라 Python 의 최신 발전 동향(PEP-622),즉 도입 할 수 있 는 패턴 매 칭(pattern matching)문법 도 소개 할 것 이다.이 화제 가 사람들의 시 야 를 넓 혀 switch 문법 에 대해 더욱 전면적 인 인식 을 가지 게 될 것 이 라 고 믿는다.
1.switch 는 무엇 입 니까?
본론 을 시작 하기 전에 switch 가 무엇 인지 먼저 얘 기해 야 합 니 다.
일반적으로 switch 의 문법 형식 은 다음 과 같 습 니 다.

switch(expression){
  case value1:
    //   
    break; //   
  case value2:
    //   
    break; //   
  default: //   
    //   
}

흐름 도 를 사용 하여 대략 다음 과 같다.

그것 의 용법 은 이해 하기 어렵 지 않다.switch 문장의 값 이 어떤 케이스 상황 을 만족 시 키 면 대응 하 는 코드 블록 을 실행 하고 실행 할 때 break 를 만나면 튀 어 나온다.그렇지 않 으 면 다음 케이스 지점 을 계속 실행한다.보통 마지막 에 default 가 지 를 넣 어 바닥 을 파 헤 친다.
대부분의 언어 는 switch 문 구 를 제공 하거나 매우 비슷 한 것 을 제공 합 니 다.예 를 들 어 C/C++자바/Go 등 정적 언어 에서 switch-case 구 조 를 지원 합 니 다.Ruby 에는 비슷 한 케이스-when 구조 가 있 고 셸 언어 에는 비슷 한 케이스-in 구조 가 있 으 며 펄 에는 switch-case-else 가 있 습 니 다.
switch 문장의 장점 은'단일 조건 다 분기'의 선택 구 조 를 지원 하 는 것 입 니 다.if-else 의 2 분 선택 구조 에 비해 어느 때 는 더욱 간결 하고 뚜렷 합 니 다.
그러나 Python 에서 우 리 는 switch-case 나 비슷 한 문법 구 조 를 볼 수 없다.이것 은 왜 일 까?
2.Python 은 왜 switch 를 지원 하지 않 습 니까?
공식 문서 중 한 편의 FAQ 에는 이 문제 가 포함 되 어 있다.

이 문 서 는 몇 가지 제안 을 했 습 니 다.switch/case 의 대체 방안 을 알려 주 었 습 니 다.
ife-elif-else 조건 판단 문 구 를 사용 합 니 다4.567917.사전 을 사용 하여 케이스 값 과 호출 된 함 수 를 매 핑 합 니 다

내 장 된 getattr()를 사용 하여 특정한 대상 호출 방법 을 검색 합 니 다.

파 이 썬 에 switch 문법 을 도입 하 자 는 제안(즉,PEP-275 와 PEP-3103)이 있 었 지만'사격장 테스트 를 어떻게 하 는 지'에 대해 서 는 의견 이 일치 하지 않 았 다.
사격장 테스트,즉 range test 는 무기 탄약 의 기술적 성능 에 대해 각종 테스트 검증 을 하 는 것 을 말 하 며,약물 의 임상 시험 과 마찬가지 로 최종 제품 인도 전의 관건 적 인 테스트 이다.
공식 문서 에서'왜 Python 이 switch 를 도입 하지 않 는 지'에 대한 설명 은 사실상 Python 의 아버지 Guido van Rossum 이 PEP-3103 에서 의 의견 에서 비롯 되 었 다.

출처:Why isn't there a switch or case statement in Python?
A quick poll during my keynote presentation at PyCon 2007 shows this proposal has no popular support. I therefore reject it.
나 는 PyCon 2007 기조 연설 에서 빠 른 여론 조 사 를 한 결과 이 제안 이 광범 위 한 지 지 를 받 지 못 했다 는 것 을 보 여 주 었 다.그래서 나 는 그것 을 거절 했다.
한 마디 로 하면 PEP 제안 이 있 고 문법 실현 도 초기 화 되 었 으 나 핵심 개발 자 들 이 의견 일 치 를 보지 못 한 것 처럼 제안 이 무산 되 었 다.
3.PEP-275 와 PEP-3103 은 뭐라고 했 습 니까?
PEP-3103 은 2006 년 에 제 기 된 것 이 고,PEP-275 는 2001 년 에 제 기 된 것 이다.이들 의 공통점 은 switch 문 구 를 도입 하 는 어떤 필요 성 을 제기 하고 여러 가지 예비 선거 실현 방안 을 분 석 했 지만 결 과 는 모두 거절당 했다 는 것 이다.

출처:https://www.python.org/dev/peps/pep-3103/
그렇다면 핵심 개발 자 들 이 어떤 토론 을 했 는 지 살 펴 보고 파 이 썬 이 switch 구 조 를 실현 하려 면 어떻게 될 지 살 펴 보 자.PS:PEP 에는 다른 내용 도 포함 되 어 있 습 니 다.본 고 는 switch 와 직접 관련 된 부분 만 추출 합 니 다)
PEP-275 가 제시 한 문법 구 조 는 다음 과 같다.

switch EXPR:
  case CONSTANT:
    SUITE
  case CONSTANT:
    SUITE
  ...
  else:
    SUITE

그 중에서 else 가 지 는 선택 할 수 있 습 니 다.그것 이 없 으 면 앞의 가지 가 만족 하지 않 으 면 아무것도 하지 않 습 니 다.또한 케이스 값 constant 은 expr 표현 식 의 형식 이 동적 이기 때문에 서로 다른 형식 을 지원 합 니 다.
PEP-275 는 switch 가 드 롭(fall-through)행 위 를 지원 하지 않도록 하 는 것 도 제안 했다.즉,모든 case 분기 가 서로 독립 적 이 고 완전 하 며 C 언어 처럼 break 를 쓰 지 않 아 도 된다 는 것 이다.
이 PEP 는 또 다른 issue 를 열거 했다.
기 존 키 워드 를 다시 사용 하고'switch'와'case'를 도입 하지 않 습 니 다.

새로운 키 워드 를 사용 하여 C 의 switch 개념 과 헷 갈 리 지 않도록 합 니 다

단일 분기 다 중 값 선택 지원(예 를 들 어 case'a','b','c':...)

4.567917.그리고 지원 범위 의 수치 판단 을 권장 합 니 다(예 를 들 어 케이스 10.14:...)
첫 번 째 방안 을 제외 하고 이 PEP 는 몇 가지 스타일 이 다른 문법 방안 도 기록 했다.

case EXPR:
  of CONSTANT:
    SUITE
  of CONSTANT:
    SUITE
  else:
    SUITE

case EXPR:
  if CONSTANT:
     SUITE
  if CONSTANT:
    SUITE
  else:
    SUITE

when EXPR:
  in CONSTANT_TUPLE:
    SUITE
  in CONSTANT_TUPLE:
    SUITE
  ...
else:
   SUITE

PEP-275 는 많은 중요 한 사고 와 문 제 를 기록 하여 PEP-3103 의 등장 에 좋 은 기반 을 다 져 주 었 다.
그럼 구 이도 가 만 든 PEP-3103 이 무슨 말 을 했 는 지 살 펴 보 자.
이 는 먼저 PEP-275 의 두 가지 기본 설정 을 인정 했다.예 를 들 어'암시 적 인 break'를 실현 하고 케이스 분기 에 fall-through 와 같은 통제 권 이전 상황 이 나타 나 지 않도록 한다(다른 언어 는 모두 break 를 명시 적 으로 써 야 하 는 것 같다).else 가 지 는 선택 할 수 있 습 니 다.else 키 워드 를 다시 사용 합 니 다."default"을 도입 하지 않 아 도 됩 니 다.
PEP-275 가 제창 하 는 스타일 에 대해 Guido 는 비교적 인정 하지만 그 문 제 는 들 여 쓰기 단계 가 너무 많다 고 생각 하기 때문에 코드 분기 들 여 쓰기 의 빈 칸 수 를 줄 이 는 것 을 권장 합 니 다.예 를 들 어 원래 4 빈 칸 을 들 여 쓰기 2 빈 칸 으로 바 꾸 는 것 입 니 다.
PEP-3103 은 또 다른 세 가지 실현 방안 을 열거 하여 그들의 차이 와 문 제 를 분 석 했 고 구체 적 인 내용 은 생략 했다.여 기 는 그들의 스타일 만 보 여 주 었 다.

# case      
switch EXPR:
case EXPR:
  SUITE
case EXPR:
  SUITE
....
else:
  SUITE

# switch        
switch EXPR
case EXPR:
  SUITE
case EXPR:
  SUITE
....
else:
  SUITE

#    case    
switch EXPR:
  EXPR:
    SUITE
  EXPR:
    SUITE
  ...
  else:
    SUITE

기본 문법 외 에 Guido 는 확장 문법(Extended Syntax),즉 하나의 case 분기 에서 여러 값 과 일치 하 는 복잡 한 상황 을 토론 하 는 데 많은 지면 을 썼 다.
case EXPR, EXPR, ...:
\#Guido 우선 선택
case in EXPR_LIST:
case *EXPR:
case [*]EXPR, [*]EXPR, ...:
case *(EXPR, EXPR, ...):
그 가 중점적으로 고려 한 문 제 는 switch 에서 표현 식 의 결 과 는 원 그룹 이나 교체 가능 한 대상 의 경우,case 의 값 이 원 그룹 으로 보 여 지 는 경우,case 지점 에서"*"별표 작업 을 하 는 경우 등 이다.
이 어 Guido 는 switch 를 어떻게 실현 해 야 하 는 지 를 매우 많은 지면 으로 분석 했다.그 중에서 토론 한 주요 방향 은 다음 과 같다.
4.567917.등가 의 if-elif 체인 을 사용 하여 switch 문 구 를 정의 합 니 다(최적화 할 수 있 습 니 다)

위 와 같이 모든 표현 식 은 해시(hashable)여야 합 니 다

사전에 계 산 된 사전 의 분파(dispatch)로 간주한다

PEP 에서 이 부분의 내용 은 매우 많다.모든 사고방식 에서 Guido 는 여러 가지 실현 경 로 를 고려 했 기 때문에 복잡 한 분석 을 한 후에 그 는 It is too early to decide(지금 결정 하기 에는 시기상조)라 는 결론 을 내 렸 다.
PEP-3103 을 읽 은 후에 저 는 전체적인 느낌 은 Guido 의 사고 방향 이 매우 발산 되 고 차원 이 풍부 하지만 그 가 다른 문제 에 직면 할 때'날 카 로 운 칼 로 난마'식 의 통찰력 이 부족 하 다 는 것 입 니 다.
여러 가능성 방안 에서 그 는 주도면밀 하 게 노력 했 지만 결국 자신 이 독재 적 인 결정 을 내리 도록 설득 할 수 없 었 다 는 것 이다.저항력 은 주로 다른 사람 이 아니 라 그 자신 에 게 서 나온다.
그러나 이런 상황 이 발생 한 것 은 그의 예비 입장 과 관련 이 있 을 지도 모른다.그 는'Python is fine without a switch statement'이 라 고 생각 하 는 것 같 아서 긴 PEP 를 썼 지만 문 제 를 복잡 하 게 만 들 고 의 제 를 방치 하고 있 을 뿐이다.
마지막 으로 그 는 피 콘 에서 작은 범위 의 조 사 를 했 는데 이 를 통 해 자신 이 발기 한 PEP 를'명분 순'하 게 거절 하고 사람들의 유유 한 입 을 막 으 려 고 했다.
4.미래 에 switch 문구 가 있 을까요?
요약 하면 Python 에 switch 문구 가 없 는 이 유 는 switch 의 실현 디 테 일/기능 점 이 확정 되 지 않 았 고 switch 가 없 는 것 도 좋 습 니 다.switch,Guido 의 작은 임 의 를 대체 하 는 다른 좋 은 방법 이 있 기 때 문 입 니 다.
하지만 미래 에 switch 문구 가 있 을 까?아니면 비슷 한 다 분기 선택 구조?
왜 그런 질문 을 해 야 합 니까?그 이 유 는 자체 적 으로 switch 문 구 를 가 진 언어 가 너무 많 고 switch 기능 을 제공 하 는 라 이브 러 리 를 만 들 려 고 하 는 사람 도 많 기 때 문 입 니 다.
저(Python 고양이)는 처음부터 끝까지 switch 를 좋아 하지 않 습 니 다.Python 은 미래 에 도 switch 가 없 을 것 이 라 고 확신 할 수 있 습 니 다.그러나 switch 와 유사 하고 더욱 복잡 한 문법 구 조 를 도입 할 수 있 습 니 다!
2020 년 6 월 PEP-622 는 스칼라,에 를 랑,러 스 트 등 언어 에서 패턴 매 칭 문법(pattern matching)을 도입 할 것 을 제안 했다.

2020 년 10 월 까지 이 PEP 는 다른 3 개 PEP(634-636)로 분 해 돼 현재 초안 단계 다.핵심 개발 자 들 의 참여 상황 과 화제 토론 상황 을 고려 하면 이런 제안 들 은 미래 버 전(예 를 들 어 개발 중인 3.10)에서 실 현 될 가능성 이 높다.
평균 수 를 구 하 는 함 수 를 예 로 들 면 패턴 일치 문법 은 이렇게 실 현 될 수 있다.

def average(*args):
  match args:
    case [x, y]:      # captures the two elements of a sequence
      return (x + y) / 2
    case [x]:       # captures the only element of a sequence
      return x
    case []:
      return 0
    case x:        # captures the entire sequence
      return sum(x) / len(x)

match-case 구 조 는 switch-case 구조 와 비슷 하지만 표현 식(expression)이 아 닌 패턴(pattern)을 기반 으로 하기 때문에 더 많은 고려 해 야 할 세부 적 인 문제 도 있 고 더 넓 은 응용 공간 도 있다.
이 화제 에 관심 이 있 는 독자 들 은 이 몇 개의 새로운 PEP 를 찾 아 볼 것 을 건의 합 니 다.
마지막 으로 제목 의 문제 로 돌아 갑시다. Python 은 왜 switch 문 구 를 지원 하지 않 습 니까?
공식 문서 의 FAQ 는 이 문제 에 대한 해답 이 있 습 니 다.우리 에 게 몇 가지 좋 은 대체 문법 이 있 는 지 알려 주 는 동시에 하나의 단 서 를 남 겼 습 니 다.PEP 가 switch 를 도입 하 자고 제 안 했 지만 성공 적 으로 실현 되 지 못 했 습 니 다.
이 단 서 를 따라 본 고 는 PEP-275 와 PEP-3103 이라는 두 문 서 를 분해 하여 Python 커 뮤 니 티 에서 제 시 된 스타일 이 서로 다른 switch 방안 과 많은 현안 을 보 여 주 었 다.
이상 이 바로 본 고의 모든 내용 입 니 다.여러분 의 학습 에 도움 이 되 고 저 희 를 많이 응원 해 주 셨 으 면 좋 겠 습 니 다.