Hacker News 의견

• Python의 기본 텍스트 파일 인코딩이 플랫폼에 따라 다른 것은 오랫동안 문제였음
• 파일 시스템 인코딩 문제는 별개이며, 이번 변경에서는 다루지 않음
• 시스템 기본값에 의존하는 것은 좋지 않음. 가정과 달라질 수 있기 때문
• 과거 우분투와 init.d 스크립트에서 문제가 있었음. 루트로 실행되는 Java 실행 스크립트가 일반 사용자와 다른 인코딩을 사용하여 문제 발생
• 요즘은 덜 문제지만, OS에 이를 맡기는 것은 피해야 함. UTF-8 외 인코딩 사용은 의도치 않은 경우일 가능성이 높음
• 명시적으로 지정하지 않고 OS 설정에 의존하는 것은 좋지 않음
• 이번 변경은 좋은 방향. 깨지는 코드는 간단히 수정하는 게 나음
• 내용 손상 버그의 가능성이 있는 상태로 두는 것보다 낫다고 봄

최근 수십 년 동안 점점 더 사실이 되어 가는 경험칙: "charset" 설정이 UTF-8이 아니라면 잘못된 것임

• Python 2는 charset에 구애받지 않아 항상 잘 동작했지만, Python 3의 개선은 개선 그 이상이었음

• Python 3 스크립트와 Python 2 스크립트를 구분하는 방법:

  • "utf-8" 문자열이 있으면 Python 3
  • C.UTF-8 로케일에서만 동작하면 Python 3

• 이번 변경은 환영할 만한 것이며, Python 3를 "개선"할 것으로 보임

• Python 3부터 기본값이었다고 생각했음

Node.js, Go, Rust, Java를 포함한 많은 인기 언어들이 기본적으로 UTF-8을 사용함

• Java가 UTF-16에서 UTF-8로 옮겨간 것은 몰랐음

• CPython의 내부 인코딩이 UTF-8인지는 모르겠음

• Python 문자열은 인덱싱이 가능하지만 임의 접근은 드물기에 필요할 때 지연 인덱싱하는 게 좋을 듯

• 한 칸씩 앞뒤로 이동만 하면 인덱스가 필요 없음

• 따라서 내부적으로 UTF-8 표현이 가능할 것으로 보임

• 왜 utf-8-sig가 아닌지? BOM을 선택적으로 처리해주는데 유용함

• UTF-8과 관련하여, 리눅스 프레임버퍼는 오래전부터 제대로 된 UTF-8 지원이 있었어야 함

• GNU Hurd는 2007년경부터 UTF-8을 지원하는 더 나은 '터미널 콘솔'을 가지고 있었음

• 2024년인 지금에야 이런 변화가 오다니

• 좋은 변화. 이제 JS만 UTF-8로 전환하면 되는데, 1995년에 쓰인 코드와 호환되어야 하기에 개선이 어려움

많은 유닉스 Python 개발자들이 기본 인코딩이 플랫폼마다 다르다는 걸 잊고, UTF-8 텍스트 파일을 읽을 때 encoding="utf-8"을 명시하지 않음

• "잊는다"라기보다는 제대로 인지하지 못하는 것 같음
• 명시적으로 요청하지 않는 한 Python이 모든 곳에서 UTF-8만 사용할 거라 생각했음