-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Python] 타입 힌트 내용 추가 #59
Conversation
Python/README.md
Outdated
@@ -25,6 +27,55 @@ max-line-length = 88 | |||
extend-ignore = E203 | |||
``` | |||
|
|||
## Type Hinting | |||
> [관련 논의](https://github.com/8percent/styleguide/discussions/47) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
관련 참고자료는 문서 최하단이나 주제의 하단에 참고 자료의 형태로 따로 모아두는것은 어떤가요?
논의를 통해 정해진 내용들이 가장 중요한 내용이라 그것을 중심으로 작성해 나가는것이 좋은것 같아서요.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
히스토리보단 결과를 담는 게 중요하다는 점에 동의합니다. 논의를 아예 안적어도 무방할 것 같고, 이 PR과 논의를 #을 사용하여 연결시켜주면 충분할 것 같습니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue와 달리 discussion은 서로 #으로 참조해도 PR 이력에 남지 않네요... 일단 #으로 PR과 discussion 간 서로 언급은 해두고, 관련 논의 줄은 가이드에서 지웠습니다.
Co-authored-by: Wook <twins1040@8percent.kr>
인스턴스 메서드 첫 인자(self), 클래스 메서드 첫 인자(cls)에는 타입 힌트를 생략합니다. | ||
|
||
#### Do | ||
```python | ||
class Car: | ||
def move(self, goal: str) -> str: | ||
return "Move to " + goal | ||
|
||
def get_name(cls) -> str: | ||
return "My Car" | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
p4. 논의가 필요한 내용인 것 같습니다.
PEP673에 따르면, self나 cls에 대해 타입 힌트를 생략하지 않는 것도 괜찮다고 합니다.
물론 python 3.11+ 혹은 typing-extension를 쓰는 경우에 그렇고,
지금은 필요한 경우 적어야 하고, 그 외에는 생략하는 게 좋은 것 같습니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typing-extension은 설치되어 있기 때문에, 모든 경우에 self, cls의 타입힌트를 생략할 수 있습니다.
아래 경우에는 생략하기 애매할 수 있는데, 아직 저희 코드베이스에는 등장하지 않습니다. 해당 경우가 발생하면 다시 의논의 여지가 있긴 하나, 우선 일관성을 고려하여 단정적인 어투의 생략합니다.
를 유지하도록 하겠습니다.
def add(self: Self, other: Self):
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
별개로 get_name() 메서드에 @classmethod
데코레이터가 누락되었네요. 추가하겠습니다.
Discussed in #47
Originally posted by Kirade March 16, 2023
이전 논의에서 타입 힌트에 대해서 어떻게 생각하는지 논의를 진행한적이 있습니다.
#18
최근에 많은 분들이 타입힌팅을 활용해주시기 시작했는데요.
기존에 코드들이 타입힌트가 있지 않다보니, 현재 저희 코드들에 듬성듬성 타입힌팅을 사용하고 있고 저마다 타입힌트를 활용하는 범위 같은것들이 달라서 코드 스타일의 일관성이 떨어져가고 있는 것으로 보입니다. 일관성이 없는 코드는 가독성을 떨어트려 저희의 생산성에 영향을 주는 부분이라고 생각합니다.
개인적으로는 타입 힌트는 클래스나 함수의 매개변수 반환값 등을 정도를 표기하는 방식으로 가볍게 사용하고 있는데요.
다른분들은 어떤 수준으로 사용하고 계신지도 궁금하고, 어떤 방식을 저희 코드의 규칙으로 만들면 좋을지 의견을 부탁드립니다.
Changes
타입 힌트 관련 내용을 python 스타일 가이드에 추가합니다.
논의 필요 사항
아래 사항은 논의에서 다루지 않았으나, 우리 코드베이스에 일반적으로 통용되는 방식입니다. 스타일 가이드에 적었으나, 적어도 좋을지에 대한 의견을 모으고 싶습니다.