Hacker News 의견

• 다양한 언어들이 문자열 포맷팅을 다루는 방식이 흥미로움

  • Java는 f/t-strings를 추가하려고 노력 중이나, 모든 문제를 해결하려는 완벽주의로 인해 어려움을 겪고 있음
  • Go 개발자들은 이 문제를 거의 고려하지 않고 무시한 것으로 보임
  • Python은 균형 잡힌 접근 방식을 취해 새로운 문자열 포맷팅 방법을 논의하고 적절한 구현을 선택해 사용 중임
  • Python의 접근 방식에 동의하지 않을 수 없으며, .format(), f-strings, t-strings를 통해 가치를 얻고 있음

• Nick Humrich는 PEP 501을 재작성하여 t-strings를 도입한 저자 중 한 명이며, 이 PEP의 수용에 매우 기뻐하고 있음

  • 4년 전부터 PEP 501 작업을 시작했음

• 언어 수준의 기능이 가치 있는지 확신하지 못함

  • f-string을 반환하는 함수로 같은 결과를 얻을 수 있음
  • 주입 안전성을 원한다면 태그 타입과 문자열을 반환하는 정화 함수를 사용하면 됨
  • 간결하지만, 단일 문자로 즉시 실행과 지연 실행을 구분하는 것은 Python에 익숙하지 않은 사람들에게 읽기 어려움을 줄 수 있음

• f-strings를 좋아하지만, 평가를 지연할 수 없는 문제가 있음

  • str.format을 사용해야 하는 경우가 있어 불편함

• lit-html의 유지보수자로서 JavaScript의 태그 템플릿 리터럴과 유사한 점이 흥미로움

  • Python의 Template 클래스가 JavaScript의 태그 함수와 인수를 분리하는 방식이 독특함
  • 중첩된 템플릿 구조에서 html() 함수가 필요하지 않을 수 있음

• JavaScript의 태그 템플릿 리터럴이 HTML 자동 이스케이프나 SQL 매개변수화에 도움이 되는 점이 Python에도 적용될 것 같아 기대됨

• Python이 PHP로 변하는 것 같다는 의견

  • f-strings와 t-strings가 언어에 복잡성을 더함
  • string.format이 최적이라고 생각하며, %도 오랫동안 사용되어 온 만큼 수용 가능함
  • 언어 팀이 더 중요한 것에 집중하길 바람

• 언어에 계속해서 새로운 것을 추가하는 것에 대한 불만

  • 언어가 위원회에 의해 설계된 것처럼 느껴짐

• 이 PEP가 C++의 P1819와 유사하다는 의견

• PEP의 코드가 너무 장황하다는 의견

  • Python이 실행 가능한 의사 코드가 아닌 과도한 불필요함을 표현하는 것 같음
  • Ruby의 코드와 비교하여 Python 코드가 더 장황함