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는 계속 남습니다.

    그러나 현재 형태 그대로 남습니다. 문 지원을 추가하는 것은 애초에 고려할 수 없습니다. 여러 줄 lambda 표현식을 허용해야 하며, 그러면 여러 줄 표현식이 갑자기 존재할 수 있게 됩니다. 예를 들어 함수 호출에 여러 줄 인자를 사용할 수 있게 됩니다. 그것은 정말 보기 흉합니다.

    스레드: “genexp syntax / 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-March/000210.html
  • 문자열은 계속 이터러블로 유지됩니다.
    스레드: “문자열을 이터러블이 아니게 만들기”, 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 절은 의미를 변경하지 않으며 제거되지도 않습니다.

내장 기능

표준 타입

코딩 스타일

대화형 인터프리터