PEP 736 – 호출 시 키워드 인자를 위한 축약 구문

Author:: Joshua Bambrick <jbambrick at google.com>, Chris Angelico <rosuav at gmail.com>
Discussions-To:: Discourse thread
Status:: Rejected
Type:: Standards Track
Created:: 28-Nov-2023
Python-Version:: 3.14
Post-History:: 14-Oct-2023, 17-Jan-2024, 17-Jul-2024
Resolution:: 13-Mar-2025

Table of Contents

초록
동기
근거
사양
하위 호환성
보안 영향
선행 사례
적용 가능성
제안된 구문
이것을 가르치는 방법
거부된 아이디어
반대 의견
이 구문 사용 권장 사항
편집에 미치는 영향
- 평문 편집기 사용
- IDE를 위한 제안
참조 구현
참고 자료
Copyright

번역·라이선스 안내

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

초록

이 PEP에서는 키워드 인자가 해당 값에 대응하는 변수와 동일한 이름을 갖는 일반적인 패턴인 f(x=x)에 대해 f(x=)를 도입할 것을 제안합니다.

동기

키워드 인자 구문은 불필요하게 반복적이고 장황해질 수 있습니다.

다음 호출을 고려하십시오:

my_function(
  my_first_variable=my_first_variable,
  my_second_variable=my_second_variable,
  my_third_variable=my_third_variable,
)

키워드 인자 이름이 해당 값의 변수 이름과 일치하는 경우는 Python 라이브러리에서 흔합니다. 이러한 중복성은 시각적 잡음을 증가시켜 이름 있는 인자의 사용을 저해하고 가독성을 떨어뜨립니다.

근거

인자를 사용하여 함수를 호출하는 방법에는 위치와 키워드로 지정하는 두 가지가 있습니다. 키워드 인자는 명시적이므로 가독성을 높이고 의도하지 않은 위치 뒤바뀜의 위험을 최소화합니다. 반면 위치 인자는 장황함과 시각적 잡음을 최소화하기 위해 선호되는 경우가 많습니다.

이러한 일반적인 패턴을 단순화하는 간단한 구문 설탕이 여러 이점을 제공할 것이라고 주장합니다.

이름 있는 인자의 사용을 장려합니다

기존 키워드 인자 구문이 유발할 수 있는 시각적 잡음을 줄임으로써, 이 구문은 이름 있는 인자의 사용을 장려하고 그에 따라 가독성을 높이며 인자의 위치 뒤바뀜으로 인한 버그를 줄입니다.

장황함을 줄입니다

시각적 잡음과 경우에 따라 코드 줄 수를 최소화함으로써 가독성을 높일 수 있습니다.

일관된 변수 이름 사용을 장려합니다

흔히 발생하는 문제는 의미상 동일한 변수의 이름이 해당 변수가 사용되는 문맥에 따라 달라진다는 것입니다. 이 구문은 함수 호출 시 인자 이름과 동일한 변수 이름을 사용하도록 작성자를 유도하며, 이를 통해 사용되는 변수 이름의 일관성이 높아져 가독성이 향상됩니다.

이 패턴을 따르지 않는 인자를 강조합니다

현재 구문에서는 로컬 문맥의 많은 인자를 전달하는 함수 호출에서 시각적 잡음으로 인해 다른 인자 값을 쉽게 놓칠 수 있습니다. 예를 들어:

add_middleware(
    excluded_urls=excluded_urls,
    server_request=server_request,
    client_request=client_request,
    client_response=client_response,
    span_details=_get_span_details(),
    tracer=tracer,
    meter=meter,
)

이 구문을 사용하면 예외적인 인자를 더 쉽게 식별할 수 있습니다.:

add_middleware(
    excluded_urls=,
    server_request=,
    client_request=,
    client_response=,
    span_details=_get_span_details(),
    tracer=,
    meter=,
)

이 구문은 유사한 패턴이 자주 발생하는 딕셔너리 생성에도 적용할 수 있습니다. 즉, 딕셔너리 키가 값으로 할당되는 변수의 이름과 동일한 경우인 {"x": x, "y": y} 또는 dict(x=x, y=y)입니다. 이 기능을 사용하면 이제 이를 dict(x=, y=)로도 간단히 작성할 수 있습니다. 딕셔너리 리터럴에서도 유사한 구문을 추가로 지원할지는 이 PEP의 범위를 벗어나는 미해결 문제입니다.

사양

함수 호출에서 키워드 인자의 값이 생략된 경우 해당 인자의 값이 호출 범위에서 해당 이름과 일치하는 변수인 것으로 추론되도록 하는 구문 설탕을 도입할 것을 제안합니다.

예를 들어, 다음 함수 호출은:

my_function(my_first_variable=, my_second_variable=, my_third_variable=)

기존 구문에서는 다음과 정확히 동일하게 해석됩니다:

my_function(
  my_first_variable=my_first_variable,
  my_second_variable=my_second_variable,
  my_third_variable=my_third_variable,
)

호출 범위에 해당 이름과 일치하는 변수가 없으면, 기존 확장 구문에서와 동일한 방식으로 NameError가 발생합니다.

이 제안은 함수 호출에만 해당하며, 함수 정의는 구문 변경의 영향을 받지 않습니다. 기존의 유효한 구문은 모두 변경되지 않습니다.

하위 호환성

이전에는 구문상 잘못되었던 새로운 구문만 추가됩니다. 기존의 유효한 구문은 수정되지 않습니다. 따라서 제안된 변경 사항은 완전히 하위 호환됩니다.

보안 영향

이 변경으로 인한 보안 영향은 없습니다.

선행 사례

Python에는 이미 f-string 보간에서 이와 매우 유사한 기능이 있으며, 여기서 f'{x=}'는 사실상 f'x={x}'로 확장됩니다(related GitHub issue 참조).

여러 현대 언어는 함수 호출 중에 유사한 기능을 제공하며, 이를 때로는 ‘펀닝’이라고 부릅니다. 예를 들어 다음과 같습니다.

Ruby에서 f(x:, y:)는 f(x: x, y: y)를 위한 문법적 설탕입니다. Ruby 3.1.0 release notes를 참조하십시오(“keyword arguments” 검색).
ReasonML에서 f(~x, ~y)는 f(~x=x, ~y=y)를 위한 문법적 설탕입니다. ReasonML function documentation을 참조하십시오(“punning” 검색).
SystemVerilog에서 (.mult, .mop1, .data);는 (.mult(mult), .mop1(mop1), .data(data));를 위한 문법적 설탕입니다. SystemVerilog Implicit Port Connections를 참조하십시오.
Jakt에서 f(x, y)는 f(x: x, y: y)를 위한 문법적 설탕입니다. The Jakt programming language를 참조하십시오.

특히 함수 호출을 넘어서는 경우에도 더 많은 언어가 유사한 기능을 제공합니다.

OCaml에서 let+ x in …는 let+ x = x in …를 위한 문법적 설탕입니다. OCaml: Short notation for variable bindings (let-punning)을 참조하십시오.
JavaScript에서 { x, y }는 {x: x, y: y}를 위한 문법적 설탕입니다. JavaScript: Object Initializer를 참조하십시오.
Rust에서 User { x, y }는 User {x: x, y: y}의 축약형입니다. Rust: Using the Field Init Shorthand를 참조하십시오.

적용 가능성

지난 몇 년간의 인기 있는 Python 라이브러리를 분석하고, 다음 계산을 위해 this script를 사용했습니다.

호출 시 f(x=x)형태였던 키워드 인자의 수입니다.
호출 시 f(x=x)형태였던 키워드 인자의 비율입니다.
줄바꿈의 필요성을 줄이기 위해 이 문법적 설탕을 사용함으로써 절약할 수 있는 코드 줄 수입니다.

이 연습의 목적은 이 패턴의 보편성에 관한 통계를 계산하는 것이었으며, 제안된 문법적 설탕을 보편적으로 적용해야 한다는 권고로 해석해서는 안 됩니다.

통계	Polars	FastAPI	Rich	HTTPX
호출 시 `f(x=x)` 형식의 키워드 인자 수	1,654	1,408	566	759
호출 시 `f(x=x)` 형식의 키워드 인자 비율	15.83%	28.11%	15.74%	45.13%
절약된 줄 수	170	35	62	117

이를 바탕으로 f(x=x) 키워드 인자 패턴이 널리 사용되며, 코드베이스에 따라 전체 키워드 인자 사용의 15%에서 절반에 조금 못 미치는 수준을 차지한다는 점을 확인할 수 있습니다.

제안된 구문

이 기능은 여러 가지 형태로 여러 차례 제안되어 왔지만 [1] [2] [3] [4] [5], [6] 다음과 같은 이유로 f(x=) 형식을 지지하기로 했습니다.

이 기능은 10년 동안 빈번하게 제안되어 왔으며, f(x=)또는 f(=x)가 가장 일반적으로 제안된 구문이었습니다 [1] [2] [6]. 이는 해당 표기가 가장 명확하다는 점을 강하게 시사합니다.
제안된 구문은 f-string 디버그 f'{var=}'구문(확립된 Pythonic 스타일)과 매우 유사하며, 거의 동일한 목적을 수행합니다.
제안된 구문은 Ruby의 키워드 인자 문법적 설탕과 정확히 유사합니다. Ruby 3.1.0 release notes를 참조하십시오(“keyword arguments”를 검색하십시오).
단순한 문법적 설탕이므로 이 구문은 쉽게 구현할 수 있습니다.
접두사 형식(Rejected Ideas 참조)과 비교할 때, 이 구문은 “여기 매개변수가 있으니 그 인자를 찾아가십시오”라는 의미를 전달하므로, 명명된 인자의 의미론을 고려할 때 더 적절합니다.
A poll of Python developers은 제안된 구문 중 이것이 가장 인기 있는 구문임을 나타냅니다.

이것을 가르치는 방법

이 기능을 쉽게 전달하고 검색할 수 있도록 ‘키워드 인자 약식’과 같은 이름을 부여하는 것도 유용할 수 있습니다.

열정적인 Python 개발자는 뉴스 게시판, 소셜 미디어, 메일링 리스트, 온라인 포럼 또는 입소문과 같은 일반적인 정보 채널을 통해 이 기능에 대해 듣게 될 가능성이 큽니다. 더 많은 사람은 코드를 읽다가 호출 시 키워드 인자에서 값이 생략된 것을 발견하고, 이것이 자신의 예상에 어긋나는 것을 경험하면서 이 기능을 접하게 될 것입니다. 이러한 개발자가 이 기능의 의미를 설명하는 문서에 쉽게 접근할 수 있고, 검색할 때 해당 문서를 쉽게 찾을 수 있도록 해야 합니다. 예를 들어, Python Glossary와 Tutorial는 이에 맞게 업데이트할 수 있으며, 검색 가능성을 높이는 데 도움이 되도록 적절한 키워드를 사용할 수 있습니다. 설명을 검색하는 사람에게 이 기능을 설명하는 데 도움이 되도록 A StackOverflow question을 작성할 수도 있습니다.

교사는 새로운 Python 프로그래머에게 다음과 같이 이 기능을 설명할 수 있습니다. “등호만 뒤따르는 인자, 예를 들어 f(x=)를 보면, 이는 인자의 이름과 값이 같은 키워드 인자를 나타냅니다. 이는 확장 표기법인 f(x=x)로 동일하게 작성할 수 있습니다.” 학생의 배경에 따라 교사는 이를 다른 언어의 동등한 구문이나 Python의 f-문자열 구문인 f"{x=}"와 추가로 비교할 수도 있습니다.

이를 이해하려면 Python 학습자는 기존의 키워드 인자 구문뿐만 아니라 함수의 기본 사항에도 익숙해야 합니다. 이 기능은 비교적 간단한 구문 설탕이므로, 키워드 인자를 이해하고 있는 학생이라면 이 개념을 빠르게 습득할 수 있다고 보는 것이 합리적입니다. 이는 f-문자열 구문의 성공과 다른 언어의 유사한 기능을 통해 입증됩니다(Prior Art 참조).

거부된 아이디어

많은 대체 구문이 제안되었지만 f(=x) 또는 f(x=) 외의 어떤 형태도 상당한 지지를 얻지 못했습니다. 여기에서는 제안된 대안 중 가장 인기 있는 몇 가지와 우리가 궁극적으로 이를 거부한 이유를 열거합니다.

`f(a, b, *, x)`

몇 차례에 걸쳐 키워드 전용 함수 정의에서 구문을 차용하자는 아이디어가 제기되었습니다.

이 제안을 지지하는 이유:

이 구문은 함수 정의에서 키워드 전용 인자를 요구하는 데 사용되므로 익숙합니다.
A poll of Python developers은 제안된 구문 중 이것이 두 번째로 인기 있는 구문임을 나타냅니다.

그러나 다음과 같은 이유로 반대합니다.

주어진 인자가 위치 인자인지 이름 있는 인자인지 로컬 문맥만으로는 명확하지 않습니다. 긴 인자 목록에서는 *를 쉽게 놓칠 수 있으며, 이름 있는 인자를 위치 인자로 읽거나 그 반대로 읽을 수 있습니다.
값이 생략되지 않은 키워드 인자가 *뒤에 올 수 있는지는 명확하지 않습니다. 올 수 있다면 인자들의 상대적 위치가 혼란스러울 정도로 임의적이 되며, 올 수 없다면 서로 다른 유형의 키워드 인자 사이에 임의적인 그룹화가 강제되고, 이름 하나(인자 또는 그 값)만 변경된 경우 인자를 재정렬해야 합니다.
함수 호출에서 *를 사용하는 방식은 이미 확립되어 있으며, 이 제안은 혼란을 일으킬 수 있는 새로운 효과를 도입합니다. 예를 들어, f(a, *x, y)는 f(a, *, x, y)와 다른 의미를 갖게 됩니다.

`f(=x)`

이 형식을 지지하는 이유:

접두 연산자는 함수 호출에서 이미 확립된 *args 및 **kwargs 구문과 더 유사합니다.
인수가 수직으로 배열되면 그 자체가 더 눈에 띕니다. 특히 인수의 길이가 서로 다르면 끝에 있는 등호를 찾기가 더 어렵습니다. 또한 Python은 왼쪽에서 오른쪽으로 읽으므로, 이 기능의 사용이 독자에게 더 앞에서부터 명확하게 드러납니다.

반대로 말하면 다음과 같습니다.

접두사 방식은 시각적으로 더 눈에 띄지만, 실제로는 일반적인 명명된 인수보다 이 기능의 존재를 더 크게 드러낼 필요가 없습니다. =까지 읽으면 일반적인 키워드 인자의 경우 값이 분명한 것과 마찬가지로 값이 자동으로 채워진다는 것이 분명합니다.
의미상 이 형식은 ‘여기에 값이 있으니 매개변수를 채우십시오’라고 전달하는데, 이는 우리가 전달하려는 바가 아닙니다.
f-string 구문과의 유사성이 떨어집니다.
임의의 표현식이 유효하지 않다는 점은 덜 분명합니다. 예를 들어 f(=a + b)와 같은 표현식은 현재 키워드 인자 구문에서 등호 뒤에는 허용되지만 등호 앞에는 허용되지 않기 때문입니다.

`f(%x)` 또는 `f(:x)` 또는 `f(.x)`

이 구문의 여러 변형이 제안되었으며, 접두사 형식에서 = 대신 다른 문자를 사용합니다. 그러나 그러한 형태 중 어느 것도 호응을 얻지 못했으며, 기호의 선택은 =에 비해 임의적으로 보입니다. 또한 기존 언어 기능(f-string 등)이나 다른 언어(Ruby 등)의 관점에서도 선례가 적습니다.

반대 의견

이러한 문법적 편의 기능의 도입에 대한 강한 반대 의견은 몇 가지뿐입니다. 이 기능에 찬성하지 않는 사람들의 대부분은 ‘나는 사용하지 않을 것입니다’라는 입장에 속합니다. 그러나 이 기능에 관한 광범위한 논의에서 다음과 같은 반대 의견이 가장 흔했습니다.

구문이 보기 흉합니다.

이 반대 의견이 가장 흔합니다. 반대로 우리는 다음과 같이 주장합니다.

이 반대 의견은 주관적이며 많은 커뮤니티 구성원이 동의하지 않습니다.
f-string에는 이와 거의 동일한 구문이 이미 정착되어 있습니다.
프로그래머는 언제나 그렇듯 시간이 지나면서 적응할 것입니다.

이 기능은 혼란스럽습니다.

우리는 다음과 같이 주장합니다.

새로운 기능을 도입하면 일반적으로 일시적으로 이러한 영향이 발생합니다.
이 구문은 이미 정착된 f'{x=}' 구문과 매우 유사합니다.
이 기능과 구문은 다른 인기 있는 현대 언어에서도 익숙합니다.
x=를 x=x로 확장하는 것은 사소한 기능이며, 인기 있는 *arg 및 **kwarg 확장보다 본질적으로 훨씬 덜 복잡합니다.
이 특정 구문 형식은 여러 차례 독립적으로 제안되었으며, 이는 이것이 가장 명백한 형식임을 나타냅니다 [1] [2] [6].

이 기능은 명시적이지 않습니다.

이 제안된 구문에서 인자 값이 명백한 의미에서 ‘암묵적’이라는 점은 인정합니다. 그러나 이것이 Python의 선(禪)이 억제하려는 것이라고는 생각하지 않습니다.

우리가 선이 가리키는 의미에서 보자면, 키워드 인자는 (예를 들어) 인자 이름이 생략되어 로컬 컨텍스트만으로는 알 수 없는 위치 인자보다 더 명시적입니다. 반대로 정수에 대한 구문 설탕인 x += 1은 이 의미에서 x = x + 1보다 더 암묵적이지 않습니다. 변수는 우변에서 생략되어 있지만, 로컬 컨텍스트에서 그것이 무엇인지 즉시 명확하기 때문입니다.

이 PEP에서 제안하는 구문은 x += 1 예제와 훨씬 더 유사합니다(새로운 연산을 도입하지 않으므로 더 단순하기도 합니다). 또한 기존 키워드 인자 구문이 만들어 내는 시각적 잡음이라는 장벽을 제거함으로써, 이 구문 설탕은 위치 인자보다 키워드 인자를 사용하도록 장려하여 일반적인 Python 코드베이스를 전반적으로 더 명시적으로 만듭니다.

이 기능은 작업을 수행하는 또 다른 방법을 추가합니다.

모든 구문 변경에 대해서도 같은 주장을 할 수 있습니다. 이는 x += 1이 x가 정수일 때 x = x + 1의 구문 설탕인 것과 마찬가지로 단순한 구문 설탕입니다. 이는 인자를 전달하는 ‘새로운 방식’에 해당하는 것이 아니라, 동일한 방식에 대한 더 읽기 쉬운 표기입니다.

호출 컨텍스트에서 변수 이름을 변경하면 코드가 손상됩니다.

NameError는 대다수 경우에 실수를 명확하게 드러냅니다. 더 넓은 범위의 변수가 원래 변수와 같은 이름을 사용하면 혼동이 발생하여 NameError가 발생하지 않을 수 있습니다. 그러나 현재 구문을 사용하는 키워드 인자에서도 이 문제가 발생할 수 있습니다(이 구문 설탕으로 인해 문제를 발견하기 더 어려워질 수 있다는 주장도 가능하지만 말입니다). 또한 서로 다른 범위에서 같은 이름의 변수를 사용하는 것은 대체로 나쁜 관행으로 간주되며 린터에서 사용을 억제합니다.

코드 편집기는 정적 분석을 기반으로 이 문제를 강조 표시할 수 있습니다 – f(x=)는 f(x=x)를 작성하는 것과 정확히 같습니다. x가 존재하지 않는 경우 최신 편집기는 이 문제를 강조 표시하는 데 아무런 문제가 없습니다.

이 구문은 결합도를 높입니다.

늘 그렇듯 모든 구문은 오용될 가능성이 있으므로 코드베이스를 개선하도록 신중하게 적용해야 한다는 점을 인정합니다. 이 경우 두 컨텍스트에서 매개변수와 그 값이 동일한 의미를 가진다면, 이 구문을 사용하는 것이 적절하며 가독성을 해치는 의도하지 않은 비동기화의 위험을 완화하는 데 도움이 된다는 뜻입니다.

그러나 두 변수가 서로 다른 의미를 가진다면, 이는 이 기능을 사용해서는 안 되거나(일관성을 장려하기 때문입니다) 변수 중 하나 또는 둘 다의 이름을 변경해야 한다는 뜻입니다.

이 구문 사용 권장 사항

다른 언어 기능과 마찬가지로 프로그래머는 주어진 컨텍스트에서 이 기능을 사용하는 것이 현명한지 스스로 판단해야 합니다. 린트 규칙이나 스타일 가이드를 통해 이 기능을 적용할 수 있는 모든 경우에 사용하도록 강제하는 규칙은 권장하지 않습니다.

This syntax increases coupling 에서 설명한 것처럼, 부적절한 결합을 유발하지 않으면서 의도하지 않은 비동기화를 줄이려면 매개변수와 인자가 동일한 의미를 가지는 경우에 이 기능을 사용하는 것이 합리적인 경험 법칙이라고 제안합니다.

편집에 미치는 영향

평문 편집기 사용

평문 편집기를 사용한 편집은 일반적으로 영향을 받지 않습니다.

‘찾기-바꾸기’ 방식을 사용하여 변수 이름을 변경할 때 이 구문이 사용된 경우, 개발자는 호출 시 함수 인자를 마주치게 됩니다(이 구문을 사용하지 않았을 때와 마찬가지입니다). 그 시점에 개발자는 평소처럼 인자도 업데이트할지, 아니면 전체 f(x=x)구문으로 확장할지 결정할 수 있습니다.

현재 구문과 마찬가지로 ‘모두 찾기-바꾸기’ 방식은 대다수 경우 함수 정의에 키워드 인자가 존재하지 않으므로 실패합니다.

개발자가 인자 이름을 변경하지 않은 채 그 값을 업데이트하는 것을 잊으면, Renaming the variable in the calling context will break the code 에서 설명한 대로 일반적으로 NameError가 발생합니다.

IDE를 위한 제안

커뮤니티의 피드백에 따라 IDE가 이 구문을 처리할 수 있는 방법에 관한 몇 가지 제안을 포함합니다. 그러나 IDE를 개발하는 해당 분야의 전문가가 재량에 따라 결정하도록 맡깁니다.

f(x=)가 f(x=x)의 단순한 문법적 설탕이며 현재와 동일하게 처리해야 한다는 점을 인식하면 대부분의 고려 사항이 단순해집니다.

NameError 강조 표시

IDE는 일반적으로 NameError를 일으킬 수 있는 코드를 강조 표시하는 기능을 제공합니다. 생략된 변수가 존재하지 않을 수 있는 경우를 식별하고 강조 표시할 수 있도록 이 구문을 확장된 형식인 f(x=x)와 동일하게 처리할 것을 권장합니다. 이러한 경우를 강조 표시하는 데 사용할 시각적 단서는 IDE에 따라 현재 구문에서 사용하는 것과 같거나 다를 수 있습니다.

정의로 이동

캐럿/커서 위치에 따라 ‘정의로 이동’ 기능을 구현할 수 있는 몇 가지 방법이 있습니다.

한 가지 방법은 다음과 같습니다.

캐럿/커서가 인자 위에 있으면 함수 정의의 해당 인자로 이동합니다.
제안된 구문에서 캐럿/커서가 =뒤의 문자 위에 있으면 생략된 변수의 정의로 이동합니다.

또 다른, 잠재적으로 상호 보완적인 방법은 마우스를 올렸을 때 구문을 시각적으로 확장하고, Ctrl+Click(또는 Cmd+Click)으로 변수의 정의를 열 수 있도록 하는 것입니다.

다른 참조 강조 표시

IDE는 현재 캐럿/커서 위치의 값과 일치하는 코드 참조를 자주 강조 표시합니다. 이 축약 구문에서는 캐럿/커서가 인자 이름 위에 있을 때 다음 중 하나를 수행하는 것이 유용할 수 있습니다.

이 이름이 이제 인자와 해당 값 모두를 가리킨다는 사실을 반영하여 인자와 해당 값에 대한 두 참조를 모두 강조 표시합니다.
마우스를 올렸을 때 위와 같이 구문을 시각적으로 확장하고 커서에 따라 확립된 강조 표시 로직을 적용합니다.

기호 이름 변경

IDE가 이 구문에 대해 ‘기호 이름 변경’ 기능을 지원할 수 있는 방법은 몇 가지가 있습니다. 예를 들어 인자 이름을 변경하는 경우 IDE는 다음을 수행할 수 있습니다.

이 구문이 사용된 각 호출 컨텍스트에서 해당 값으로 사용되는 변수의 이름도 변경합니다.
이름이 변경된 인자의 값으로 변경되지 않은 변수를 전달하도록 전체 구문으로 확장합니다.
개발자에게 위의 두 옵션 중에서 선택하도록 요청합니다.

프로그래머에게 변경 사항을 강조 표시하면서 이름이 의도치 않게 동기화되지 않는 일을 줄일 수 있으므로 마지막 옵션이 가장 바람직해 보입니다.

Python 개선 제안 한국어 번역