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-문자열 보간에 매우 유사한 기능이 있으며, 여기서 f'{x=}'는 사실상 f'x={x}'로 확장됩니다(관련 GitHub 이슈를 참고하십시오).

여러 현대 언어가 함수 호출 시 유사한 기능을 제공하며, 이를 때때로 ‘퍼닝(punning)’이라고 부릅니다. 예를 들면 다음과 같습니다.

Ruby에서 f(x:, y:)는 f(x: x, y: y)의 문법적 설탕입니다. Ruby 3.1.0 릴리스 노트를 참조하십시오(“keyword arguments”(키워드 인자)로 검색하십시오).
ReasonML에서 f(~x, ~y)는 f(~x=x, ~y=y)의 문법적 설탕입니다. ReasonML 함수 문서를 참고하십시오(“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 라이브러리를 분석하고 다음을 계산했습니다.

호출 시 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-문자열 디버그 문법인 f'{var=}'(이미 확립된 파이썬다운 스타일)와 매우 비슷하며, 거의 동일한 목적을 수행합니다.
제안된 문법은 Ruby의 키워드 인자 문법적 설탕과 정확히 같은 방식입니다. Ruby 3.1.0 릴리스 노트를 참조하십시오(“keyword arguments”(키워드 인자)로 검색하십시오).
이 문법은 단순한 문법적 설탕이므로 구현하기 쉽습니다.
접두사 형태(Rejected Ideas 참고)와 비교했을 때, 이 문법은 “여기에 매개변수가 있으니 그 인자를 찾으십시오”라는 의미를 전달하며, 이는 이름 있는 인자의 의미론을 고려할 때 더 적절합니다.
파이썬 개발자 대상 설문에 따르면 이것은 제안된 문법 중 가장 인기 있는 문법입니다.

교육 방법

이 기능에 관해 소통하고 검색하기 쉽도록 ‘키워드 인자 축약 표기(keyword argument shorthand)’와 같은 이름을 붙이는 것도 유용할 수 있습니다.

관심 많은 Python 개발자는 뉴스 게시판, 소셜 미디어, 메일링 리스트, 온라인 포럼, 입소문과 같은 일반적인 정보 경로를 통해 이 기능에 대해 듣게 될 가능성이 높습니다. 그보다 훨씬 많은 개발자는 코드를 읽다가 호출 시 키워드 인자의 값이 생략된 것을 보고 예상과 달라 당황하면서 이 기능을 처음 접하게 될 것입니다. 이러한 개발자가 이 기능의 의미를 설명하는 문서에 쉽게 접근할 수 있어야 하고, 검색할 때 그 문서를 쉽게 찾을 수 있도록 해야 합니다. 예를 들어 파이썬 용어집과 자습서를 그에 맞게 갱신하고, 검색으로 쉽게 찾을 수 있도록 적절한 키워드를 사용할 수 있습니다. 설명을 찾는 사람들에게 이 기능을 설명하는 데 도움이 되도록 StackOverflow 질문을 작성할 수도 있습니다.

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

이를 이해하려면 Python 학습자는 기존 키워드 인자 문법뿐 아니라 함수의 기초에도 익숙해야 합니다. 이 기능이 비교적 단순한 문법 설탕(syntactic sugar)이라는 점을 고려하면, 키워드 인자를 이해하고 있는 학생은 이 개념을 빠르게 익힐 수 있다고 보는 것이 타당합니다. 이는 f-문자열 문법의 성공과 다른 언어의 유사한 기능을 통해 입증됩니다(Prior Art 참고).

기각된 아이디어

여러 대안 문법이 제안되었지만, f(=x) 또는 f(x=) 외의 어떤 형태도 상당한 지지를 얻지 못했습니다. 여기서는 제안된 대안 중 가장 인기 있었던 몇 가지를 나열하고, 최종적으로 이를 기각한 이유를 설명합니다.

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

키워드 전용 함수 정의의 문법을 빌려 오자는 아이디어가 몇 차례 제기되었습니다.

이 제안을 지지하는 근거는 다음과 같습니다.

이 문법은 함수 정의에서 키워드 전용 인자를 요구할 때 사용되므로 익숙합니다.
파이썬 개발자 대상 설문에 따르면 이것은 제안된 문법 중 두 번째로 인기 있는 문법입니다.

그러나 저희는 다음과 같은 이유로 반대합니다:

어떤 인자가 위치 인자인지 이름 있는 인자인지를 주변 문맥만으로 파악하기가 더 어렵습니다. 긴 인자 목록에서는 *를 놓치기 쉬우며, 이름 있는 인자를 위치 인자로 읽거나 그 반대로 읽을 수 있습니다.
값이 생략되지 않은 키워드 인자가 * 뒤에 올 수 있는지가 불분명합니다. 올 수 있다면 이들의 상대적 위치가 혼란스러울 만큼 임의적이게 되고, 올 수 없다면 서로 다른 종류의 키워드 인자 사이에 임의적인 구분이 강제되며, 이름 하나(인자 또는 그 값)만 바뀌어도 인자의 순서를 다시 정렬해야 합니다.
함수 호출에서 *를 사용하는 방식은 이미 확고히 자리 잡았으며, 이 제안은 혼란을 일으킬 수 있는 새로운 효과를 도입하게 됩니다. 예를 들어 f(a, *x, y)는 f(a, *, x, y)와 다른 의미가 됩니다.

`f(=x)`

이 형태를 지지하는 근거는 다음과 같습니다.

접두 연산자는 함수 호출에 쓰이는 기존의 *args 및 **kwargs 문법과 더 유사합니다.
인자를 세로로 배치하면 이 형태가 더 눈에 잘 띕니다. 특히 인자의 길이가 서로 다르면 끝에 있는 등호를 찾기가 더 어렵습니다. 게다가 Python은 왼쪽에서 오른쪽으로 읽히므로, 이 기능의 사용이 독자에게 더 일찍 명확하게 드러납니다.

반면에 다음과 같은 점이 있습니다:

접두사 방식이 시각적으로 더 두드러지기는 하지만, 실제로는 이 기능이 일반적인 이름 있는 인자보다 더 요란하게 자신의 존재를 드러낼 필요가 없습니다. =까지 읽을 무렵에는, 일반적인 키워드 인자의 경우에 값이 분명한 것과 마찬가지로 값이 자동으로 채워진다는 것이 분명합니다.
의미상으로 이 형태는 ‘여기 값이 있으니 매개변수를 채우십시오’라는 뜻을 전달하는데, 이는 우리가 전달하려는 의미가 아닙니다.
f-문자열 문법과 덜 유사합니다.
임의의 표현식, 예를 들어 f(=a + b)가 유효하지 않다는 점이 덜 분명합니다. 현재의 키워드 인자 문법에서는 이러한 표현식이 등호 뒤에는 올 수 있지만 앞에는 올 수 없기 때문입니다.

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

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

반대 의견

이 문법 설탕의 도입에 대한 강한 반대 의견은 몇 가지뿐입니다. 이 기능에 찬성하지 않는 사람들 대부분은 ‘나는 쓰지 않겠습니다’라는 입장입니다. 그러나 이 기능에 관한 광범위한 논의에서 가장 흔했던 반대 의견은 다음과 같습니다:

문법이 보기 흉합니다

이것이 가장 흔한 반대 의견입니다. 이에 반해 우리는 다음과 같이 주장합니다:

이 반대 의견은 주관적이며, 많은 커뮤니티 구성원이 동의하지 않습니다.
f-문자열에는 거의 동일한 문법이 이미 확립되어 있습니다.
프로그래머들은 언제나 그랬듯이 시간이 지나면 적응할 것입니다.

기능이 혼란스럽습니다

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

새로운 기능을 도입하면 보통 일시적으로 이러한 영향이 있습니다.
이 문법은 이미 자리 잡은 f'{x=}' 문법과 매우 비슷합니다.
이 기능과 문법은 널리 쓰이는 다른 현대 언어에서 이미 익숙한 것입니다.
x=를 x=x로 확장하는 것은 사소한 기능이며, 널리 쓰이는 *arg 및 **kwarg 확장보다 본질적으로 훨씬 덜 복잡합니다.
이 특정한 문법 형태는 여러 차례 독립적으로 제안되었으며, 이는 이것이 가장 자명한 형태임을 보여 줍니다 [1] [2] [6].

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

우리는 명백한 의미에서 이 제안된 문법에서 인자 값이 ‘암시적’이라는 점을 인정합니다. 그러나 이것이 파이썬의 선(Zen of Python)이 지양하려는 바라고는 생각하지 않습니다.

저희가 이해하는 선(Zen)의 의미에서 보면, (예를 들어) 키워드 인자는 인자 이름이 생략되어 지역 문맥만으로는 알 수 없는 위치 인자보다 더 명시적입니다. 반대로, 정수에 대한 구문 설탕인 x += 1은 우변에서 변수가 생략되었음에도 이런 의미에서 x = x + 1보다 더 암시적이지 않습니다. 그 변수가 무엇인지 지역 문맥에서 바로 명백하게 알 수 있기 때문입니다.

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

이 기능은 같은 일을 하는 또 다른 방법을 추가합니다

같은 논거는 모든 문법 변경에 대해서도 똑같이 제기할 수 있습니다. 이것은 x가 정수일 때 x += 1이 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 개선 제안 한국어 번역