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

초록
동기
변형
대안
API 변경 사항
명령줄 옵션
플로어 나눗셈의 시맨틱스
참 나눗셈(True Division)의 의미
Future 나눗셈 문
미해결 이슈
해결된 문제
자주 묻는 질문
구현
Copyright

번역·라이선스 안내

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

초록

현재의 나눗셈(/) 연산자는 숫자 인자에 대해 모호한 의미를 가집니다: 인자가 int나 long이면 나눗셈의 수학적 결과의 바닥값을 반환하지만, 인자가 float나 complex이면 나눗셈 결과에 대한 합리적인 근삿값을 반환합니다. 이 때문에 float나 complex 결과를 기대하는 표현식은 입력값으로 정수가 예상되지는 않지만 가능한 경우 오류가 발생하기 쉬워집니다.

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

c.l.py에서의 대규모 논쟁은 물론이고 심각한 하위 호환성 문제로 인해, 우리는 다음과 같은 과도기적 조치를 제안합니다(Python 2.2부터 시작):

고전적 나눗셈은 Python 2.x 시리즈에서 기본값으로 유지되며, 참 나눗셈은 Python 3.0에서 표준이 될 것입니다.
// 연산자는 바닥 나눗셈을 명확하게 요청하는 데 사용할 수 있게 될 것입니다.
from __future__ import division이라고 표기되는 미래 나눗셈 문(future division statement)은 모듈 전체에서 / 연산자가 참 나눗셈을 의미하도록 변경할 것입니다.
명령줄 옵션 하나는 int나 long 인자에 적용된 고전적 나눗셈에 대한 실행 시점 경고를 활성화하게 되며, 또 다른 명령줄 옵션은 참 나눗셈을 기본값으로 만들게 될 것입니다.
표준 라이브러리는 고전적 나눗셈을 완전히 피하기 위해 적절한 경우 미래 나눗셈 문과 // 연산자를 사용하게 될 것입니다.

동기

고전적 나눗셈 연산자는 임의의 숫자 입력값에 대해 올바른 결과를 내야 하는 숫자 표현식을 작성하기 어렵게 만듭니다. 다른 모든 연산자의 경우, x*y**2 + z와 같은 수식을 작성하면 (int, long, float, complex 중) 어떤 숫자 입력 타입에 대해서도 계산된 결과가 수학적 결과에 (물론 수치 정확도의 한계 내에서) 가까울 것입니다. 하지만 나눗셈은 문제를 일으킵니다: 두 인자에 대한 표현식이 우연히 정수 타입을 가지게 되면, 참 나눗셈이 아니라 바닥 나눗셈이 구현됩니다.

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

이 문제는 다른 모든 상황에서는 정수가 부동소수점의 완벽한 대체물이기 때문에 특히 골치 아픕니다: 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 statement) 아래에서만 인식되지 않는 한 이는 상당수의 기존 코드를 깨뜨리게 됩니다. 변환이 필요한 코드의 대다수가 정수를 나누는 코드일 것으로 예상되므로, 이는 미래의 나눗셈 문에 대한 필요성을 크게 증가시키게 됩니다. 미래의 문(future statement)을 사용하더라도, 반드시 필요한 경우가 아니면 새 키워드를 추가하지 않는다는 일반적인 정서가 이에 반대하는 논거가 됩니다.
div(x, y). 이는 기존 코드의 변환을 훨씬 더 어렵게 만듭니다. x/y를 x//y또는 x div y로 바꾸는 작업은 간단한 검색 치환으로 할 수 있습니다. 대부분의 경우 프로그래머는 특정 모듈이 정수만 다룬다는 것을 쉽게 확인할 수 있으므로 x/y의 모든 출현을 치환할 수 있습니다. (여전히 주석이나 문자열 리터럴에 나타나는 슬래시를 걸러내기 위해 검색 치환이 필요합니다.) x/y를 div(x, y)로 바꾸는 작업은 훨씬 더 지능적인 도구를 필요로 하는데, div(와 )부분을 어디에 배치할지 결정하기 전에 /의 좌우에 있는 표현식의 범위를 분석해야 하기 때문입니다.
x \ y. 백슬래시는 이미 줄 이어짐을 뜻하는 토큰이며, 일반적으로 유닉스에 익숙한 사람들의 눈에는 이스케이프를 암시합니다. 또한(이는 Terry Reedy가 지적한 것입니다) 이렇게 하면 eval("x\y") 같은 것을 올바르게 처리하기가 더 어려워질 것입니다.

대안

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

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

API 변경 사항

과도기 동안에는 같은 프로그램 내에서 세 가지 나눗셈 연산자, 즉 고전적 나눗셈(미래의 나눗셈 문이 없는 모듈에서 /에 대응), 참 나눗셈(미래의 나눗셈 문이 있는 모듈에서 /에 대응), 내림 나눗셈(//에 대응)을 지원해야 합니다. 각 연산자는 일반형과 복합 대입 연산자(/= 또는 //=)의 두 가지 형태로 제공됩니다.

이러한 변형들과 연관된 이름은 다음과 같습니다:

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

__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는 대응하는 슬롯을 찾아 그것을 호출합니다. 해당 슬롯이 NULL일 때는 예외를 발생시킵니다. 클래식 나눗셈 슬롯으로의 폴백은 없습니다.

파이썬 3.0에서는 클래식 나눗셈 시맨틱스가 제거됩니다. 클래식 나눗셈 API는 트루 나눗셈과 동의어가 됩니다.

명령줄 옵션

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

이 옵션은 파이썬 3.0에서 지원되지 않을 것입니다. 파이썬 3.0은 /를 항상 트루 나눗셈으로 해석합니다.

(이 옵션은 원래 -D로 제안되었으나, Jython에 이미 존재하는 옵션임이 밝혀져 Q를 사용하게 되었습니다 – Quotient(몫)를 나타내는 기억법입니다. -Qclassic, -Qclassic-warn, -Qtrue, -Qold_division 등 다른 이름들도 제안되었습니다. 하지만 필자에게는 이것들이 큰 이점 없이 더 장황해 보입니다. 결국 classic division이라는 용어는 언어 자체에서는 전혀 사용되지 않으며(PEP에서만 사용됩니다), true division이라는 용어도 언어에서 거의 사용되지 않습니다 – __truediv__에서만 사용됩니다.)

플로어 나눗셈의 시맨틱스

몫 나눗셈(floor division)은 모든 파이썬 숫자 타입에 구현되며, 다음과 같은 의미를 가집니다::

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()는 허용되지 않으므로 //는 예외를 발생시킵니다.

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

참 나눗셈(True Division)의 의미

int와 long의 참 나눗셈은 인자를 float로 변환한 다음 float 나눗셈을 적용합니다. 즉, 2/1조차도 int가 아닌 float (2.0)을 반환합니다. float와 복소수의 경우, 전통적인 나눗셈과 동일합니다.

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비트를 넘는 정밀도를 유지하지 않기 때문입니다.

유리수 타입이 파이썬에 추가된다면(PEP 239 참조), int와 long의 참 나눗셈은 아마도 유리수를 반환해야 합니다. 이는 int와 long의 참 나눗셈이 정보를 잃는 문제를 방지합니다. 그러나 그때까지는 일관성을 위해 float가 참 나눗셈의 유일한 선택지입니다.

Future 나눗셈 문

모듈에 from __future__ import division이 있거나 -Qnew가 사용되면, /와 /= 연산자는 참 나눗셈 옵코드로 변환됩니다; 그렇지 않으면 고전적 나눗셈으로 변환됩니다(파이썬 3.0이 도래하기 전까지는 그러하며, 3.0부터는 항상 참 나눗셈으로 변환됩니다).

Future 나눗셈 문은 //와 //=의 인식이나 변환에 영향을 주지 않습니다.

future 문에 대한 일반적인 규칙은 PEP 236을 참조하십시오.

(true_division이나 modern_division 같은 더 긴 어구를 사용하자는 제안이 있었습니다. 이런 표현들은 정보를 더 추가하는 것 같지 않습니다.)

미해결 이슈

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

//를 몫 연산자로, / 연산자를 비율 연산자로 부르자는 제안이 있었습니다. 이 점에 대해서는 확신이 서지 않습니다 – 어떤 사람들에게 몫은 그저 나눗셈의 동의어일 뿐이고, 비율은 잘못되게도 유리수를 연상시킵니다. 저는 모호함을 피할 수 있다면 용어가 다소 어색하더라도 그쪽을 선호합니다. 또한 어떤 사람들에게는 몫이 버림 나눗셈이 명시적으로 말하는 무한대 방향이 아니라 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-to-float 변환이 OverflowError를 발생시키도록 만들 수도 있습니다.
해결: 이는 이미 구현되었지만, 위에서 언급했듯이 long 참 나눗셈의 입력값 크기는 중요하지 않으며, 오직 몫의 크기만이 중요합니다.
문제: Tim Peters가 범위 내의 float가 반환될 때마다 적절한 정밀도가 보장되도록 확실히 할 것입니다.
해결: long 참 나눗셈의 몫이 float로 표현 가능하다면, 최대 3번의 반올림 오차만 발생합니다. 즉 입력값을 네이티브 double 정밀도를 가지지만 범위 제한이 없는 내부 float 타입으로 변환할 때 각각 한 번씩, 그리고 나눗셈 자체에서 한 번 더 발생합니다. 다만 몫의 크기가 네이티브 double로 표현하기에 너무 작은 경우, 예외 없이 0.0이 반환된다는 점에 유의하십시오(“조용한 언더플로”).

자주 묻는 질문

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를 동시에 설치해 두는 것이 권장됩니다.

참 나눗셈은 왜 float 나눗셈이라고 부르지 않습니까?

유리수를 도입하여 1/2이 float가 아니라 유리수를 반환하도록 만들 수 있는 여지를 혹시 남겨 두고 싶기 때문입니다. 자세한 내용은 PEP 239를 참조하십시오.

`truediv`와 `itruediv`가 필요한 이유는 무엇입니까?

사용자 정의 클래스를 이류 시민으로 만들고 싶지 않습니다. 특히 타입/클래스 통합이 진행되고 있는 상황에서는 더더욱 그렇습니다.

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

true division에는 x*1.0/y를, int division에는 divmod(x, y) (PEP 228)를 사용하십시오. 특히 후자는 함수 안에 숨기는 것이 가장 좋습니다. 복소수를 기대하지 않는다고 확신한다면 true division에 float(x)/y를 사용해도 됩니다. 정수가 절대 음수가 아니라는 것을 안다면 int(x/y)를 사용할 수 있습니다 – int()의 문서에는 int()가 C 구현에 따라 반올림하거나 절단할 수 있다고 나와 있지만, 절단하지 않는 C 구현은 알려진 바 없으며, int()의 명세를 절단을 보장하도록 변경할 예정입니다. classic division(및 floor division)은 음의 무한대 방향으로 반올림하는 반면, 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.