Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

PEP 3099 – Python 3000에서 바뀌지 않을 것들

Author:
Georg Brandl <georg at python.org>
Status:
Final
Type:
Process
Created:
04-Apr-2006
Post-History:

Table of Contents

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

초록

어떤 아이디어는 그냥 나쁩니다. Python의 발전에 관한 생각 중 일부는 건설적이지만, 어떤 것들은 Python의 기본 원칙에 너무나 심하게 어긋나서 누군가에게 제자리에서 빙빙 돌며 달리라고 요구하는 것과 같습니다. 파격적인 제안이 허용되는 Python 3000에서조차 아무 데에도 이르지 못합니다. 이 PEP는 일어나지 않을 변경과 도입되지 않을 새 기능에 관한 Python 3000에 대한 BDFL의 모든 선언을 주제별로 정리하여, 짧은 설명이나 python-3000 메일링 리스트의 관련 스레드에 대한 참조와 함께 나열하려고 합니다.

나열된 아이디어 중 어느 것이라도 제안해야겠다고 생각한다면, 그냥 컴퓨터에서 물러나 밖으로 나가 즐거운 시간을 보내는 편이 낫습니다. 이미 끝난 아이디어를 다시 꺼냈다가 그 아이디어가 얼마나 철저히 끝났는지 사람들에게 듣는 것보다, 밖에 나가 멋진 잔디 패치 위에서 낮잠을 자는 편이 더 생산적입니다. 미리 경고해 둡니다.

핵심 언어

  • Python 3000은 대소문자를 구분하지 않는 언어가 되지 않을 것입니다.
  • Python 3000은 처음부터 다시 작성되지 않을 것입니다.
    또한 구현 언어로 C++이나 C가 아닌 다른 언어를 사용하지도 않을 것입니다. 그 대신 코드베이스가 점진적으로 탈바꿈할 것입니다. 그 이유를 설명하는 Joel Spolsky의 훌륭한 에세이가 있습니다: http://www.joelonsoftware.com/articles/fog0000000069.html
  • self는 암묵적인 것으로 바뀌지 않을 것입니다.
    self를 명시적으로 두는 것은 좋은 일입니다. 변수가 어떻게 결정되는지에 대한 모호함을 없애 코드를 명확하게 만듭니다. 또한 함수와 메서드 사이의 차이를 작게 만듭니다.

    스레드: “Draft proposal: Implicit self in Python 3.0” https://mail.python.org/pipermail/python-dev/2006-January/059468.html

  • lambda의 이름은 바뀌지 않을 것입니다.
    한때 lambda는 Python 3000에서 제거될 예정이었습니다. 안타깝게도 익명 함수를 제공하는 더 나은 방법을 아무도 생각해 내지 못했습니다. 그래서 lambda는 계속 남게 되었습니다.

    하지만 지금 모습 그대로 남습니다. 문(statement) 지원을 추가하는 것은 고려할 가치도 없습니다. 그렇게 하려면 여러 줄 lambda 식을 허용해야 하는데, 이는 곧 여러 줄 식이 갑자기 존재할 수 있게 된다는 뜻입니다. 예를 들어 함수 호출에 여러 줄 인자를 쓸 수 있게 됩니다. 그것은 그야말로 보기 흉합니다.

    스레드: “genexp 문법 / lambda”, https://mail.python.org/pipermail/python-3000/2006-April/001042.html

  • Python은 프로그래밍 가능한 문법을 갖지 않을 것입니다.
    스레드: “문장입니다! 함수입니다! 둘 다입니다!”, https://mail.python.org/pipermail/python-3000/2006-April/000286.html
  • zip() 스타일의 병렬 반복을 위한 문법은 없을 것입니다.
  • 문자열은 계속 이터러블로 남을 것입니다.
    스레드: “문자열을 이터러블이 아니게 만들기”, https://mail.python.org/pipermail/python-3000/2006-April/000759.html
  • 제너레이터 표현식이나 리스트 컴프리헨션의 결과를 정렬하는 문법은 없을 것입니다. sorted()가 모든 사용 사례를 다룹니다.
    스레드: “제너레이터 컴프리헨션에 정렬 추가하기”, https://mail.python.org/pipermail/python-3000/2006-April/001295.html
  • 슬라이스와 확장 슬라이스는 사라지지 않으며(__getslice__ 및 __setslice__ API는 대체될 수 있더라도), 표준 객체 타입에 대해 뷰를 반환하지도 않을 것입니다.
  • 루프 본문 안에서 루프 변수를 재사용하는 것은 금지되지 않을 것입니다.
    스레드: 이터레이션 변수의 스코프 누출 제거 https://mail.python.org/pipermail/python-dev/2006-May/064761.html
  • 파서는 LL(1)보다 복잡해지지 않을 것입니다.
    단순한 것이 복잡한 것보다 낫습니다. 이 생각은 파서에도 적용됩니다. Python의 문법을 LL(1) 파서로 제한하는 것은 저주가 아니라 축복입니다. 이 제한은 우리에게 수갑을 채워, 우리가 도를 넘어 굳이 이름을 밝히지 않을 몇몇 다른 동적 언어들(예컨대 Perl)처럼 기이한 문법 규칙을 갖게 되는 일을 막아 줍니다.
  • 중괄호는 없습니다.
    이것은 너무나 자명하여 메일링 리스트를 참조할 필요도 없습니다. 이 주제에 대한 확정적인 답을 얻으려면 from __future__ import braces를 실행하십시오.
  • 역따옴표는 더 이상 없습니다.
    역따옴표(`)는 더 이상 repr의 약칭으로 사용되지 않을 것입니다 – 하지만 그렇다고 해서 다른 용도로 사용할 수 있다는 뜻은 아닙니다. 하위 호환성으로 인한 혼란을 무시하더라도, 이 문자 자체가 너무 많은 문제를 일으킵니다(일부 글꼴에서, 일부 키보드에서, 책을 조판할 때 등).

    스레드: “역따옴표를 이용한 새 연산자”, https://mail.python.org/pipermail/python-ideas/2007-January/000054.html

  • 전역 이름 foo를 참조할 때 globals.foo로 쓰게 되지는 않을 것입니다. global 문은 유지됩니다.
    스레드: “globals()와 global 문을 전역 내장 객체로 대체하기”, https://mail.python.org/pipermail/python-3000/2006-July/002485.html, “명시적 어휘적 스코핑(PEP 초안?)”, https://mail.python.org/pipermail/python-dev/2006-July/067111.html
  • :=와 같은 대체 바인딩 연산자는 없을 것입니다.
    스레드: “명시적 어휘적 스코핑(PEP 초안?)”, https://mail.python.org/pipermail/python-dev/2006-July/066995.html
  • 컨테이너 리터럴은 제거되지 않을 것입니다. 즉, {expr: expr, …}, [expr, …], (expr, …)는 그대로 유지됩니다.
    스레드: “컨테이너 리터럴 없음”, https://mail.python.org/pipermail/python-3000/2006-July/002550.html
  • while 및 for 루프의 else 절은 의미가 바뀌지 않으며 제거되지도 않습니다.

내장 함수

표준 타입

코딩 스타일

대화형 인터프리터