PEP 8, 키워드 인수 또는 기본 매개 변수 값에서 '=' 주변에 공백이 없는 이유는 무엇입니까?

PEP 8, 키워드 인수 또는 기본 매개 변수 값에서 '=' 주변에 공백이 없는 이유는 무엇입니까?

왜 PEP 8은 키워드 인수나 기본 매개 변수 값에 공백을 두지 말 것을 권장합니까?

이것이 모든 다른 발생 주변의 공간을 권장하는 것과 일치하지 않습니까?=파이썬 코드로?

방법:

func(1, 2, very_long_variable_name=another_very_long_variable_name)

다음보다 우수:

func(1, 2, very_long_variable_name = another_very_long_variable_name)

Python의 BDFL에 의한 토론/설명 링크는 감사합니다.

명심하세요, 이 질문은 기본값보다 kwargs에 관한 것입니다. 저는 방금 PEP 8의 문구를 사용했습니다.

저는 의견을 구하는 것이 아닙니다.저는 이 결정의 배경에 대한 이유를 묻고 있습니다.내가 왜 이런 걸 쓰냐고 묻는 것에 더 가깝습니다.{와같선에상과 if내가 그것을 사용해야 하는지 아닌지가 아닌 C 프로그램의 진술.

키워드 인수는 변수 할당과 본질적으로 다르기 때문인 것 같습니다.

예를 들어, 다음과 같은 코드가 많이 있습니다.

kw1 = some_value
kw2 = some_value
kw3 = some_value
some_func(
    1,
    2,
    kw1=kw1,
    kw2=kw2,
    kw3=kw3)

보시는 바와 같이 동일한 이름의 키워드 인수에 변수를 할당하는 것은 완전히 의미가 있으므로 공백 없이 볼 수 있는 가독성이 향상됩니다.키워드 인수를 사용하고 있으며 변수를 자체에 할당하지 않고 있다는 것을 더 쉽게 인식할 수 있습니다.

또한 매개 변수는 동일한 줄로 이동하는 경향이 있는 반면, 할당은 일반적으로 각각 고유한 줄로 이동하므로 공간 절약이 중요한 문제가 될 수 있습니다.

장단점이 있습니다.

저는 PEP8 호환 코드가 어떻게 읽히는지 매우 싫어합니다.나는 그 주장에 동의하지 않습니다.very_long_variable_name=another_very_long_variable_name보다 더 인간적으로 읽을 수 있습니다.very_long_variable_name = another_very_long_variable_name이것은 사람들이 읽는 방식이 아닙니다.그것은 추가적인 인지 부하입니다. 특히 구문 강조가 없는 경우에는 더욱 그렇습니다.

하지만 상당한 이점이 있습니다.간격 규칙을 준수하면 도구를 사용하여 매개 변수를 단독으로 검색하는 것이 훨씬 효과적입니다.

기본 인수로 very_long_variable_name을 사용하지 않습니다.이를 고려해 보십시오.

func(1, 2, axis='x', angle=90, size=450, name='foo bar')

이 이상:

func(1, 2, axis = 'x', angle = 90, size = 450, name = 'foo bar')

또한 변수를 기본값으로 사용하는 것은 그다지 의미가 없습니다.아마도 일부 상수 변수(실제 상수는 아님)와 같은 경우에는 모두 대문자이지만 가능한 한 짧은 이름을 사용할 것입니다.그러니 다른 사람은...

IMO에서 인수를 위한 공간을 생략하면 인수/값 쌍을 보다 명확하게 시각적으로 그룹화할 수 있습니다. 따라서 덜 복잡해 보입니다.

나에게 그것은 코드를 더 쉽게 읽을 수 있게 해주기 때문에 좋은 관습입니다.

변수 할당과 함수 키워드 할당의 스타일 측면에서 핵심적인 차이점은 하나만 있어야 한다는 것입니다.=일반적으로 여러 개가 있는 반면 전자를 위한 선에서.=후자를 위한 선에 있는 아들.

다른 고려 사항이 없다면, 우리는 더 선호합니다.foo = 42로.foo=42왜냐하면 후자는 일반적으로 등호 형식이 아니며 전자는 변수와 값을 공백으로 시각적으로 구분하기 때문입니다.

하지만 한 줄에 여러 개의 과제가 있을 때는f(foo=42, bar=43, baz=44)로.f(foo = 42, bar = 43, baz = 44)전자는 여러 할당을 공백으로 시각적으로 구분하는 반면 후자는 그렇지 않기 때문에 키워드/값 쌍이 어디에 있는지 확인하기가 조금 어렵습니다.

여기에 또 다른 방법이 있습니다: 관습 뒤에는 일관성이 있습니다.이러한 일관성은 다음과 같습니다. "가장 높은 수준의 분리"는 공간을 통해 시각적으로 명확해집니다.모든 낮은 수준의 분리는 그렇지 않습니다(높은 수준을 구분하는 공백과 혼동될 수 있기 때문입니다).변수 할당의 경우 가장 높은 수준의 분리는 변수와 값 사이에 있습니다.함수 키워드 할당의 경우, 가장 높은 수준의 분리는 개별 할당 자체 사이에 있습니다.

저는 개인적으로 모든 할당 연산자 전후의 단일 공간이=서로 다른 채널의 토큰을 구별하는 데 도움이 되기 때문에(즉, 변수/매개 변수 이름 토큰을 할당 연산자 토큰에서 분리) 프로그래밍/매개 변수 언어와 관계없이 표준이어야 합니다.=값 토큰/식 값 토큰 시퀀스에서).

세 개의 서로 다른 채널의 세 개 토큰을 하나의 "매개 변수-이름-할당-연산자-값/표현-튜플" 토큰으로 뭉치는 것은 읽기 어렵고 직관적이지도 않습니다.

예를 들어, 다음과 같이 구분되지 않는 토큰을 고려해 보겠습니다.

def my_func(par1: str, par2: str):
    print('%s %s' % (par1, par2))

cond = 'conditional string'
my_func(par1='string with a lot of spaces',
        par2=cond if cond is not None else 'no string')

허용, 전달된 값par2아마도 "3차" 식으로 전달되기 보다는 변수에 저장되어야 할 것입니다...

par2 = cond if cond is not None else 'no string'
my_func(par1='string with a lot of spaces', 
        par2=par2)

...하지만 어쨌든 3차 표현식을 사용하기로 결정한다면, 할당 연산자 앞과 뒤에 구분 공간을 추가하면 사전 객체(기본적으로 python 매개 변수 시퀀스)처럼 더 읽기 쉽다는 것을 알 수 있습니다.

my_func(par1 = 'string with a lot of spaces', 
        par2 = cond if cond is not None else 'no string')
# OR
par2 = cond if cond is not None else 'no string'
my_func(par1 = 'string with a lot of spaces', 
        par2 = par2)

저는 이것에 대한 몇 가지 이유가 있다고 생각하지만, 제가 단지 합리화하고 있을 수도 있습니다.

1. 공간을 절약하여 더 많은 함수 정의와 호출을 한 줄에 맞출 수 있고 인수 이름 자체에 더 많은 공간을 절약할 수 있습니다.
2. 각 키워드와 값을 결합하면 쉼표 뒤의 공백으로 서로 다른 인수를 더 쉽게 구분할 수 있습니다.이것은 여러분이 얼마나 많은 주장을 했는지 빠르게 볼 수 있다는 것을 의미합니다.
3. 그런 다음 구문은 이름이 같을 수 있는 변수 할당과 구별됩니다.
4. 이 checks와 (a == b호출 내부의 유효한 표현식일 수도 있습니다.

언급URL : https://stackoverflow.com/questions/8853063/pep-8-why-no-spaces-around-in-keyword-argument-or-a-default-parameter-value