PEP 238 – 나눗셈 연산자 변경

Author:: Moshe Zadka <moshez at zadka.site.co.il>, Guido van Rossum <guido at python.org>
Status:: Final
Type:: Standards Track
Created:: 11-Mar-2001
Python-Version:: 2.2
Post-History:: 16-Mar-2001, 26-Jul-2001, 27-Jul-2001

Table of Contents

번역·라이선스 안내

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

초록

현재의 나눗셈(/) 연산자는 숫자 인자에 대해 모호한 의미를 가집니다. 인자가 int나 long이면 나눗셈의 수학적 결과를 내림(floor)한 값을 반환하지만, 인자가 float나 complex이면 나눗셈 결과의 합리적인 근삿값을 반환합니다. 이 때문에 정수가 입력으로 예상되지는 않지만 들어올 수는 있는 경우, float나 complex 결과를 기대하는 표현식에서 오류가 생기기 쉽습니다.

저희는 서로 다른 연산에 서로 다른 연산자를 도입하여 이 문제를 해결할 것을 제안합니다. x/y는 나눗셈의 수학적 결과에 대한 합리적인 근삿값을 반환하고(“참 나눗셈(true division)”), x//y는 내림한 값을 반환합니다(“내림 나눗셈(floor division)”). 저희는 x/y의 현재의 혼합된 의미를 “고전적 나눗셈(classic division)”이라고 부릅니다.

c.l.py에서 벌어진 대규모 논쟁은 말할 것도 없고 심각한 하위 호환성 문제 때문에, 저희는 다음과 같은 과도기적 조치를 제안합니다(Python 2.2부터 시작합니다).

Python 2.x 시리즈에서는 고전적 나눗셈이 계속 기본값으로 유지되며, Python 3.0에서는 참 나눗셈이 표준이 됩니다.
내림 나눗셈을 모호함 없이 요청할 수 있도록 // 연산자를 제공합니다.
from __future__ import division으로 표기하는 future division 문은 모듈 전체에서 / 연산자가 참 나눗셈을 의미하도록 바꿉니다.
한 명령줄 옵션은 int나 long 인자에 적용된 고전적 나눗셈에 대해 실행 시간 경고를 활성화하고, 다른 명령줄 옵션은 참 나눗셈을 기본값으로 만듭니다.
표준 라이브러리는 고전적 나눗셈을 완전히 피하기 위해, 적절한 경우 future division 문과 // 연산자를 사용합니다.

동기

고전적 나눗셈 연산자 때문에 임의의 숫자 입력에 대해 올바른 결과를 내야 하는 수치 표현식을 작성하기가 어렵습니다. 다른 모든 연산자에 대해서는 x*y**2 + z와 같은 식을 작성할 수 있으며, 계산된 결과는 어떤 숫자 입력 타입(int, long, float, complex)에 대해서도 수학적 결과에 가깝습니다(물론 수치 정확도의 한계 내에서입니다). 하지만 나눗셈은 문제를 일으킵니다. 두 인자의 표현식이 공교롭게도 모두 정수 타입이면, 참 나눗셈이 아니라 내림 나눗셈을 수행합니다.

이 문제는 동적 타입 언어에만 있는 문제입니다. C와 같은 정적 타입 언어에서는 입력(일반적으로 함수 인자)이 double이나 float로 선언되며, 호출 시 정수 인자를 전달하면 호출 시점에 double이나 float로 변환됩니다. Python에는 인자 타입 선언이 없으므로, 정수 인자가 쉽게 표현식 안으로 섞여 들어올 수 있습니다.

다른 모든 상황에서는 int가 float를 완벽하게 대체하기 때문에 이 문제는 특히 해롭습니다. math.sqrt(2)는 math.sqrt(2.0)과 같은 값을 반환하고, 3.14*100과 3.14*100.0은 같은 값을 반환하는 식입니다. 따라서 수치 루틴의 작성자는 부동 소수점 수만으로 코드를 테스트하고 올바르게 동작한다고 믿을 수 있으며, 사용자는 실수로 정수 입력값을 전달하여 잘못된 결과를 얻을 수 있습니다.

이를 달리 보면, 고전적 나눗셈 때문에 float 인자와 int 인자 모두에서 잘 동작하는 다형적 함수를 작성하기가 어렵다는 것입니다. 다른 모든 연산자는 이미 올바르게 동작합니다. int와 float 모두에서 동작하는 알고리즘 중에 한 경우에는 버림 나눗셈이, 다른 경우에는 참 나눗셈이 필요한 알고리즘은 없습니다.

올바른 우회 방법은 미묘합니다. 인자가 복소수일 수 있다면 float()로 변환하는 것은 잘못이며, 인자에 0.0을 더하면 인자가 음의 0이었을 경우 그 부호가 보존되지 않습니다. 두 가지 단점이 모두 없는 유일한 해결책은 인자(일반적으로 첫 번째 인자)에 1.0을 곱하는 것입니다. 이렇게 하면 float와 complex의 경우 값과 부호가 바뀌지 않으며, int와 long은 해당하는 값을 가진 float로 바뀝니다.

저자들은 이것이 Python의 실제 설계 버그이며, 가능한 한 빨리 수정해야 한다는 의견입니다. Python 사용이 계속 늘어난다고 가정하면, 이 버그를 언어에 남겨 두는 비용은 결국 기존 코드를 수정하는 비용보다 커질 것입니다. 수정해야 할 코드의 양에는 상한이 있지만, 앞으로 이 버그의 영향을 받을 수 있는 코드의 양에는 한계가 없습니다.

이 변경의 또 다른 이유는 궁극적으로 Python의 수치 모델을 통합하려는 바람입니다. 이는 PEP 228의 주제입니다(현재 미완성입니다). 통합된 수치 모델을 사용하면 사용자가 서로 다른 수치 타입을 의식해야 할 필요가 대부분 사라집니다. 이는 초보자에게 좋을 뿐 아니라, 숙련된 프로그래머에게도 서로 다른 수치 동작에 대한 걱정을 덜어 줍니다. (물론 수치 안정성과 정확도에 대한 걱정까지 없애 주지는 않습니다.)

통합 수치 모델에서 서로 다른 타입(int, long, float, complex, 그리고 새로운 유리수 타입 같은 다른 타입이 있을 수도 있습니다)은 주로 저장 최적화 역할을 하며, 어느 정도는 부정확성이나 복소성 같은 직교적 속성을 나타내는 역할도 합니다. 통합 모델에서 정수 1은 (부정확성을 제외하면) 부동 소수점 수 1.0과 구별할 수 없어야 하며, 둘은 모든 수치 문맥에서 똑같이 동작해야 합니다. 분명히 통합 수치 모델에서 a==b이고 c==d이면 a/c는 b/d와 같아야 하며(부정확한 수에 대해서는 반올림 때문에 어느 정도 여유를 둡니다), 1.0/2.0이 0.5와 같다는 데에는 모두가 동의하므로 1/2도 0.5와 같아야 합니다. 마찬가지로 1//2가 0과 같으므로 1.0//2.0도 0과 같아야 합니다.

변형안

미적으로 x//y가 모두를 만족시키지는 못하므로 여러 변형안이 제안되었습니다. 여기에서 그 변형안들을 다룹니다:

x div y. 이는 새로운 키워드를 도입하게 됩니다. div는 흔히 쓰이는 식별자이므로, 새 키워드가 future division 문 아래에서만 인식되는 것이 아니라면 상당한 양의 기존 코드를 망가뜨리게 됩니다. 변환이 필요한 코드의 대부분은 정수를 나누는 코드일 것으로 예상되므로, 이는 future division 문의 필요성을 크게 높이게 됩니다. future 문이 있더라도, 꼭 필요한 경우가 아니면 새 키워드를 추가하지 말아야 한다는 일반적인 정서가 이 방안에 반대하는 근거가 됩니다.
div(x, y). 이는 오래된 코드의 변환을 훨씬 어렵게 만듭니다. x/y를 x//y나 x div y로 바꾸는 일은 간단한 질의 치환(query replace)으로 할 수 있습니다. 대부분의 경우 프로그래머는 특정 모듈이 정수만 다룬다는 것을 쉽게 확인할 수 있으므로 x/y가 나오는 모든 곳을 바꿀 수 있습니다. (주석이나 문자열 리터럴에 나오는 슬래시를 걸러내려면 여전히 질의 치환이 필요합니다.) x/y를 div(x, y)로 바꾸려면 훨씬 더 지능적인 도구가 필요합니다. div(와 ) 부분의 위치를 정하기 전에 / 왼쪽과 오른쪽에 있는 표현식의 범위를 분석해야 하기 때문입니다.
x \ y. 백슬래시는 이미 줄 이어 쓰기를 뜻하는 토큰이며, 일반적으로 Unix 사용자의 눈에는 이스케이프를 연상시킵니다. 또한 (이 지적은 Terry Reedy가 한 것입니다) 이렇게 하면 eval("x\y") 같은 것을 올바르게 작성하기가 더 어려워집니다.

대안

변환해야 하는 오래된 코드의 양을 줄이기 위해 여러 대안이 제안되었습니다. 다음은 각 제안(또는 제안 범주)에 대한 간략한 논의입니다. c.l.py에서 논의되었지만 여기에 언급되지 않은 대안을 알고 계시면 두 번째 저자에게 메일을 보내 주십시오.

/는 고전적 의미를 유지하게 하고, 진정한 나눗셈을 위해 //를 도입합니다. 이렇게 하면 여전히 언어에 망가진 연산자가 남게 되고, 그 망가진 동작을 사용하도록 부추기게 됩니다. 또한 PEP 228식의 통합 수치 모델로 가는 길도 막아 버립니다.
int 나눗셈이 정수 문맥에서는 정수처럼, float 문맥에서는 float처럼 동작하는 특별한 “혼성(portmanteau)” 타입을 반환하게 합니다. 이 방식의 문제는 몇 번의 연산 후에는 int 값과 float 값이 크게 벌어질 수 있고, 비교에서 어느 값을 사용해야 하는지 불분명하며, 물론 (문자열로의 변환 같은) 많은 문맥에서는 정수와 float 중 어느 쪽을 선호할지가 명확하지 않다는 점입니다.
future 문 대신 지시자(directive)를 사용하여 모듈에서 특정 나눗셈 의미를 사용하게 합니다. 이렇게 하면 고전적 나눗셈이 언어의 영구적인 흠으로 남게 되어, 앞으로의 Python 프로그래머 세대도 이 문제와 해결책을 알고 있어야 합니다.
from __past__ import division을 사용하여 모듈에서 고전적 나눗셈 의미를 사용하게 합니다. 이 역시 고전적 나눗셈을 영구적인 흠으로, 또는 적어도 오랫동안 남겨 둡니다(결국에는 past division 문이 ImportError를 일으키게 될 수 있습니다).
지시문(또는 다른 방법)을 사용하여 특정 코드가 어떤 Python 버전을 대상으로 개발되었는지 명시합니다. 이렇게 하려면 향후 Python 인터프리터가 이전 여러 Python 버전을 정확히 에뮬레이트할 수 있어야 하며, 게다가 하나의 인터프리터 안에서 여러 버전을 동시에 에뮬레이트할 수 있어야 합니다. 이는 지나치게 많은 작업입니다. 여러 인터프리터를 설치해 두는 것이 훨씬 간단한 해결책입니다. 이에 반대하는 또 다른 논거(인자)는, 버전 지시문이 거의 항상 과도하게 지정된다는 점입니다. Python X.Y용으로 작성된 대부분의 코드는 Python X.(Y-1)과 X.(Y+1)에서도 동작하므로, X.Y를 버전으로 지정하면 필요 이상으로 제약이 커집니다. 동시에, 코드가 미래나 과거의 어느 버전에서 깨질지 알 방법도 없습니다.

API 변경 사항

전환 기간 동안에는 같은 프로그램 안에서 세 가지 나눗셈 연산자를 지원해야 합니다. 고전적 나눗셈(future division 문이 없는 모듈의 /), 참 나눗셈(future division 문이 있는 모듈의 /), 그리고 내림 나눗셈(//)입니다. 각 연산자에는 일반 연산자와 복합 대입 연산자(/= 또는 //=)의 두 가지 형태가 있습니다.

이러한 변형에 해당하는 이름은 다음과 같습니다:

오버로드된 연산자 메서드:

__div__(), __floordiv__(), __truediv__();
__idiv__(), __ifloordiv__(), __itruediv__().

추상 API C 함수:

PyNumber_Divide(), PyNumber_FloorDivide(),
PyNumber_TrueDivide();

PyNumber_InPlaceDivide(), PyNumber_InPlaceFloorDivide(),
PyNumber_InPlaceTrueDivide().

바이트코드 옵코드:

BINARY_DIVIDE, BINARY_FLOOR_DIVIDE, BINARY_TRUE_DIVIDE;
INPLACE_DIVIDE, INPLACE_FLOOR_DIVIDE, INPLACE_TRUE_DIVIDE.

PyNumberMethod 슬롯:

nb_divide, nb_floor_divide, nb_true_divide,
nb_inplace_divide, nb_inplace_floor_divide,
nb_inplace_true_divide.

추가된 PyNumberMethod 슬롯을 사용하려면 tp_flags에 플래그가 하나 더 필요합니다. 이 플래그의 이름은 Py_TPFLAGS_HAVE_NEWDIVIDE이며 Py_TPFLAGS_DEFAULT에 포함됩니다.

참 나눗셈 API와 내림 나눗셈 API는 해당 슬롯을 찾아 호출합니다. 그 슬롯이 NULL이면 예외를 발생시킵니다. 고전적 나눗셈 슬롯으로 대체(fallback)하지 않습니다.

Python 3.0에서는 고전적 나눗셈 의미 체계가 제거되며, 고전적 나눗셈 API는 참 나눗셈과 같은 의미가 됩니다.

명령줄 옵션

-Q 명령줄 옵션은 문자열 인자를 받으며, 이 인자는 old, warn, warnall, new 네 가지 값 중 하나를 가질 수 있습니다. Python 2.2에서 기본값은 old이지만, 이후 2.x 버전에서는 warn으로 바뀔 예정입니다. old 값은 고전적 나눗셈 연산자가 앞서 설명한 대로 동작한다는 뜻입니다. warn 값은 고전적 나눗셈 연산자가 int나 long에 적용될 때 경고(표준 경고 프레임워크를 사용하는 DeprecationWarning)를 발생시킨다는 뜻입니다. warnall 값은 float나 complex에 적용되는 고전적 나눗셈에 대해서도 경고를 발생시킵니다. 이 값은 아래에서 설명하는 fixdiv.py 변환 스크립트에서 사용하기 위한 것입니다. new 값은 기본 동작을 전역적으로 바꾸어 / 연산자가 항상 참 나눗셈으로 해석되도록 합니다. new 옵션은 참 나눗셈이 필요하지만 학생들에게 모든 코드에 future division 문을 넣도록 요구하기는 곤란한 일부 교육 환경에서만 사용하도록 의도된 것입니다.

이 옵션은 Python 3.0에서는 지원되지 않습니다. Python 3.0은 항상 /를 참 나눗셈으로 해석합니다.

(이 옵션은 원래 -D로 제안되었지만, Jython에 이미 있는 옵션으로 밝혀져 Q가 되었습니다. Q는 Quotient(몫)를 떠올리게 하는 글자입니다. -Qclassic, -Qclassic-warn, -Qtrue, -Qold_division 등 다른 이름들도 제안되었지만, 제가 보기에는 별다른 이점 없이 더 장황하기만 합니다. 어쨌든 고전적 나눗셈이라는 용어는 언어에서 전혀 사용되지 않고(PEP에서만 사용됩니다), 참 나눗셈이라는 용어도 언어에서 거의 사용되지 않습니다. __truediv__에서만 사용됩니다.)

내림 나눗셈의 의미 체계

내림 나눗셈은 Python의 모든 숫자 타입에 구현되며, 다음과 같은 의미 체계를 가집니다:

a // b == floor(a/b)

단, 결과 타입은 연산 전에 a와 b가 강제 변환되는 공통 타입이 된다는 점이 다릅니다.

구체적으로, a와 b가 같은 타입이면 a//b도 그 타입이 됩니다. 입력의 타입이 서로 다르면, 다른 모든 산술 연산자에 쓰이는 것과 같은 규칙에 따라 먼저 공통 타입으로 강제 변환됩니다.

특히 a와 b가 모두 int 또는 long이면, 결과는 이 타입들에 대한 고전적 나눗셈과 같은 타입과 값을 가집니다(입력 타입이 섞인 경우도 포함합니다. int//long과 long//int는 모두 long을 반환합니다).

부동소수점 입력의 경우 결과는 float입니다. 예를 들면 다음과 같습니다.:

3.5//2.0 == 1.0

복소수의 경우 //는 예외를 발생시킵니다. 복소수의 floor()는 허용되지 않기 때문입니다.

사용자 정의 클래스와 확장 타입의 경우 모든 의미 체계는 해당 클래스나 타입의 구현에 달려 있습니다.

참 나눗셈의 의미 체계

int와 long에 대한 참 나눗셈은 인자를 float로 변환한 다음 float 나눗셈을 적용합니다. 즉, 2/1조차 int가 아니라 float (2.0)을 반환합니다. float와 complex의 경우에는 고전적 나눗셈과 같습니다.

2.2의 참 나눗셈 구현은 float 타입의 범위에 제한이 없는 것처럼 동작하므로, 수학적 결과의 크기가 너무 커서 float로 표현할 수 없는 경우가 아니면 오버플로가 발생하지 않습니다. 예를 들어 x = 1L << 40000 이후에 float(x)는 OverflowError를 발생시킵니다(이 역시 2.2에서 새로 바뀐 점이라는 데 유의하십시오. 이전에는 결과가 플랫폼에 따라 달랐으며, 가장 흔하게는 float 무한대였습니다). 하지만 x/x는 예외 없이 1.0을 반환하는 반면, x/1은 OverflowError를 발생시킵니다.

int와 long 인자에 대해 참 나눗셈은 정보를 잃을 수 있다는 점에 유의하십시오. 이는 (언어에 유리수가 없는 한) 참 나눗셈의 본질입니다. 의도적으로 long을 사용하는 알고리즘은 // 사용을 고려해야 합니다. long의 참 나눗셈은 (대부분의 플랫폼에서) 최대 53비트의 정밀도만 유지하기 때문입니다.

Python에 유리수 타입이 추가된다면(PEP 239 참조), int와 long의 참 나눗셈은 아마도 유리수를 반환해야 할 것입니다. 이렇게 하면 int와 long의 참 나눗셈이 정보를 잃는 문제를 피할 수 있습니다. 하지만 그때까지는 일관성을 위해 float가 참 나눗셈의 유일한 선택지입니다.

퓨처 나눗셈 문

모듈에 from __future__ import division이 있거나 -Qnew가 사용되면 / 및 /= 연산자는 참 나눗셈 옵코드로 변환됩니다. 그렇지 않으면 고전적 나눗셈으로 변환됩니다(Python 3.0이 나오면 항상 참 나눗셈으로 변환됩니다).

퓨처 나눗셈 문은 //와 //=의 인식이나 번역에 아무런 영향을 주지 않습니다.

퓨처 문의 일반 규칙은 PEP 236을 참고하십시오.

(true_division이나 modern_division 같은 더 긴 문구를 사용하자는 제안이 있었습니다. 이런 문구는 별다른 정보를 더해 주지 않는 것 같습니다.)

미해결 문제

더 많은 피드백을 받거나 초기 구현에 대한 경험이 쌓이면서 시간이 지나면 이 문제들이 해결될 것으로 기대합니다.

//를 몫(quotient) 연산자로, / 연산자를 비율(ratio) 연산자로 부르자는 제안이 있었습니다. 저는 이에 대해 확신이 없습니다 – 어떤 사람들에게 몫은 나눗셈의 동의어일 뿐이고, 비율은 유리수를 연상시키는데, 이는 잘못된 것입니다. 저는 그렇게 해서 모호함을 피할 수 있다면 용어가 약간 어색한 편을 선호합니다. 또한 어떤 사람들에게 몫은 내림 나눗셈이라는 이름이 명시적으로 말하듯 무한대 방향으로 버리는 것이 아니라 0 방향으로 버리는 것을 연상시킵니다.
기본값을 바꾸는 명령줄 옵션은 해롭다는 주장이 있었습니다. 잘못 쓰면 분명히 위험할 수 있습니다. 예를 들어 -Qnew를 요구하는 서드파티 라이브러리 패키지와 -Qold를 요구하는 다른 패키지를 함께 사용하는 것은 불가능합니다. 하지만 저는 VPython 개발자들에게 참 나눗셈을 기본으로 활성화할 방법이 필요하며, 다른 교육자들도 같은 것이 필요할 수 있다고 생각합니다. 이들은 보통 자신의 환경에서 사용할 수 있는 라이브러리 패키지를 충분히 통제할 수 있습니다.
클래스가 __div__(), __floordiv__(), __truediv__() 세 가지를 모두 지원해야 하는 것은 번거로워 보입니다. 그리고 3.0에서는 어떻게 해야 합니까? 어쩌면 __div__()와 __floordiv__()만 있으면 될 수도 있고, 아니면 적어도 참 나눗셈이 __truediv__()를 먼저 시도하고 그다음에 __div__()를 시도해야 할 수도 있습니다.

해결된 문제

문제: 매우 큰 long 정수의 경우, 참 나눗셈이 float를 반환한다는 정의는 문제를 일으킵니다. Python long의 범위가 Python float의 범위보다 훨씬 넓기 때문입니다. 이 문제는 유리수가 지원되면 사라질 것입니다.
해결: long 참 나눗셈의 경우, Python은 네이티브 double 정밀도를 가지되 범위에는 제한이 없는 내부 float 타입을 사용합니다. 따라서 몫이 너무 커서 네이티브 double로 표현할 수 없는 경우가 아니면 OverflowError가 발생하지 않습니다.
문제: 당분간은 long이 범위를 벗어나면 long에서 float로의 변환이 OverflowError를 발생시키도록 할 수 있을 것입니다.
해결: 이는 구현되었습니다. 하지만 위에서 설명했듯이 long 참 나눗셈에서 입력값의 크기는 중요하지 않으며, 몫의 크기만 중요합니다.
문제: Tim Peters는 범위 내의 float가 반환될 때마다 적절한 정밀도가 보장되도록 할 것입니다.
해결: long 참 나눗셈의 몫을 float로 표현할 수 있다면 반올림 오차는 최대 3번 발생합니다. 네이티브 double 정밀도를 가지되 범위에는 제한이 없는 내부 float 타입으로 각 입력값을 변환할 때 한 번씩, 그리고 나눗셈에서 한 번 더 발생합니다. 그러나 몫의 크기가 너무 작아서 네이티브 double로 표현할 수 없으면 예외 없이 0.0이 반환된다는 점에 유의하십시오(“조용한 언더플로”).

FAQ

Python 3.0은 언제 출시됩니까?

저희는 그렇게 먼 미래까지 계획하지 않으므로 확실히 말씀드릴 수 없습니다. 전환에는 최소 2년의 기간을 두고자 합니다. Python 3.0이 더 일찍 나오더라도, 하위 호환성을 위해 최소한 Python 2.2 출시 후 2년까지는 2.x 계열을 유지할 것입니다. 실제로는 Python 3.0이 출시된 후에도 몇 년 동안 Python 2.x 계열을 계속 사용할 수 있을 것이므로, 서두르지 않고 전환하셔도 됩니다. 각 사이트에는 Python 2.x와 Python 3.x가 동시에 설치되어 있을 것으로 예상됩니다.

참 나눗셈을 왜 부동소수점 나눗셈이라고 부르지 않습니까?

어쩌면 유리수를 도입하여 1/2이 float 대신 유리수를 반환하게 할 가능성을 열어 두고 싶기 때문입니다. PEP 239를 참조하십시오.

`truediv`와 `itruediv`가 왜 필요합니까?

사용자 정의 클래스를 2등 시민으로 만들고 싶지 않습니다. 타입/클래스 통합이 진행 중인 지금은 더더욱 그렇습니다.

`//`나 future division 문을 사용하지 않고, 기존 규칙과 새 규칙 모두에서 동작하는 코드는 어떻게 작성합니까?

참 나눗셈에는 x*1.0/y를, 정수 나눗셈에는 divmod(x, y) (PEP 228)를 사용하십시오. 특히 후자는 함수 안에 숨겨 두는 것이 가장 좋습니다. 복소수가 나오지 않을 것이라고 확신한다면 참 나눗셈에 float(x)/y를 써도 됩니다. 정수가 절대 음수가 아니라는 것을 알고 있다면 int(x/y)를 사용할 수 있습니다. int()의 문서에는 int()가 C 구현에 따라 반올림할 수도 있고 버림할 수도 있다고 되어 있지만, 저희가 아는 C 구현 중에 버림하지 않는 것은 없으며, 버림을 보장하도록 int()의 명세를 변경할 예정입니다. 고전 나눗셈(그리고 내림 나눗셈)은 음의 무한대 방향으로 반올림하는 반면 int()는 0 방향으로 반올림하므로, 음수에 대해서는 서로 다른 결과가 나온다는 점에 유의하십시오.

`input()`, `compile()`, `execfile()`, `eval()`, `exec`의 나눗셈 의미는 어떻게 지정합니까?

이들은 자신을 호출한 모듈의 선택을 물려받습니다. PEP 236은 이제 이것을 해결된 문제로 나열하며, PEP 264를 참조합니다.

codeop 모듈이 컴파일하는 코드는 어떻게 됩니까?

이 경우도 적절히 처리됩니다. PEP 264를 참고하십시오.

변환 도구나 보조 수단이 제공됩니까?

물론입니다. 이것들은 이 PEP의 범위를 벗어나지만, Python 2.2a3과 함께 릴리스될 간단한 도구 두 가지를 언급해 두겠습니다. Tools/scripts/finddiv.py는 나눗셈 연산자를 찾아 주며(grep /보다 조금 더 똑똑합니다), Tools/scripts/fixdiv.py는 실행 시간 분석을 바탕으로 패치를 만들어 줄 수 있습니다.

제 질문에 대한 답이 왜 여기에 없습니까?

저희가 그 질문을 알지 못했기 때문입니다. 그 질문이 c.l.py에서 논의되었고 그 답이 많은 사람의 관심사가 될 것이라고 생각한다면 두 번째 저자에게 알려 주십시오. (개인 이메일로 보내온 질문에 일일이 답할 시간도 의향도 없기 때문에, 먼저 c.l.py에서 논의되어야 한다는 조건을 두었습니다.)

구현

여기에서 언급한 내용은 사실상 모두 CVS에 구현되어 있으며 Python 2.2a3과 함께 릴리스될 예정입니다. 그중 대부분은 이미 Python 2.2a2와 함께 릴리스되었습니다.

Copyright

This document has been placed in the public domain.