From 39284cce3eed69adc328a4389e20a28fef157219 Mon Sep 17 00:00:00 2001
From: DONG GUN LEE <gnyontu39@gmail.com>
Date: Wed, 11 Sep 2024 01:03:23 +0900
Subject: [PATCH] =?UTF-8?q?[8ee3431]=20=EB=B2=88=EC=97=AD=20=EC=9A=94?=
 =?UTF-8?q?=EC=B2=AD=20=F0=9F=92=AC=20(#37)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* merge 8ee3431 🛰

* [8ee3431] 1.1 배경 반영

* [8ee3431] 2.1 Lint 반영

* [8ee3431] 2.2 import 반영

* [8ee3431] 2.3 package 반영

* [8ee3431] 2.4 예외처리 반영

* [8ee3431] 2.5 이름 변경

* [8ee3431] 2.5 변경 가능한 전역 상태 반영

* [8ee3431] 2.6 중첩 반영

* [8ee3431] 2.7 list comprehensions

* [8ee3431] 2.8 기본 반복자와 연산자 반영

* [8ee3431] 2.9 제너레이터 반영

* [8ee3431] 2.10 람다 반영

* [8ee3431] 2.12 기본 인자 값 반영

* [8ee3431] 2.14 True/False 평가 반영

* [8ee3431] 2.16 렉시컬 스코핑 반영

* [8ee3431] 2.17 함수와 메서드 반영

* [8ee3431] 2.18 스레드 반영

* [8ee3431] 2.20 현대의 파이썬 반영

* [8ee3431] 2.20 이름 변경

* [8ee3431] 2.21 Type 주석 반영

* [8ee3431] 3.2 줄 길이 반영

* [8ee3431] 3.4 들여쓰기 반영

* [8ee3431] 3.5 빈 줄 반영

* [8ee3431] 3.7 Shebang_Line 반영

* [8ee3431] 3.8 주석과 docstring 반영

* [8ee3431] 3.10 문자열 반영

* [8ee3431] 3.12 TODO 주석 반영

* [8ee3431] 3.13 import 형식 반영

* [8ee3431] 3.16 네이밍 반영

* [8ee3431] 3.19 Type 주석 방법 반영

* [8ee3431] 4.1 맺음말 반영

* 빌드 경고 수정

* 빌드 경고 수정

* [8ee3431] build
---
 Google Python Style Guide kor.md              |  900 ++++++++------
 .../1.1 \353\260\260\352\262\275.md"          |    2 +-
 .../1. \353\260\260\352\262\275/ReadMe.md"    |    2 +-
 .../2.1 Lint.md"                              |    7 +-
 .../2.10 \353\236\214\353\213\244.md"         |    4 +-
 ... \354\235\270\354\236\220 \352\260\222.md" |   11 +-
 ...4 True, False \355\217\211\352\260\200.md" |    2 +-
 ...4\275\224\355\225\221(Lexical Scoping).md" |    2 +-
 ...224\354\204\234\353\223\234 Decorators.md" |    4 +-
 ...8 \354\212\244\353\240\210\353\223\234.md" |    2 +-
 .../2.2 import.md"                            |   22 +-
 .../2.20 Modern Python.md"                    |   18 -
 .../2.21 Type \354\243\274\354\204\235.md"    |   14 +-
 .../2.3 package.md"                           |    4 +-
 ...10\354\231\270\354\262\230\353\246\254.md" |   11 +-
 ...4\354\227\255 \354\203\201\355\203\234.md" |   40 +
 ...04\354\227\255\353\263\200\354\210\230.md" |   34 -
 .../2.6 \354\244\221\354\262\251.md"          |    2 +-
 .../2.7 list_comprehensions.md"               |   53 +-
 ...0 \354\227\260\354\202\260\354\236\220.md" |    6 +-
 ...10\353\240\210\354\235\264\355\204\260.md" |    4 +-
 .../ReadMe.md"                                |  192 ++-
 ...0 \353\254\270\354\236\220\354\227\264.md" |   18 +-
 .../3.12 TODO \354\243\274\354\204\235.md"    |   31 +-
 .../3.13 import\355\230\225\354\213\235.md"   |   20 +-
 ...6 \353\204\244\354\235\264\353\260\215.md" |   27 +-
 ...4\354\204\235 \353\260\251\353\262\225.md" |  298 +++--
 ... \354\244\204 \352\270\270\354\235\264.md" |   83 +-
 ...44\354\227\254\354\223\260\352\270\260.md" |   34 +-
 .../3.5 \353\271\210 \354\244\204.md"         |    2 +-
 .../3.7 Shebang_Line.md"                      |    2 +-
 ...\274\354\204\235\352\263\274 docstring.md" |  177 ++-
 .../ReadMe.md"                                |  691 +++++++----
 ...1 \353\247\272\354\235\214\353\247\220.md" |    9 +-
 .../ReadMe.md"                                |    9 +-
 Original.md                                   | 1032 ++++++++++-------
 script/build.py                               |    4 +-
 37 files changed, 2329 insertions(+), 1444 deletions(-)
 rename "Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.20 \355\230\204\353\214\200\354\235\230 \355\214\214\354\235\264\354\215\254.md" => "Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.20 Modern Python.md" (58%)
 create mode 100644 "Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.5 \353\263\200\352\262\275 \352\260\200\353\212\245\355\225\234 \354\240\204\354\227\255 \354\203\201\355\203\234.md"
 delete mode 100644 "Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.5 \354\240\204\354\227\255\353\263\200\354\210\230.md"

diff --git a/Google Python Style Guide kor.md b/Google Python Style Guide kor.md
index 68e036b..eb466a1 100644
--- a/Google Python Style Guide kor.md	
+++ b/Google Python Style Guide kor.md	
@@ -9,7 +9,7 @@
     *   [2.2 Imports](#s2.2-imports)
     *   [2.3 Packages](#s2.3-packages)
     *   [2.4 예외](#s2.4-exceptions)
-    *   [2.5 전역 변수](#s2.5-global-variables)
+    *   [2.5 변경 가능한 전역 상태](#25-global-state)
     *   [2.6 중첩/지역/내부 클래스와 함수](#s2.6-nested)
     *   [2.7 Comprehensions & 제너레이터 표현식](#s2.7-list_comprehensions)
     *   [2.8 기본 반복자와 연산자](#s2.8-default-iterators-and-operators)
@@ -67,8 +67,8 @@
         +   [3.19.7 Ignoring Types](#s3.19.7-ignore)
         +   [3.19.8 내부 변수 작성](#s3.19.8-comments)
         +   [3.19.9 튜플 vs 리스트](#s3.19.9-tuples)
-        +   [3.19.10 TypeVar](#s3.19.10-type-var)
-        +   [3.19.11 문자열 Type](#s3.19.11-strings)
+        +   [3.19.10 Type variables](#typevars)
+        +   [3.19.11 문자열 Type](#typing-strings)
         +   [3.19.12 Typing 추가](#s3.19.12-imports)
         +   [3.19.13 조건 Imports](#s3.19.13-conditional-imports)
         +   [3.19.14 Circular 종속](#s3.19.14-circular-deps)
@@ -87,7 +87,7 @@
 - 이 스타일 가이드는 Python 프로그램에서 _해야 할 것들과 하지 말아야 할 것_ 들을 적어놓았습니다.
 - 코드 형식을 정확하게 하는 것들 돕기 위해, 우리는 [settings file for Vim](google_python_style.vim)을 만들었습니다.
 - Emacs 편집기에서는 기본 설정값으로 사용하면 됩니다.
-- 많은 팀에서 형식에 대한 논쟁을 피하기 위해 [yapf](https://github.com/google/yapf/) auto-formatter 을 사용합니다.
+- 많은 팀에서 형식에 대한 논쟁을 피하기 위해 [Black](https://github.com/psf/black) 혹은 [Pyink](https://github.com/google/pyink) auto-formatter 을 사용합니다.
 
 ---
 
@@ -137,7 +137,8 @@
 - 경고를 띄우지 않기 위해, 코드에 라인 단위로 주석을 달아야 합니다.
 
   ```python
-  dict = 'something awful'  # Bad Idea... pylint: disable=redefined-builtin
+  def do_PUT(self):  # WSGI name, so pylint: disable=invalid-name
+    ...
   ```
 
 - `pylint`의 경고는 각각 symbolic name(`empty-docstring`)으로 구별됩니다.
@@ -153,7 +154,7 @@
 - 각 메시지에 대해 자세한 정보를 얻고자 하는 경우 다음과 같은 방법으로 볼 수 있습니다.
 
   ```shell
-  pylint --help-msg=C6409
+  pylint --help-msg=invalid-name
   ```
 
 - `pyling: disable-msg`는 이전에 사용했던 방식으로 이제는 사용되지 않으며 `pylint: disable`를 사용합니다.
@@ -161,7 +162,7 @@
 - 아래 예시를 참고하세요.
 
   ```python
-  def viking_cafe_order(spam: str, beans: str, eggs: Optional[str] = None) -> str:
+  def viking_cafe_order(spam: str, beans: str, eggs: str | None = None) -> str:
       del beans, eggs  # Unused by vikings.
       return spam + spam + spam
   ```
@@ -173,7 +174,7 @@
 
 ### 2.2 Imports
 
-- `import`문을 사용할때 package와 module에 사용하고 개별 클래스나 함수에 대해 사용하면 안됩니다. 다만 [typing 모듈](#s3.19.12-imports), [typing_extensions module](https://github.com/python/typing/tree/master/typing_extensions)에서 가져온 클래스 및 [six.moves module](https://six.readthedocs.io/#module-six.moves)에서의 리디렉션은 이 규칙에서 제외됩니다.
+- `import`문은 개별 타입, 클래스, 함수가 아니라 패키지와 모듈에만 사용하세요. (주: 개별 타입은 기본 자료형, 사용자 정의 클래스를 나타냅니다.)
 
 <a id="s2.2.1-definition"></a>
 
@@ -199,8 +200,13 @@
 
 - `import x`를 패키지와 모듈을 import할때 사용하세요.
 - `from x import y`를 `x`가 패키지의 접두어이고 `y`가 접두어가 없는 모듈일때 사용하세요.
-- 만약 `y` 로 이름이 지어진 두 모듈이 import되거나 `y` 가 불필요하게 너무 긴 이름을 가졌다면 `from x import y as z`를 사용세요.
-- `import y as z`를 `z` 가 공식적인 약어인 경우에만 사용하세요(e.g., `np` 는 `numpy` 를 의미합니다.)
+- 다음과 같은 상황에서는 `from x import y as z` 를 사용하세요.
+  - `y`라는 이름을 가진 두 개의 모듈을 가져옵니다.
+  - `y`는 현재 모듈에 정의된 최상위 이름과 충돌합니다.
+  - `y`는 공개 API의 일부인 공통 매개변수 이름(예: 'features')과 충돌합니다.
+  - `y`는 불편할 정도로 긴 이름입니다.
+  - `y`는 코드 컨텍스트에서 너무 일반적입니다(예: `from storage.file_system import options as fs_options`).
+- `import y as z`를 `z` 가 공식적인 약어인 경우에만 사용하세요(e.g., `import numpy as np`)
 
 - 예를들어 `sound.effects.echo`모듈이 import 된다면 아래와 같습니다.
 
@@ -214,6 +220,17 @@
 - 모듈이 같은 패키지에 있더라도 전체 패키지 이름을 사용하세요.
 - 이는 무심코 패키지를 두번 import 하는것을 예방하는 것에 도움이 됩니다.
 
+<a id="imports-exemptions"></a>
+
+##### 2.2.4.1 예외
+
+- 이 규칙의 예외는 다음과 같습니다.
+  - 다음 모듈의 심볼은 정적 분석 및 타입 검사를 지원하는 데 사용됩니다.
+    - [`typing` module](#typing-imports)
+    - [`collections.abc` module](#typing-imports)
+    - [`typing_extensions` module](https://github.com/python/typing_extensions/blob/main/README.md)
+  - [six.moves module](https://six.readthedocs.io/#module-six.moves)의 리다이렉션입니다.
+
 ---
 <a id="s2.3-packages"></a>
 
@@ -248,7 +265,7 @@
     import absl.flags
     from doctor.who import jodie
 
-    FLAGS = absl.flags.FLAGS
+    _FOO = absl.flags.DEFINE_string(...)
     ```
 
     ```python
@@ -256,7 +273,7 @@
     from absl import flags
     from doctor.who import jodie
 
-    FLAGS = flags.FLAGS
+    _FOO = flags.DEFINE_string(...)
     ```
 
   - 부적절한 예 _(이 파일은 `doctor/who/` 에 있다고 가정하고 `jodie.py`또한 존재한다고 가정합니다.)_
@@ -304,10 +321,8 @@
 
 ##### 예외는 다음과 같은 조건을 만족해야 합니다
 
-- 적절한 경우 내장 예외 클래스를 사용하세요.
-- 예를 들어, 만약 양수를 예상하는데 음수가 통과한다면 `ValueError`를 발생시는 것이 그 예입니다.
-- 공공 API에 있는 인수의 값을 검증하기 위해 `assert`문을 사용하지마세요.
-- `assert`는 올바른 사용이나 예상치 못한 이벤트 발생을 나타내는 것이 아니라 내부적 정확성을 보장하기 위해 사용됩니다. 만약 나중에 예외가 필요하다면, raise문을 실행하세요.
+- 내장 예외 클래스를 사용하는 데에 문제가 없다면 사용합니다. 예를 들어, 함수 인자를 검증할 때와 같은 프로그래밍 오류나 위반된 전제조건을 나타내기 위해 `ValueError`를 발생시키세요.
+- `assert` 문을 조건문이나 전제조건 검증 대신 사용하지 마세요. application logic에 중요하지 않아야 합니다. `assert`문을 제거해도 코드가 정상적으로 작동한다면, 그것이 기준이 될 수 있습니다. assert 조건문은 평가될 것이라고 [보장되지 않습니다](https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement). [pytest](https://pytest.org)기반의 테스트에서는 `assert` 문을 사용하여 기대값을 검증하는 것이 적절하고 예상됩니다
 
   - 올바른 예
 
@@ -326,9 +341,10 @@
         if minimum < 1024:
             raise ValueError(f'Min. port must be at least 1024, not {minimum}.')
         port = self._find_next_open_port(minimum)
-        if not port:
+        if port is None:
           raise ConnectionError(
               f'Could not connect to service on port {minimum} or higher.')
+        # 이 코드의 결과는 이 assert에 의존하지 않습니다.
         assert port >= minimum, (
             f'Unexpected port {port} when minimum was {minimum}.')
         return port
@@ -346,8 +362,10 @@
         The new minimum port.
         """
         assert minimum >= 1024, 'Minimum port must be at least 1024.'
+        # 이 코드는 이전 assert에 의존합니다.
         port = self._find_next_open_port(minimum)
         assert port is not None
+        # 반환 값에 대한 타입 검사는 assert에 의존합니다.
         return port
     ```
 
@@ -360,16 +378,19 @@
 
 ---
 <a id="s2.5-global-variables"></a>
+<a id="25-global-variables"></a>
+<a id="s2.5-global-state"></a>
+<a id="25-global-state"></a>
 
-### 2.5 전역 변수
+### 2.5 변경 가능한 전역 상태
 
-- 전역 변수를 사용하지 마세요.
+- 변경 가능한 전역 상태를 사용하지 마세요.
 
 <a id="s2.5.1-definition"></a>
 
 #### 2.5.1 정의
 
-- 모듈이나 클래스 속성으로 선언된 변수를 말합니다.
+- 프로그램 실행 중 변경될 수 있는 모듈 수준의 값이나 클래스 속성을 말합니다.
 
 <a id="s2.5.2-pros"></a>
 
@@ -378,21 +399,24 @@
 - 가끔 편리합니다.
 
 <a id="s2.5.3-cons"></a>
+<a id="253-cons"></a>
+<a id="global-variables-cons"></a>
 
 #### 2.5.3 단점
 
-- import되는 동안 모듈의 동작이 변경될 수도 있습니다. 왜냐하면 전역 변수의 할당은 모듈을 처음 import를 할때 수행이 되기 때문입니다.
+- 캡슐화가 깨집니다.
+  - 이러한 설계는 유효한 목표를 달성하기 어렵게 만들 수 있습니다. 예를 들면, 전역 상태를 사용하여 데이터베이스 연결을 관리하는 경우, 두 개의 서로 다른 데이터베이스를 동시에 연결하는 것이 어려워질 수 있습니다(e.g., 마이그레이션 중 차이를 계산할 때). 전역 레지스트리에서도 유사한 문제가 쉽게 발생할 수 있습니다.
+- 모듈이 처음 임포트될 때 전역 변수에 대한 할당이 이루어지기 때문에, 모듈의 동작을 임포트 중에 변경할 가능성이 있습니다.
 
 <a id="s2.5.4-decision"></a>
+<a id="254-decision"></a>
+<a id="global-variables-decision"></a>
 
 #### 2.5.4 결론
 
-- 전역 변수를 사용하지 마세요.
-
-- 전역변수는 기술적으로는 변수이지만, module-level 상수가 허용되고 권장됩니다.
-- 예를들어 `_MAX_HOLY_HANDGRENADE_COUNT = 3`. 상수는 반드시 모든 공백 `_`를 넣어서 이름을 만들어야 합니다.
-- 만약 전역변수가 필요하다면 module-level에서 선언되고 모듈 내부에서 이름에 `_`를 붙여서 만들어져야 합니다.
-- 외부 접근은 반드시 public단위의 module-level 함수를 통해서 동작되어야 합니다. [Naming](#s3.16-naming)을 참고하세요.
+- 변경 가능한 전역 상태를 사용하지 마세요.
+  - 전역 상태를 사용하는 것이 드물게 필요한 경우, 변경 가능한 전역 엔티티는 모듈 수준이나 클래스 속성으로 선언하고, 이름 앞에 `_`를 붙여 내부적으로 사용해야 합니다. 필요한 경우, 변경 가능한 전역 상태에 대한 외부 접근은 공개 함수나 클래스 메소드를 통해 이루어져야 합니다. [Naming](#s3.16-naming)를 참고하세요. 변경 가능한 전역 상태를 사용하는 설계 이유에 대해서는 주석에 설명하거나 링크된 문서에서 설명해 주세요.
+  - 모듈 수준의 상수는 허용되며 권장됩니다. 예를 들어, 내부 용도의 상수에는 `_MAX_HOLY_HANDGRENADE_COUNT = 3`를 사용하고, Public API 상수에는 `SIR_LANCELOTS_FAVORITE_COLOR = "blue"`를 사용하세요. 상수는 모두 대문자와 밑줄을 사용하여 명명해야 합니다. [Naming](#s3.16-naming)를 참고하세요.
 
 ---
 <a id="s2.6-nested"></a>
@@ -415,7 +439,7 @@
 #### 2.6.2 장점
 
 - 제한된 스코프 내에서 사용하는 유틸리티 클래스와 함수의 정의를 허용합니다.
-- [ADT](http://www.google.com/url?sa=D&q=http://en.wikipedia.org/wiki/Abstract_data_type)가 무엇인지 참고하세요.
+- [ADT](https://ko.wikipedia.org/wiki/추상_자료형)가 무엇인지 참고하세요.
 - 일반적으로 데코레이터를 구현할 때 사용됩니다.
 
 <a id="s2.6.3-cons"></a>
@@ -464,19 +488,17 @@
 
 #### 2.7.4 결론
 
-- 복잡하지 않은 상황에서 사용하세요. 각각의 부분은 반드시 한 라인에서 끝나야 합니다.
-- map, for문, filter 표현식이 그 예입니다. 중첩 for문이나 filter문은 허용되지 않습니다.
-- loop문을 통해 코드를 단순화 할 수 있으면 사용하세요.
+- 컴프리헨션(comprehension)은 허용되지만, 여러 개의 for 절이나 필터 표현식은 허용되지 않습니다. 간결함보다는 가독성을 우선시하세요.
 - 올바른 예
 
   ```python
   result = [mapping_expr for value in iterable if filter_expr]
 
-  result = [{'key': value} for value in iterable
-              if a_long_filter_expression(value)]
-
-  result = [complicated_transform(x)
-              for x in iterable if predicate(x)]
+  result = [
+      is_valid(metric={'key': value})
+      for value in interesting_iterable
+      if a_longer_filter_expression(value)
+  ]
 
   descriptive_name = [
       transform({'key': key, 'value': value}, color='black')
@@ -486,37 +508,32 @@
 
   result = []
   for x in range(10):
-      for y in range(5):
-          if x * y > 10:
-              result.append((x, y))
-
-  return {x: complicated_transform(x)
-          for x in long_generator_function(parameter)
-          if x is not None}
-
-  squares_generator = (x**2 for x in range(10))
+    for y in range(5):
+      if x * y > 10:
+        result.append((x, y))
+  return {
+      x: complicated_transform(x)
+      for x in long_generator_function(parameter)
+      if x is not None
+  }
+  return (x**2 for x in range(10))
 
   unique_names = {user.name for user in users if user is not None}
-
-  eat(jelly_bean for jelly_bean in jelly_beans
-      if jelly_bean.color == 'black')
   ```
 
 - 부적절한 예
 
   ```python
-  result = [complicated_transform(
-                  x, some_argument=x+1)
-              for x in iterable if predicate(x)]
-
   result = [(x, y) for x in range(10) for y in range(5) if x * y > 10]
 
-  return ((x, y, z)
-          for x in range(5)
-          for y in range(5)
-          if x != y
-          for z in range(5)
-          if y != z)
+  return (
+      (x, y, z)
+      for x in range(5)
+      for y in range(5)
+      if x != y
+      for z in range(5)
+      if y != z
+  )
   ```
 
 ---
@@ -543,7 +560,7 @@
 
 #### 2.8.3 단점
 
-- 메소드 이름을 읽어도 객체의 타입을 유추할 수 없습니다.(e.g. `has_key()`는 딕셔너리를 의미합니다.) 이건 이점이 될 수도 있습니다.
+- 메소드 이름을 읽어도 객체의 타입을 유추할 수 없습니다.(변수에 타입 주석이 없는 경우) 이건 이점이 될 수도 있습니다.
 
 <a id="s2.8.4-decision"></a>
 
@@ -556,20 +573,16 @@
 
   ```python
   for key in adict: ...
-  if key not in adict: ...
   if obj in alist: ...
   for line in afile: ...
   for k, v in adict.items(): ...
-  for k, v in six.iteritems(adict): ...
   ```
 
 - 부적절한 예
 
   ```python
   for key in adict.keys(): ...
-  if not adict.has_key(key): ...
   for line in afile.readlines(): ...
-  for k, v in dict.iteritems(): ...
   ```
 
 ---
@@ -597,13 +610,15 @@
 
 #### 2.9.3 단점
 
-- 없습니다.
+- 제너레이터 내의 지역 변수는 제너레이터가 모두 소모되거나 자체적으로 가비지 컬렉션될 때까지 가비지 컬렉션되지 않습니다.
 
 <a id="s2.9.4-decision"></a>
 
 #### 2.9.4 결론
 
 - 제너레이터 함수에서 docstring에 대해 "Returns:"보다 "Yields:"를 사용하세요.
+- 제너레이터가 비용이 많이 드는 자원을 관리하는 경우, 정리 작업을 강제로 수행해야 합니다.
+- 정리 작업을 잘 수행하는 방법 중 하나는 제너레이터를 컨텍스트 매니저로 감싸는 것입니다 ([PEP-0533](https://peps.python.org/pep-0533/)).
 
 ---
 <a id="s2.10-lambda-functions"></a>
@@ -636,9 +651,7 @@
 
 #### 2.10.4 결론
 
-- 람다를 한 줄로 사용하세요. 만약 코드 내부에 있는 람다 함수가 60~80글자 수 정도로 길다면 그건 아마 더 일반적인 
-  [Lexical Scoping(렉시컬 스코핑)](#s2.16-lexical-scoping)으로 정의하는게 나을 것입니다.
-
+- 람다 함수는 허용하지만, 람다 함수 내부의 코드가 여러 줄에 걸치거나 60-80자를 넘는 경우, 일반적인 [중첩 함수](#s2.16-lexical-scoping)로 정의하는 것이 더 나을 수 있습니다.
 - 곱셈 같은 일반 연산자에서는 `operator`모듈 대신에 람다 함수를 사용하세요.
 - 예를 들어, `operator.mul`을 `lambda x,y : x * y` 처럼 사용하시면 됩니다.
 
@@ -748,7 +761,7 @@
   def foo(a, b=None):
       if b is None:
           b = []
-  def foo(a, b: Optional[Sequence] = None):
+  def foo(a, b: Sequence | None = None):
       if b is None:
           b = []
   def foo(a, b: Sequence = ()):  # tuples은 불변하기 때문에 사용 가능합니다.
@@ -758,13 +771,16 @@
 - 부적절한 예
 
   ```python
+  from absl import flags
+  _FOO = flags.DEFINE_string(...)
+
   def foo(a, b=[]):
       ...
-  def foo(a, b=time.time()):  # 모듈이 로드가 될 때의 시간인가???
+  def foo(a, b=time.time()):  # `b`가 이 모듈이 로드된 시간을 나타내는 것인가요?
       ...
-  def foo(a, b=FLAGS.my_thing):  # sys.argv는 아직 구문 분석되지 않았습니다...
+  def foo(a, b=_FOO.value):  # sys.argv는 아직 구문 분석되지 않았습니다...
       ...
-  def foo(a, b: Mapping = {}):  # 확인되지 않은 코드로 전달 될 수 있습니다...
+  def foo(a, b: Mapping = {}):  # 확인되지 않은 코드로 전달 될 수 있습니다.
       ...
   ```
 
@@ -817,7 +833,7 @@
 
 ### 2.14 True/False 평가
 
-- 가능한 경우 "암묵적(implicit)" `false`를 사용하세요.
+- 가능한 경우 "암묵적(implicit)" `false`를 사용하세요. (몇 가지 주의사항이 있지만)
 
 <a id="s2.14.1-definition"></a>
 
@@ -917,7 +933,7 @@
 
 #### 2.16.3 단점
 
-- 혼란스러운 버그로 이어질 수 있습니다. [PEP-0227](http://www.google.com/url?sa=D&q=http://www.python.org/dev/peps/pep-0227/)에서 자세한 정보를 확인할 수 있습니다.
+- [PEP-0227](https://peps.python.org/pep-0227)을 기반으로 한 이 예시와 같이 혼란스러운 버그를 초래할 수 있습니다.
 
   ```python
   i = 4
@@ -992,16 +1008,16 @@
 
 - Decorator는 분명한 이점이 있더라도 현명하게 사용해야 합니다. Decorator는 import와 명명 지침을 따라야 합니다. Decorator pydoc는 decorator 함수 임을 분명히 명시해야합니다. dcorator를 위한 유닛 테스트(unit test)를 사용해야합니다.
 - Decorator(예. 파일, 소켓, 데이터베이스 연결 등) 를 실행할 때 (`pydoc` 혹은 기타 도구를 import 시간에 가져올 때) 사용 못할 수 있으므로 Decorator의 외부 의존성을 피하세요. 유효한 매개변수를 가진 Decorator은 모든 경우에 작동할 수 있도록 보장되어야 합니다.
-- Decorator는 "Top level code"의 특별한 경우일 때에는 [main](#s3.17-main) 항목에 자세한 내용이 있습니다.
+- Decorator는 "Top-level code"의 특별한 경우일 때에는 [main](#s3.17-main) 항목에 자세한 내용이 있습니다.
 - 기존 라이브러리에 정의된 API와 통합하기 위해 강제하지 않는 한 "staticmethod"를 사용하지 마세요. 대신 모듈 레벨 함수를 쓰세요.
-- 프로세스 전체 캐시 등 필요한 global state를 수정하는 명명된 생성자 또는 클래스별 루틴을 작성할 때만 "classmethod"를 사용하세요.
+- classmethod는 명명된 생성자를 작성하거나 프로세스 전체 캐시와 같은 필수 전역 상태를 수정하는 클래스 특정 루틴을 작성할 때만 사용하세요.
 
 ---
 <a id="s2.18-threading"></a>
 
 ### 2.18 스레드
 
-- 내장된 타입의 원자성에 의존하지 마세요. 딕셔너리와 같은 Python의 내장된 타입은 원자 형태로 조작할 수 있지만 그러지 않은 경우(예: `__hash__`이나 `__eq__`가 Python 함수로 구현되는 경우)도 있으며 원자로 되어있다고 신뢰하면 안 됩니다. 또한, 원자 변수 할당에 의존해서는 안 됩니다. (결국, 딕셔너리에 달려있기 때문입니다) 스레드 간 데이터를 통신하는 데 선호하는 방법으로 큐 모듈의 `Queue` 데이터 타입을 사용하세요. 그렇지 않으면 threading 모듈이나 locking primitives를 사용하세요. lower-level lock 대신해 Condition variables와 `threading.Condition`를 선호하세요.
+- 내장된 타입의 원자성에 의존하지 마세요. 딕셔너리와 같은 Python의 내장된 타입은 원자 형태로 조작할 수 있지만 그러지 않은 경우(예: `__hash__`이나 `__eq__`가 Python 함수로 구현되는 경우)도 있으며 원자로 되어있다고 신뢰하면 안 됩니다. 또한, 원자 변수 할당에 의존해서는 안 됩니다. (결국, 딕셔너리에 달려있기 때문입니다) 스레드 간 데이터를 통신하는 데 선호하는 방법으로 `queue` 모듈의 `Queue` 데이터 타입을 사용하세요. 그렇지 않으면 `threading` 모듈이나 locking primitives를 사용하세요. lower-level lock 대신해 Condition variables와 `threading.Condition`를 선호하세요.
 
 ---
 <a id="s2.19-power-features"></a>
@@ -1079,25 +1095,7 @@
   from __future__ import generator_stop
   ```
 
-- 2.7 버전을 계속 지원해야하는 부담이 있는 레거시 코드의 경우
-
-  ```python
-  from __future__ import absolute_import
-  from __future__ import division
-  from __future__ import print_function
-  ```
-
 - 자세한 내용은 [Python future statement definitions](https://docs.python.org/3/library/__future__.html) 문서를 읽어보세요.
-- 코드가 충분히 현대적인 환경에서만 사용된다는 확신이 들 때까지 이러한 import를 제거하지 마세요.
-- 현재 코드에서 특정 향후 import를 통해 활성화되는 기능을 현재 사용하지 않더라도 파일에 해당 기능을 유지하면 나중에 코드가 이전 동작에 따라 실수로 수정되는 것을 방지할 수 있습니다.
-- 적절하다고 생각되는 다른 `from __future__` import 문을 사용하세요.
-- 2.7버전 내에 여러 위치에서 도입된 암시적 기본 코덱 변환 결과로 인해 확실하지 않았기 때문에 2.7버전에 대한 권장 사항에 `unicode_literals`를 포함하지 않았습니다.
-- 대부분의 이중 버전 2-3 코드는 필요한 경우 `b''` 와 `u''` q바트와 유니코드 문자열 리터럴을 명시적으로 사용하는 것이 더 나았습니다.
-
-##### six, future 그리고 past 라이브러리
-
-- 프로젝트가 여전히 Python 2, 3 모두에서 사용을 지원해야하는 경우 적합하다고 판단되는 대로 [six](https://pypi.org/project/six/), [future](https://pypi.org/project/future/), 및 [past](https://pypi.org/project/past/) 라이브러리를 사용하세요.
-- 코드를 더 깨끗하고 삶을 더 쉽게 만들기 위해 존재합니다.
 
 ---
 <a id="s2.21-type-annotated-code"></a>
@@ -1105,8 +1103,8 @@
 
 ### 2.21 Type 주석
 
-- Python 3에서 타입의 정보를 [PEP-484](https://www.python.org/dev/peps/pep-0484/)의 참고해서 주석으로 달 수 있습니다. 그리고 빌드 할 때 [pytype](https://github.com/google/pytype)같은 타입검사도구를 사용하세요.
-- Type에 대한 주석은 소스 안이나 [stub pyi 파일](https://www.python.org/dev/peps/pep-0484/#stub-files)에 있을 수 있습니다. 가능하면 주석은 소스안에 있어야 합니다. 타사 또는 확장 모듈에는 pyi 파일을 사용하세요.
+- Python에서 타입의 정보를 [PEP-484](https://www.python.org/dev/peps/pep-0484/)의 참고해서 주석으로 달 수 있습니다. 그리고 빌드 할 때 [pytype](https://github.com/google/pytype)같은 타입검사도구를 사용하세요.
+- Type에 대한 주석은 소스 안이나 [stub pyi 파일](https://peps.python.org/pep-0484/#stub-files)에 있을 수 있습니다. 가능하면 주석은 소스안에 있어야 합니다. 타사 또는 확장 모듈에는 pyi 파일을 사용하세요.
 
 <a id="s2.21.1-definition"></a>
 
@@ -1115,21 +1113,15 @@
 - Type의 주석(혹은 Type 정보)은 함수나 메서드의 인자값이나 반환값입니다
 
   ```python
-  def func(a: int) -> List[int]:
+  def func(a: int) -> list[int]:
   ```
 
-- [PEP-526](https://www.python.org/dev/peps/pep-0526/)구문 처럼 변수의 type을 선언할 때 사용합니다.
+- [PEP-526](https://peps.python.org/pep-0526/)구문 처럼 변수의 type을 선언할 때 사용합니다.
 
   ```python
   a: SomeType = some_func()
   ```
 
-- legacy Python version을 지원해야한다면 코드에 type 설명을 추가합니다.
-
-  ```python
-  a = some_func()  # type: SomeType
-  ```
-
 <a id="s2.21.2-pros"></a>
 
 #### 2.21.2 장점
@@ -1175,10 +1167,10 @@
     - 경로이름이나 URLs와 같은 공백을 포함하지 않는 긴 모듈수준 문자상수는 여러 줄에 나누어 기록하기 불편할 경우
     - Pylint 비활성화 주석문 (e.g.: `# pylint: disable=invalid-name`)
 
-- 3개 이상의 컨텍스트 매니저를 요구하는 `with` 구문을 제외하고 백슬래쉬(`\`) 를 이용한 문장연장을 사용하지 마세요.
-
-- Python의 [소/중/대 괄호 내부의 묵시적 라인결합](http://docs.python.org/reference/lexical_analysis.html#implicit-line-joining)을 사용하세요.
+- [명시적인 줄 연속](https://docs.python.org/3/reference/lexical_analysis.html#explicit-line-joining)을 위해 백슬래시를 사용하지 마세요.
+- 대신에 Python의 [소/중/대 괄호 내부의 묵시적 라인결합](http://docs.python.org/reference/lexical_analysis.html#implicit-line-joining)을 사용하세요.
 - 필요하다면, 구문 양쪽에 추가로 괄호를 더할 수 있습니다.
+- 이 규칙은 문자열 내에서 백슬래시로 이스케이프된 개행을 금지하지 않습니다(아래 [참조](#strings)).
 
   - 올바른 예
 
@@ -1186,8 +1178,29 @@
     foo_bar(self, width, height, color='black', design=None, x='foo',
     emphasis=None, highlight=0)
 
-        if (width == 0 and height == 0 and
-            color == 'red' and emphasis == 'strong'):
+    if (width == 0 and height == 0 and
+         color == 'red' and emphasis == 'strong'):
+     (bridge_questions.clarification_on
+      .average_airspeed_of.unladen_swallow) = 'African or European?'
+     with (
+         very_long_first_expression_function() as spam,
+         very_long_second_expression_function() as beans,
+         third_thing() as eggs,
+     ):
+       place_order(eggs, beans, spam, beans)
+    ```
+
+  - 부적절한 예
+
+    ```python
+    if width == 0 and height == 0 and \
+         color == 'red' and emphasis == 'strong':
+     bridge_questions.clarification_on \
+         .average_airspeed_of.unladen_swallow = 'African or European?'
+     with very_long_first_expression_function() as spam, \
+           very_long_second_expression_function() as beans, \
+           third_thing() as eggs:
+       place_order(eggs, beans, spam, beans)
     ```
 
 - 만약 리터럴 문자열을 한 줄에 표현하기 어렵다면 아래와 같이 괄호를 이용하여 묵시적 라인결합을 사용하세요.
@@ -1197,56 +1210,55 @@
       'long long long long long long string')
   ```
 
-- 주석의 경우 긴 URLs 들은 한줄에 표현하세요.
+- 가능한 가장 높은 구문 수준에서 줄을 나누는 것을 선호하세요. 줄을 두 번 나눠야 하는 경우, 두 번 모두 동일한 구문 수준에서 나누세요.
 
   - 올바른 예
 
     ```python
-    # See details at
-    # http://www.example.com/us/developer/documentation/api/content/v2.0/csv_file_name_extension_full_specification.html
+    bridgekeeper.answer(
+         name="Arthur", quest=questlib.find(owner="Arthur", perilous=True))
+     answer = (a_long_line().of_chained_methods()
+               .that_eventually_provides().an_answer())
+     if (
+         config is None
+         or 'editor.language' not in config
+         or config['editor.language'].use_spaces is False
+     ):
+       use_tabs()
     ```
 
   - 부적절한 예
 
     ```python
-    # See details at
-    # http://www.example.com/us/developer/documentation/api/content/\
-    # v2.0/csv_file_name_extension_full_specification.html
+    bridgekeeper.answer(name="Arthur", quest=questlib.find(
+        owner="Arthur", perilous=True))
+    answer = a_long_line().of_chained_methods().that_eventually_provides(
+        ).an_answer()
+    if (config is None or 'editor.language' not in config or config[
+        'editor.language'].use_spaces is False):
+      use_tabs()
     ```
 
-- 3줄 이상이 필요한 `with` 구문을 정의할 때는 백슬래쉬(`\`) 를 이용한 문장연장이 허용됩니다. 2줄인 경우 네스티드 `with`를 사용하세요
+- 주석의 경우 긴 URLs 들은 한줄에 표현하세요.
 
   - 올바른 예
 
     ```python
-        with very_long_first_expression_function() as spam, \
-            very_long_second_expression_function() as beans, \
-            third_thing() as eggs:
-            place_order(eggs, beans, spam, beans)
+    # See details at
+    # http://www.example.com/us/developer/documentation/api/content/v2.0/csv_file_name_extension_full_specification.html
     ```
 
   - 부적절한 예
 
     ```python
-    with VeryLongFirstExpressionFunction() as spam, \
-            VeryLongSecondExpressionFunction() as beans:
-        PlaceOrder(beans, spam)
-    ```
-
-  - 올바른 예
-
-    ```python
-    with very_long_first_expression_function() as spam:
-        with very_long_second_expression_function() as beans:
-            place_order(beans, spam)
+    # See details at
+    # http://www.example.com/us/developer/documentation/api/content/\
+    # v2.0/csv_file_name_extension_full_specification.html
     ```
 
 - 위의 예시에서 각 요소에 사용된 들여쓰기를 잘 기억하세요. 더 자세한 정보는 [들여쓰기](#s3.4-indentation) 챕터를 확인하세요.
+- 위에서 언급되지 않은 상황에서 한 줄의 길이가 80자를 초과함에도 [Black](https://github.com/psf/black) 혹은 [Pyink](https://github.com/google/pyink) 오토포메터가 별다른 도움을 주지 못한다면 80자 이상 초과가 허용됩니다. 작성자는 상식적인 수준내에서 위 문서의 사항을 참고하여 줄을 분리하는것이 바람직합니다.
 
-위에서 언급되지 않은 상황에서 한 줄의 길이가 80자를 초과함에도 
-[yapf](https://github.com/google/yapf/)
-오토포메터가 별다른 도움을 주지 못한다면 80자 이상 초과가 허용됩니다.  
-작성자는 상식적인 수준내에서 위 문서의 사항을 참고하여 줄을 분리하는것이 바람직합니다.
 ---
 <a id="s3.3-parentheses"></a>
 
@@ -1293,26 +1305,26 @@
 
 - 코드를 작성할 때 _4 칸_ 들여쓰기를 하세요.
 
-- 탭을 사용하거나 탭과 스페이스를 섞어서 사용하지 마세요.
-- 묵시적 문장연장의 경우 [line length](#s3.2-line-length) 섹션의 예시처럼 동일한 문장에 포함된 요소들을 수직정렬하거나 첫 열린괄호 이후로는 아무것도 없는 4 칸 hanging indent 를 적용하여야 합니다.
+- 탭을 절대 사용하지 마세요. 암시된 줄 연속은 래핑된 요소를 수직으로 정렬해야 하며([줄 길이 예제](#s3.2-line-length) 참조), 또는 4개의 공백을 사용하여 행을 들여쓰기 하세요.
+- 닫는 괄호(원, 대각선 또는 중괄호)는 표현식의 끝에 배치하거나 별도의 줄에 배치할 수 있지만, 이 경우 해당 여는 괄호와 같은 줄에 들여쓰기해야 합니다.
 
 - 올바른 예
 
   ```python
-  # Aligned with opening delimiter
+  # 여는 구분 기호와 정렬됨
   foo = long_function_name(var_one, var_two,
                           var_three, var_four)
   meal = (spam,
           beans)
 
-  # Aligned with opening delimiter in a dictionary
+  # 딕셔너리의 여는 구분 기호와 정렬됨
   foo = {
       'long_dictionary_key': value1 +
                              value2,
       ...
   }
 
-  # 4-space hanging indent; nothing on first line
+  # 4칸 공백의 걸쳐서 들여쓰기, 첫 번째 줄에는 아무것도 없음
   foo = long_function_name(
       var_one, var_two, var_three,
       var_four)
@@ -1320,7 +1332,16 @@
       spam,
       beans)
 
-  # 4-space hanging indent in a dictionary
+  # 4칸 공백의 걸쳐서 들여쓰기; 첫 번째 줄에는 아무것도 없음, 닫는 괄호는 새 줄에 배치
+  foo = long_function_name(
+      var_one, var_two, var_three,
+      var_four
+  )
+  meal = (
+      spam,
+      beans,
+  )
+  # 딕셔너리에서 4칸 공백의 걸쳐서 들여쓰기
   foo = {
       'long_dictionary_key':
           long_dictionary_value,
@@ -1331,18 +1352,18 @@
 - 부적절한 예
 
   ```python
-  # Stuff on first line forbidden
+  # 첫 번째 줄에 내용이 있어서는 안 됩니다.
   foo = long_function_name(var_one, var_two,
       var_three, var_four)
   meal = (spam,
       beans)
 
-  # 2-space hanging indent forbidden
+  # 2칸 공백의 걸쳐서 들여쓰기는 금지됩니다.
   foo = long_function_name(
       var_one, var_two, var_three,
       var_four)
 
-  # No hanging indent in a dictionary
+  # 딕셔너리에서는 걸쳐서 들여쓰기를 사용하지 않습니다.
   foo = {
       'long_dictionary_key':
       long_dictionary_value,
@@ -1354,8 +1375,8 @@
 
 #### 3.4.1 원소 나열 시 후행 쉼표
 
-- 여러 원소를 나열할 때 후행 쉼표는 `]`, `)`, `}` 와 같이 컨테이너를 닫는 토큰이 마지막 원소와 같은 줄에 있지 않을 때만 권장됩니다.
-- 또한 후행 쉼표의 존재 여부는 파이썬 코드 오토-포메터 [YAPF](https://pypi.org/project/yapf/) 가 컨테이너의 원소를 한 줄에 하나씩 `,` 기호를 붙여 자동 정렬하도록 지시하는 힌트로도 사용됩니다.
+- 후행 쉼표는 시퀀스의 요소에서 닫는 구문 기호 `]`, `)`, 또는 `}`가 마지막 요소와 같은 줄에 나타나지 않는 경우와 단일 요소를 가진 튜플에 대해서만 권장됩니다.
+- 후행 쉼표의 존재는 Python 코드 자동 포맷터인 [Black](https://github.com/psf/black)이나 [Pyink](https://github.com/google/pyink)에게 마지막 요소 뒤에 `,`가 있을 때 항목의 컨테이너를 한 줄에 하나의 항목씩 자동으로 포맷하도록 지시하는 힌트로도 사용됩니다.
 
 - 올바른 예
 
@@ -1376,8 +1397,7 @@
           0,
           1,
           4,
-          6
-          ]
+          6,]
   ```
 
 ---
@@ -1386,7 +1406,7 @@
 ### 3.5 Blank Lines
 
 - 함수 선언이든 객체 선언이든 최상위 선언문과는 2개의 빈 줄을 사이에 두어야 합니다.
-- 각 메소드 선언 또는 `class` 줄과 젓 번째 메소드 선언 시 그 사이에는 한 개의 빈 줄이 있어야 합니다.
+- 각 메소드 선언 또는 `class`의 docstring 줄과 젓 번째 메소드 선언 시 그 사이에는 한 개의 빈 줄이 있어야 합니다.
 - `def` 줄 이후에는 빈 줄이 없어야 합니다.
 - 함수와 메소드 사이에 개발자의 판단하에 적절하게 한 개의 빈 줄을 사용하세요.
 
@@ -1524,7 +1544,7 @@
 ### 3.7 Shebang Line
 
 - 대부분의 `.py` 파일은 `#!` 로 시작하지 않아도 됩니다.
-- [PEP-394](https://www.python.org/dev/peps/pep-0394/)에 따라 프로그램의 메인 파일 첫 줄에 `#!/usr/bin/env python3` (virtualenvs 지원) 또는 `#!/usr/bin/python3`사용하면 됩니다.
+- [PEP-394](https://peps.python.org/pep-0394/)에 따라 프로그램의 메인 파일 첫 줄에 `#!/usr/bin/env python3` (virtualenvs 지원) 또는 `#!/usr/bin/python3`사용하면 됩니다.
 
 - 이 줄은 파이썬 파일을 import 할때는 무시되지만 실행 될때는 커널이 어떤 파이썬 인터프리터를 사용해야 하는지 알려줍니다.
 - 따라서 직접 실행될 파일에 기록하는것이 적합합니다.
@@ -1543,7 +1563,7 @@
 - 파이썬은 코드를 문서화 할 때 _docstring_ 을 사용합니다.
 - docstring 은 패키지, 모듈, 클래스나 함수의 첫번째 선언되는 문자열입니다.
 - 이 문자열은 `pydoc` 이 사용하는 `__doc__` 멤버 오브젝트에서 자동으로 추출될 수 있습니다. (여러분의 모듈에서 `pydoc` 를 실행 후 결과를 확인해보세요)
-- [PEP257](https://www.google.com/url?sa=D&q=http://www.python.org/dev/peps/pep-0257/) 에 따라 docstring 을 시작하거나 끝낼 때는 `"""` 를 사용하세요.
+- [PEP257](https://peps.python.org/pep-0257/) 에 따라 docstring 을 시작하거나 끝낼 때는 `"""` 를 사용하세요.
 - docstring은 마침표, 물음표, 느낌표로 끝나는 요약줄(한 줄)로 시작하여야 하며 한 줄의 공백을 두고 내용을 담고있는 나머지 docstring 이 이어져야 합니다.
 - 또한 내용을 담고있는 docstring 은 `"""` 와 같은 커서위치에서 시작하여야 합니다.
 
@@ -1551,36 +1571,70 @@
 
 #### 3.8.2 Modules
 
-- 모든 파일은 라이센스 보일러 플레이트를 가지고 있어야 합니다.
 - 프로젝트에 알맞는 라이센스 보일러 플레이트를 선택하세요. (예를 들면, Apache 2.0, BSD, LGPL, GPL)
+- 모든 파일은 라이센스 보일러 플레이트를 가지고 있어야 합니다.
+
+  ```python
+  """모듈이나 프로그램에 대한 한 줄 요약으로, 마침표로 끝나야 합니다.
+
+  한 줄을 비워두세요. 이 docstring의 나머지 부분에는 모듈이나 프로그램에
+  대한 전반적인 설명이 포함되어야 합니다. 선택적으로, 내보낸 클래스와
+  함수에 대한 간단한 설명 및/또는 사용 예시도 포함될 수 있습니다.
+
+  전형적인 사용 예시:
+
+    foo = ClassFoo()
+    bar = foo.FunctionBar()
+  """
+  ```
+
+<a id="s3.8.2.1-test-modules"></a>
+<a id="test-docs"></a>
+
+##### 3.8.2.1 Test modules
+
+- 테스트 파일의 모듈 수준 docstring은 필수는 아닙니다.
+- 추가적인 정보를 제공할 필요가 있는 경우에만 포함해야 합니다.
+- 예를 들면, 테스트를 실행하는 방법에 대한 구체적인 내용, 특이한 설정 패턴에 대한 설명, 외부 환경에 대한 의존성 등이 포함될 수 있습니다.
+
+```python
+"""이 Blaze 테스트는 golden 파일을 사용합니다.
+`google3` 디렉토리에서
+`blaze run //foo/bar:foo_test -- --update_golden_files` 명령어를 실행하여
+이러한 파일을 업데이트할 수 있습니다.
+"""
+```
+
+- 새로운 정보를 제공하지 않는 docstring은 사용하지 말아야 합니다.
+
+```python
+"""Tests for foo.bar."""
+```
 
 <a id="s3.8.3-functions-and-methods"></a>
 
 #### 3.8.3 Functions and Methods
 
-- 이 섹션에서 "함수"는 메소드, 함수 또는 제너레이터를 의미합니다.
+- 이 섹션에서 ‘function’은 메소드, 함수, 제너레이터 또는 속성을 의미합니다.
 
-- 아래의 조건을 만족하지 않는 이상 함수는 반드시 docstring 을 가지고 있어야 합니다.
+- 다음 중 하나 이상의 속성을 가진 모든 함수에는 docstring이 필수입니다.
 
-  - 외부에서 보이지 않음
-  - 매우 짧음
-  - 잘 알려져 있음
+  - 공개 API의 일부인 경우
+  - 비교적 큰 경우
+  - 직관적이지 않은 로직을 가진 경우
 
-- docstring 은 직접 함수의 코드를 읽어보지 않더라도 충분히 함수를 호출하는 코드를 작성 할 수 있을만큼 정보를 제공해야 합니다.
-- docstring은 함수의 호출방식이나 시멘틱등을 반드시 기술하되 함수의 사용함에 있어 영항을 주지 않는 한 함수 내부의 상세한 구현방법은 기술하지 아니합니다
-- 예를들어 한 함수가 구동과정에서 인자로 받은 변수 하나를 변형시킨다면 이는 docstring에 기술되어야 합니다.
-- 이외 함수의 호출과 상관이 없는 자잘하지만 중요한 항목들은 함수 내 docstring 보단 주석으로 기록하는 것이 좋습니다
-- docstring 은 (`"""Fetches rows from a Bigtable."""`) 처럼 _설명조_ 를 사용하여야 하며 (`"""Fetch rows from a Bigtable."""`) 처럼 _명령조_ 를 사용하지 않아야 합니다.
-- docstring 은 함수의 구현방식이 아닌 호출 방법과 의미를 기술해야 합니다.
-- 복잡한 코드의 경우 docstring 을 사용하는 것보다 코드 한 줄마다 주석을 첨가하는 것이 더 알맞습니다.
+- docstring은 함수의 코드를 읽지 않고도 함수 호출을 작성할 수 있을 만큼 충분한 정보를 제공해야 합니다.
+- docstring은 함수의 호출 구문과 의미를 설명해야 하며, 일반적으로 구현 세부 사항은 포함하지 않아야 하지만, 이러한 세부 사항이 함수 사용 방법에 중요하다면 예외입니다.
+- 예를 들어, 인자를 사이드 임펙트로 변경하는 함수는 그 점을 docstring에 명시해야 합니다.
 
-- 다른 기본 객체의 메소드를 오버라이드하는 메소드는 `"""See base class."""` 처럼 개발자가 작성한 docstring 에 오버라이드된 메소드가 있음을 알려주는 docstring 을 전달 할 수도 있습니다.
-- 그 이유는 같은 문서를 여러곳에서 반복하는 것을 방지하기 위함입니다.
-- 하지만 오버라이딩된 메소드가 기존의 메소드와 확연하게 다른 동작방식을 가지고 있거나 세부적인 내용(e.g., 잠재적인 부작용 등)이 존재한다면 적어도 그러한 차이점들은 docstring 을 통해 기록되어야 합니다.
+- 그렇지 않으면, 호출자에게 중요하지 않은 함수 구현의 미묘하지만 중요한 세부 사항은 함수의 docstring보다는 코드 옆에 주석으로 표현하는 것이 좋습니다.
+- docstring은 서술형(`"""Fetches rows from a Bigtable."""`) 또는 명령형(`"""Fetch rows from a Bigtable."""`) 스타일일 수 있지만, 파일 내에서 스타일은 일관되게 유지해야 합니다.
+- `@property` 속성의 docstring은 속성이나 [함수 인자](#doc-function-args)의 docstring과 같은 스타일을 사용해야 합니다 (`"""The Bigtable path."""` 대신에 `"""Returns the Bigtable path."""`).
 
-- 다만 함수의 몇가지 특정 부분들은 아래처럼 별도의 특별섹션으로 기록해야 합니다.
-- 각 섹션은 표제로 시작하며 콜론으로 끝맺습니다.
-- 각 섹션은 표제를 제외하고 2칸 들여쓰기를 합니다.
+- 함수의 특정 측면은 아래에 나열된 특별한 섹션에서 문서화해야 합니다.
+- 각 섹션은 콜론으로 끝나는 제목 행으로 시작합니다.
+- 제목을 제외한 모든 섹션은 2칸 또는 4칸 공백의 걸쳐서 들여쓰기를 유지해야 합니다 (파일 내에서 일관되게 유지).
+- 함수의 이름과 시그니처가 충분히 정보를 제공하여 한 줄의 docstring으로 적절히 설명할 수 있는 경우, 이러한 섹션은 생략할 수 있습니다.
 
 <a id="doc-function-args"></a>
 
@@ -1595,12 +1649,13 @@
 
 ##### [_Returns:_ (제너레이터에는 _Yields:_)](#doc-function-returns)
 
-- 반환값의 자료형과 의미를 기록합니다. 만약 함수가 None만을 반환한다면 이 섹션은 필요없습니다.
-- 또한 만약 docstring이 Returns 나 Yields로 시작하거나(e.g. `"""Returns row from Bigtable as a tuple of strings."""`) 충분한 설명이 제공된다면 생략 될 수 있습니다.
-- Tuple 반환 값을 개별 이름이 있는 여러 반환 값인 것처럼 자주 문서화하는 'NumPy style' ([example](http://numpy.org/doc/stable/reference/generated/numpy.linalg.qr.html))을 모방하지 마세요. (Tuple를 언급하지 않습니다.)
-- 대신, 다음과 같은 반환값으로 기술하세요.
-  - "Returns a tuple (mat_a, mat_b), where mat_a is ..., and ...".
-- Docstring의 보조 이름은 함수 본문에 사용된 내부 이름과 반드시 일치할 필요는 없습니다. (해당 이름은 API의 일부가 아니기 때문입니다.)
+- 반환 값의 의미를 설명하고, 타입 어노테이션에서 제공하지 않는 타입 정보도 포함해야 합니다.
+- 함수가 None만 반환하는 경우, 이 섹션은 필요하지 않습니다.
+- docstring이 "Return", "Returns", "Yield", "Yields"로 시작하고(e.g. `"""Returns row from Bigtable as a tuple of strings."""`), 첫 번째 문장이 반환 값을 설명하기에 충분할 경우, 이 섹션은 생략될 수 있습니다.
+- 이전의 'NumPy 스타일'을 모방하지 마세요. ([example](https://numpy.org/doc/1.24/reference/generated/numpy.linalg.qr.html)) 이 스타일은 종종 튜플 반환 값을 여러 개의 개별 반환 값처럼 각각의 이름으로 문서화했습니다. (튜플이라는 점을 언급하지 않고)
+- 대신, 반환 값을 다음과 같이 설명하세요: "Returns: A tuple (mat_a, mat_b), where mat_a is ..., and ...".
+- docstring에서 사용되는 설명용 이름은 함수 본문에서 사용되는 내부 이름과 반드시 일치할 필요는 없습니다 (내부 이름은 API의 일부가 아니기 때문입니다)
+- 함수가 `yield`를 사용하는 경우(즉, 제너레이터인 경우), `Yields:` 섹션에서는 호출 결과로 반환되는 제너레이터 객체가 아니라, `next()`에 의해 반환되는 객체를 문서화해야 합니다.
 
 <a id="doc-function-raises"></a>
 
@@ -1611,10 +1666,11 @@
 - 명시된 API가 docstring을 위반했을 될 경우, 예외를 문서화하지 않습니다. (왜냐하면 이것은 역설적으로 API의 API를 위반하는 행동을 만들 수 있기 때문이다.)
 
   ```python
-  def fetch_smalltable_rows(table_handle: smalltable.Table,
-                          keys: Sequence[Union[bytes, str]],
-                          require_all_keys: bool = False,
-  ) -> Mapping[bytes, Tuple[str, ...]]:
+  def fetch_smalltable_rows(
+      table_handle: smalltable.Table,
+      keys: Sequence[bytes | str],
+      require_all_keys: bool = False,
+  ) -> Mapping[bytes, tuple[str, ...]]:
     """Fetches rows from a Smalltable.
 
     Retrieves rows pertaining to the given keys from the Table instance
@@ -1648,10 +1704,11 @@
 - 마찬가지로, 줄 바꿈이 있는 `Args:`도 허용합니다.
 
   ```python
-  def fetch_smalltable_rows(table_handle: smalltable.Table,
-                            keys: Sequence[Union[bytes, str]],
-                            require_all_keys: bool = False,
-  ) -> Mapping[bytes, Tuple[str, ...]]:
+  def fetch_smalltable_rows(
+      table_handle: smalltable.Table,
+      keys: Sequence[bytes | str],
+      require_all_keys: bool = False,
+  ) -> Mapping[bytes, tuple[str, ...]]:
       """Fetches rows from a Smalltable.
 
       Retrieves rows pertaining to the given keys from the Table instance
@@ -1684,19 +1741,51 @@
       """
   ```
 
+<a id="s3.8.3.1-overridden-methods"></a>
+<a id="overridden-method-docs"></a>
+
+##### 3.8.3.1 Overridden Methods
+
+- 기본 클래스의 메서드를 오버라이드하는 메서드는 [`@override`](https://typing-extensions.readthedocs.io/en/latest/#override) 데코레이터(`typing_extensions` 또는 `typing` 모듈에서 제공)를 명시적으로 사용하는 경우 docstring이 필요하지 않습니다.
+- 단, 오버라이딩된 메서드의 동작이 기본 메서드의 계약을 실질적으로 개선하거나, 추가적인 사이드 임펙트 등을 문서화해야 하는 경우에는, 그러한 차이점이 최소한 포함된 docstring이 오버라이딩 메서드에 필요합니다.
+
+  ```python
+  from typing_extensions import override
+  class Parent:
+    def do_something(self):
+      """Parent method, includes docstring."""
+  # 자식 클래스, 오버라이드로 주석이 달린 메서드.
+  class Child(Parent):
+    @override
+    def do_something(self):
+      pass
+  ```
+
+  ```python
+  # 자식 클래스에서 @override 데코레이터가 없는 경우, docstring이 필요합니다.
+  class Child(Parent):
+    def do_something(self):
+      pass
+  # docstring이 단순한 경우, @override만으로도 문서가 기본 클래스에 있음을 표시할 수 있습니다.
+  class Child(Parent):
+    @override
+    def do_something(self):
+      """See base class."""
+  ```
+
 <a id="s3.8.4-comments-in-classes"></a>
 
 #### 3.8.4 Classes
 
 - 클래스는 선언 바로 아래에 해당 클래스를 설명하는 docstring 를 가지고 있어야 합니다.
-- 만약 클래스가 public attributes 를 가지고 있다면 [function's `Args`](#doc-function-args) 섹션과 같은 형식을 사용해 `Attributes` 섹션을 작성해야 합니다.
+- [properties](#properties)을 제외한 공개 속성은 `Attributes` 섹션에서 문서화해야 하며, [함수의 `Args`](#doc-function-args) 섹션과 동일한 형식을 따라야 합니다.
 
 ```python
 class SampleClass:
     """Summary of class here.
 
-    Longer class information....
-    Longer class information....
+    Longer class information...
+    Longer class information...
 
     Attributes:
         likes_spam: A boolean indicating if we like SPAM or not.
@@ -1704,14 +1793,42 @@ class SampleClass:
     """
 
     def __init__(self, likes_spam: bool = False):
-        """Inits SampleClass with blah."""
+        """Initializes the instance based on spam preference.
+        Args:
+          likes_spam: Defines if instance exhibits this preference.
+        """
         self.likes_spam = likes_spam
         self.eggs = 0
 
-    def public_method(self):
-        """Performs operation blah."""
+    @property
+    def butter_sticks(self) -> int:
+        """The number of butter sticks we have."""
 ```
 
+- 모든 클래스의 docstring은 클래스 인스턴스가 무엇을 나타내는지를 설명하는 한 줄 요약으로 시작해야 합니다. 이는 `Exception`의 서브클래스도 예외가 무엇을 나타내는지를 설명해야 하며, 발생할 수 있는 컨텍스트에 대해서는 설명하지 않아야 함을 의미합니다. 클래스의 docstring은 클래스가 클래스라는 등의 불필요한 정보를 반복해서는 안 됩니다.
+
+- 올바른 예
+
+  ```python
+  class CheeseShopAddress:
+    """The address of a cheese shop.
+    ...
+    """
+  class OutOfCheeseError(Exception):
+    """No more cheese is available."""
+  ```
+
+- 부적절한 예
+
+  ```python
+  class CheeseShopAddress:
+    """Class that describes the address of a cheese shop.
+    ...
+    """
+  class OutOfCheeseError(Exception):
+    """Raised when no more cheese is available."""
+  ```
+
 <a id="s3.8.5-block-and-inline-comments"></a>
 <a id="s3.8.5-comments-in-block-and-inline"></a>
 
@@ -1762,25 +1879,24 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 ### 3.10 Strings
 
 - 매개변수가 모두 문자열인 경우에도 [f-string](https://docs.python.org/3/reference/lexical_analysis.html#f-strings), `format` 메소드나 `%` 연산자를 사용하여 포메팅하세요.
-- 물론 `+` 나 `%` (또는 `format`) 를 언제 사용할지는 개발자의 판단에 따릅니다.
-- 문자열을 합치기 위해 `%` 또는 `format`을 사용하지 마세요.
+- 문자열 포맷팅 옵션 사이에서 최상의 판단을 사용하세요.
+- `+`를 사용한 단일 join은 괜찮지만, `+`를 사용한 포맷팅은 피하세요.
 
   - 올바른 예
 
     ```python
-    x = a + b
+    x = f'name: {name}; score: {n}'
     x = '%s, %s!' % (imperative, expletive)
     x = '{}, {}'.format(first, second)
     x = 'name: %s; score: %d' % (name, n)
+    x = 'name: %(name)s; score: %(score)d' % {'name':name, 'score':n}
     x = 'name: {}; score: {}'.format(name, n)
-    x = f'name: {name}; score: {n}'
+    x = a + b
     ```
 
   - 부적절한 예
 
     ```python
-    x = '%s%s' % (a, b)  # use + in this case
-    x = '{}{}'.format(a, b)  # use + in this case
     x = first + ', ' + second
     x = 'name: ' + name + '; score: ' + str(n)
     ```
@@ -1868,6 +1984,9 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
         will collapse common leading spaces in each line.""")
     ```
 
+- 여기서 백슬래시를 사용하는 것은 [명시적인 줄 이어쓰기](#line-length)에 대한 금지를 위반하지 않습니다.
+- 이 경우, 백슬래시는 문자열 리터럴에서 [줄바꿈을 이스케이프](https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals)하는 것입니다.
+
 <a id="s3.10.1-logging"></a>
 
 #### 3.10.1 Logging
@@ -1918,7 +2037,7 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 ```python
   올바른 예:
   if not 0 <= p <= 1:
-    raise ValueError(f'Not a probability: {p!r}')
+    raise ValueError(f'Not a probability: {p=}')
   try:
     os.rmdir(workdir)
   except OSError as error:
@@ -1929,7 +2048,7 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 ```python
   잘못된 예:
   if p < 0 or p > 1:  # PROBLEM: also false for float('nan')!
-    raise ValueError(f'Not a probability: {p!r}')
+    raise ValueError(f'Not a probability: {p=}')
   try:
     os.rmdir(workdir)
   except OSError:
@@ -2004,33 +2123,44 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 
 - 임시적, 잠시 사용하려는 코드 또는 좋기는 하지만 완벽하지 않은 코드의 경우 `TODO` 주석을 사용하세요.
 
-- `TODO` 주석은 대문자로 되어있는 `TODO` 문구로 시작하며 해당 코드에 대한 가장 높은 이해도를 가진 인물의 이름, 이메일 주소 또는 다른 신원구분 문구를 괄호안에 넣어 포함하여야 합니다.
-- 이것 뒤에 무엇을 해야하는 지에 대한 내용을 추가합니다.
+- `TODO` 주석은 모두 대문자로 된 `TODO`로 시작하고, 다음에 콜론을 붙이며, 맥락이 포함된 리소스에 대한 링크(이상적으로는 버그 참조)를 포함해야 합니다.
+- 버그 참조가 선호됩니다. 왜냐하면 버그는 추적되며 후속 댓글이 달리기 때문입니다.
+- 이 문맥 다음에 하이픈 `-`으로 시작하는 설명 문자열을 추가하세요..
+- 목적은 일관된 `TODO` 형식을 유지하여, 더 많은 세부 정보를 찾기 위해 검색할 수 있도록 하는 것입니다.
 
-- 목적은 `TODO`가 일관된 형식을 이용하여 추후 필요한 세부정보를 검색할 수 있어야 한다는 것입니다.
-- `TODO` 는 본인이 아닌 다른 개발자가 문제를 해결하겠다는 약속이 아닙니다.
-- 따라서 `TODO` 를 만드셨다면 거의 항상 작성한 본인의 이름이 들어가야 합니다.
+  ```python
+  # TODO: crbug.com/192795 - Investigate cpufreq optimizations.
+  ```
 
-```python
-# TODO(kl@gmail.com): Use a "*" here for string repetition.
-# TODO(Zeke) Change this to use relations.
-```
+- 이전 스타일로, 예전에는 권장되었지만 새로운 코드에서는 사용이 권장되지 않습니다.
+
+  ```python
+  # TODO(crbug.com/192795): Investigate cpufreq optimizations.
+  # TODO(yourusername): Use a "\*" here for concatenation operator.
+  ```
+
+- 문맥으로 개인이나 팀을 참조하는 TODO를 추가하는 것을 피하세요.
+
+  ```python
+  # TODO: @yourusername - File an issue and use a '*' for repetition.
+  ```
 
-- 만약 작성한 `TODO` 가 "추후 무엇을 진행할 것" 이라는 형식을 담고 있다면 반드시 ("2009년 11월까지") 와 같은 구체적인 기간이나 ("모든 클라이언트가 XML 요청을 해결 할수 있을때 이 코드 삭제") 처럼 목적을 포함하여야 합니다.
+- `TODO`가 "미래의 어느 시점에 무엇을 해야 한다"는 형식이라면, 미래의 코드 유지 관리자가 이해할 수 있도록 매우 구체적인 날짜("2009년 11월까지")나 사건("모든 클라이언트가 XML 요청을 해결 할수 있을때 이 코드 삭제")을 포함해야 합니다.
+- 이슈는 이를 추적하는 데 이상적입니다.
 
 ---
 <a id="s3.13-imports-formatting"></a>
 
 ### 3.13 import 형식
 
-- imports는 개별적인 라인에 두어야 합니다; [`typing` imports에 대한 예외가 있습니다.](#s3.19.12-imports).
+- imports는 개별적인 라인에 두어야 합니다; [`typing` 그리고 `collections.abc` imports에 대한 예외가 있습니다.](#s3.19.12-imports).
 
   - 올바른 예
 
     ```python
     import os
     import sys
-    from typing import Mapping, Sequence
+    from typing import Any, NewType
     ```
 
   - 부적절한 예
@@ -2042,7 +2172,15 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 - import는 모듈의 주석 과 docstring 바로 다음, 모듈 전역 및 상수 바로 앞 파일의 맨 위에 배치됩니다.
 - import는 가장 일반적인 것 부터 최소한의 일반적인 것들까지 묶여야 합니다.
 
-1. 파이썬의 표준 라이브러리
+1. Python의 **future** import 문
+
+   ```python
+   from __future__ import annotations
+   ```
+
+   자세한 내용은 [위](#from-future-imports)를 참조하세요.
+
+2. 파이썬의 표준 라이브러리
 
    - import 예시는 다음과 같습니다.
 
@@ -2050,7 +2188,7 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
    import sys
    ```
 
-2. [third-party](https://pypi.org/)
+3. [third-party](https://pypi.org/)
 
    - 모듈이나 패키지의 import 예시는 다음과 같습니다.
 
@@ -2058,7 +2196,7 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
    import tensorflow as tf
    ```
 
-3. Code repository
+4. Code repository
 
    - 서브 패키지의 import 예시는 다음과 같습니다.
 
@@ -2066,7 +2204,7 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
    from otherproject.ai import mind
    ```
 
-4. 동일한 top 레벨에 속하는 어플리케이션의 특정을 import하는 것은 **더 이상 사용되지 않습니다**
+5. 동일한 top 레벨에 속하는 어플리케이션의 특정을 import하는 것은 **더 이상 사용되지 않습니다**
 
    - 서브 패키지의 파일 import 예시는 다음과 같습니다.
 
@@ -2164,7 +2302,9 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 `global_var_name`,
 `instance_var_name`,
 `function_parameter_name`,
-`local_var_name`.
+`local_var_name`,
+`query_proper_noun_for_thing`,
+`send_acronym_via_https`.
 
 - 함수 이름, 변수 이름, 그리고 파일 이름은 설명적이여야 하고 약어로 적는 일을 피해야 합니다.
 - 특히 모호하거나 프로젝트에 참여하지 않은 사람들이 읽었을 때 익숙하지 않은 약어를 사용하지마세요. 그리고 절대 단어에서 글자를 지워 줄이지 마세요.
@@ -2175,15 +2315,20 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 
 #### 3.16.1 피해야 할 이름
 
-1. 아래와 같은 특별한 경우를 제외한 단일 글자는 피합니다.
+- 아래와 같은 특별한 경우를 제외한 단일 글자는 피합니다.
+
+  - counters이나 iterators에서 사용할 때 (예. `i`, `j`, `k`, `v` 등)
+  - `try/except`문에서 예외 식별자로 `e`를 사용할 때
+  - with문의 파일 핸들에서 `f`를 사용할 때
+  - 제약 조건이 없는 비공식적인 [type variables](#typing-type-var)를 사용할 때 (e.g., `_T = TypeVar("_T"), _P = ParamSpec("_P")`)
 
-- counters이나 iterators에서 사용할 때 (예. `i`, `j`, `k`, `v` 등)
-- `try/except`문에서 예외 식별자로 `e`를 사용할 때
-- with문의 파일 핸들에서 `f`를 사용할 때
   단일 글자를 남용하지 않도록 주의해야합니다. 일반적으로 말해서 서술성은 이름의 가시성 범위에 비례해야합니다. 예를 들어 `i`는 5행 코드 블록에 적합한 이름일 수 있지만 중첩된 여러 범위 내에서는 너무 모호할 수 있습니다.
+
 - package/module 이름에서 dashes(`-`)를 사용할 때
 - `__이중_선행_및_후행_밑줄__` 이름을 사용할 때 (Python에서 예약어)
+
   - 원본에 없는 추가 설명 : double leading and trailing underscore : (앞 뒤로 \_가 2개씩 있는것 e.g **name**, **init**)
+
 - 공격적인 단어
 - 불필요하게 변수 타입을 포함하는 이름 (예 : `id_to_name_dict`)
 
@@ -2195,16 +2340,20 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 
 - "Internal"는 모듈의 내부 또는 클래스 내에서 protected 또는 private를 의미합니다.
 - 단일 밑줄(`_`)을 추가하면 모듈 변수와 함수를 보호하기 위한 몇 가지 지원이 있습니다. (linters는 보호된 멤버 접근에 플래그를 지정합니다.)
+- 단일 언더스코어(`_`)를 접두사로 사용하는 것은 모듈 변수와 함수 보호를 위한 일부 지원을 제공합니다 (linters가 보호된 멤버 접근을 경고할 수 있습니다). 그러나 유닛 테스트가 테스트 중인 모듈의 보호된 상수에 접근하는 것은 괜찮습니다.
 - 인스턴스 변수나 메소드에 이중 밑줄(`__` : dunder)을 추가하면 변수나 메소드가 해당 클래스에 대해 효과적으로 private 됩니다.
   - 가독성과 테스트 가능성에 영향을 미치고 _실제로_ 비공개가 아니므로 사용을 권장하지 않습니다.
   - 하나의 밑줄을 선호합니다.
 - 모듈에 관련 클래스와 top-level 함수를 함께 배치합니다.
 - 자바와는 다르게 하나의 모듈에 대해 하나의 클래스로 제한을 할 필요가 없습니다.
 - CapWords(단어의 첫 글자를 대문자로 하는 방식)을 사용하지만 모듈의 이름이 \_with_under.py 같은 경우에는 소문자로 합니다.
+
   - 비록 몇몇 오래된 모듈의 이름이 CapWords.py일지라도 이제는 모듈의 이름을 class이름에 따라 짓게 되면 혼란스러우므로 권장하지 않습니다. (e.g "잠깐만, -- 내가 `import StringIO`를 한거야 아니면 `from StringIO import StringIO`를 한거야 ?" 같은 상황이 발생할 수 있습니다.)
-- 구성 요소가 CapWord를 사용하더라도 "test"로 시작하는 _unittest_ 메서드 이름에 Undercore가 나타날 수 있습니다.
-  - 한 가지 가능한 패턴은 `test<MethodUnderTest>_<state>`로, 예를 들어 `testPop_EmptyStack`같은 패턴은 괜찮습니다.
-  - test 메서드에 에 이름을 붙이는 올바른 방법은 없습니다.
+
+- 새로운 유닛 테스트 파일은 PEP 8을 준수하는 소문자와 언더스코어 방식의 메서드 이름을 따릅니다.
+  - 예를 들어, `test*<method*under_test>*<state>`와 같은 형식을 사용합니다.
+  - 일관성을 위해(\*) 이전 모듈에서 CapWords 함수 이름을 따르는 경우, `test`로 시작하는 메서드 이름에 논리적 구성 요소를 구분하기 위해 언더스코어가 포함될 수 있습니다.
+  - 하나의 가능한 패턴은 `test<MethodUnderTest>_<state>`입니다.
 
 <a id="s3.16.3-file-naming"></a>
 
@@ -2304,9 +2453,24 @@ if __name__ == '__main__':
 
 #### 3.19.1 일반적인 규칙
 
-- [PEP-484](https://www.python.org/dev/peps/pep-0484/)을 읽으세요.
-- 메서드에서는 `self`, `cls`는 Type의 정보가 필요한 경우에서만 주석을 달아야합니다. 예) `@classmethod def create(cls: Type[T]) -> T: return cls()`
+- [PEP-484](https://peps.python.org/pep-0484/)을 읽으세요.
+
+- `self` 또는 `cls`에 주석을 달 필요는 일반적으로 없습니다. 올바른 타입 정보를 위해 필요한 경우에만 [`Self`](https://docs.python.org/3/library/typing.html#typing.Self)를 사용할 수 있습니다.
+
+  ```python
+  from typing import Self
+  class BaseClass:
+    @classmethod
+    def create(cls) -> Self:
+      ...
+    def difference(self, other: Self) -> float:
+      ...
+  ```
+
+- 마찬가지로, `__init__`의 반환 값에 주석을 달 필요는 없습니다 (여기서 `None`만 유효한 옵션입니다).
+
 - 모든 변수나 반환되는 Type이 정해지지 않았다면 `Any`를 사용하세요.
+
 - 모듈에서 모든 함수에 주석을 달 필요는 없습니다.
   - Public API에는 최소한의 주석을 답니다.
   - 판단력을 사용하여 한편으로는 안전성과 명확성, 그리고 다른 한편으로는 유연성 사이의 균형을 잘 잡아야 합니다.
@@ -2321,12 +2485,15 @@ if __name__ == '__main__':
 - 기존의 [들여쓰기](#s3.4-indentation) 규칙을 따르세요.
 
 - 주석처리하고나서 많은 함수는 "한 줄에 하나의 파라미터"가 될 것입니다.
+- 반환 타입이 별도의 줄에 표시되도록 보장하기 위해, 마지막 매개변수 뒤에 쉼표를 추가할 수 있습니다.
 
   ```python
-  def my_method(self,
-              first_var: int,
-              second_var: Foo,
-              third_var: Optional[Bar]) -> int:
+  def my_method(
+      self,
+      first_var: int,
+      second_var: Foo,
+      third_var: Bar | None,
+  ) -> int:
   ...
   ```
 
@@ -2338,23 +2505,25 @@ if __name__ == '__main__':
   ```
 
 - 함수 이름, 마지막 매개 변수 및 리턴 Type의 조합이 너무 길면 새 행에서 4만큼 들여 쓰기됩니다.
+- 줄 바꿈을 사용할 때는 각 매개변수와 반환 타입을 별도의 줄에 배치하고, 닫는 괄호를 `def`와 정렬하는 것이 좋습니다.
 
   ```python
   def my_method(
-      self, first_var: int) -> Tuple[MyLongType1, MyLongType1]:
+      self,
+      other_arg: MyLongType | None,
+  ) -> tuple[MyLongType1, MyLongType1]:
   ...
   ```
 
-리턴 유형이 마지막 파라미터와 같은 라인에 맞지 않을 경우, 선호되는 방법은 파라미터를 4만큼 새 라인에 들여쓰고 닫히는 괄호를 "def"와 정렬하는 것이다.
+- 선택적으로, 반환 타입을 마지막 매개변수와 같은 줄에 배치할 수도 있습니다.
 
-- 반환 Type이 마지막 파라미터와 같은 줄이 아닐 때, 선호하는 방법은 파라미터를 4만큼 새 라인에 들여쓰고 닫히는 괄호를 `def`와 정렬합니다.
-
-  - 올바른 예
+  - 괜찮은 예
 
     ```python
     def my_method(
-        self, **kw_args: Optional[MyLongType]
-    ) -> Dict[OtherLongType, MyLongType]:
+      self,
+      first_var: int,
+      second_var: int) -> dict[OtherLongType, MyLongType]:
     ...
     ```
 
@@ -2364,8 +2533,8 @@ if __name__ == '__main__':
 
     ```python
     def my_method(self,
-                **kw_args: Optional[MyLongType]
-                ) -> Dict[OtherLongType, MyLongType]:
+              other_arg: MyLongType | None,
+             ) -> dict[OtherLongType, MyLongType]:
     ...
     ```
 
@@ -2375,10 +2544,11 @@ if __name__ == '__main__':
   ```python
   def my_method(
       self,
-      first_var: Tuple[List[MyLongType1],
-                      List[MyLongType2]],
-      second_var: List[Dict[
-          MyLongType3, MyLongType4]]) -> None:
+      first_var: tuple[list[MyLongType1],
+                      list[MyLongType2]],
+      second_var: list[dict[
+          MyLongType3, MyLongType4]],
+  ) -> None:
   ...
   ```
 
@@ -2409,23 +2579,34 @@ if __name__ == '__main__':
 
 #### 3.19.3 전방선언
 
-- 아직 정의되지 않은 동일한 모듈의 클래스 이름을 사용해야 하는 경우(예, 클래스 선언 내에 클래스가 필요한 경우 또는 아래에 정의된 클래스를 사용하는 경우) `from __future__ import annotations`를 사용하세요.
-- 간단한 경우에는 주석을 사용하거나 클래스 이름에 문자열을 사용하세요.
+- 아직 정의되지 않은 클래스 이름(예를 들어, 클래스 선언 내부에서 클래스 이름이 필요하거나 코드에서 나중에 정의된 클래스를 사용할 경우)을 사용해야 할 경우, `from __future__ import annotations`를 사용하거나 클래스 이름을 문자열로 사용하세요.
 
-```python
-from __future__ import annotations
+  - 올바른 예
 
-class MyClass:
+    ```python
+    from __future__ import annotations
 
-  def __init__(self, stack: Sequence[MyClass]) -> None:
-```
+    class MyClass:
+      def __init__(self, stack: Sequence[MyClass], item: OtherClass) -> None:
+
+    class OtherClass:
+      ...
+    ```
+
+    ```python
+    class MyClass:
+      def __init__(self, stack: Sequence['MyClass'], item: 'OtherClass') -> None:
+
+    class OtherClass:
+      ...
+    ```
 
 <a id="s3.19.4-default-values"></a>
 
 #### 3.19.4 기본 값
 
 - PEP-008에 따라 유형 주석과 기본값이 모두 있는 인수의 경우 "=" \_ only" 주위에 공백을 사용하십시오.
-- [PEP-008](https://www.python.org/dev/peps/pep-0008/#other-recommendations)에 따라 Type 주석과 기본 값이 모두 있는 인수의 경우 `=` _only_ 주위에 공백을 사용하세요,
+- [PEP-008](https://peps.python.org/pep-0008/#other-recommendations)에 따라 Type 주석과 기본 값이 모두 있는 인수의 경우 `=` _only_ 주위에 공백을 사용하세요,
 
 - 올바른 예
 
@@ -2445,19 +2626,20 @@ class MyClass:
 
 #### 3.19.5 NoneType
 
-- 파이썬형에서 노네타입(NoneType)은 퍼스트클래스형이며, 타이핑을 위해 노네타입(NoneType)은 노네타입(NoneType)의 별칭이다. 논쟁이 '없음'이 될 수 있다면 선언해야 한다! 유니온(Union)은 사용할 수 있지만, 다른 유형이 하나만 있는 경우에는 선택사항(Option)을 사용하십시오.
-
-- 파이썬 타입 시스템에서 `NoneType`은 "first class" Type 이며 작성을 위해 `None`은 `NoneType`의 alias(별칭)입니다. 인자는 `None`이 될 수 있다면 선언을 해야합니다! `Union`을 사용할 수 있지만 다른 Type이 하나만 있는 경우 `Optional`를 사용하세요.
+- 파이썬형에서 노네타입(NoneType)은 퍼스트클래스형이며, 타이핑을 위해 노네타입(NoneType)은 노네타입(NoneType)의 별칭이다.
+- 인자가 `None`이 될 수 있는 경우, 이를 선언해야 합니다!
+- 새로운 Python 3.10+ 코드에서는 `|` 유니온 타입 표현식을 사용하는 것이 권장되며, 이전에는 `Optional`과 `Union` 구문을 사용할 수 있습니다.
 
-- 암시적 `Optional` 대신 명시적 `Optional` 사용해야 합니다. PEP 484 이전 버전에서는 `a: Optional[str] = None` 대신에 `a: str = None` 를 선호했지만 지금은 그렇지 않습니다.
+- 암시적인 대신 명시적인 `X | None`을 사용하세요.
+- 이전 버전의 PEP 484에서는 `a: str = None`을 `a: str | None = None`으로 해석할 수 있었지만, 이제는 이것이 선호되는 동작이 아닙니다.
 
 - 올바른 예
 
   ```python
-  def func(a: Optional[str], b: Optional[str] = None) -> str:
-  ...
-  def multiple_nullable_union(a: Union[None, str, int]) -> str:
-  ...
+  def modern_or_union(a: str | int | None, b: str | None = None) -> str:
+    ...
+  def union_optional(a: Union[str, int, None], b: Optional[str] = None) -> str:
+    ...
   ```
 
 - 부적절한 예
@@ -2478,14 +2660,13 @@ class MyClass:
 
 - 어려운 Type을 별칭으로 선언할 수 있습니다. 별칭은 CapWorded여야 합니다. 별칭이 이 모듈에서만 사용하는 경우에는 \_Private여야 합니다.
 
-- 예를 들어 Type과 함께 모듈의 이름이 너무 긴 경우
+- TypeAlias 주석은 버전 3.10 이상에서만 지원된다는 점에 유의하세요.
 
-  ```python
-  _ShortName = module_with_long_name.TypeWithLongName
-  ComplexMap = Mapping[str, List[Tuple[int, int]]]
-  ```
-
-- 다른 예로는 복잡한 중첩 유형과 함수의 복수 반환 변수(튜플)가 있습니다.
+```python
+from typing import TypeAlias
+_LossAndGradient: TypeAlias = tuple[tf.Tensor, tf.Tensor]
+ComplexTFMap: TypeAlias = Mapping[str, _LossAndGradient]
+```
 
 <a id="s3.19.7-ignoring-types"></a>
 <a id="s3.19.7-ignore"></a>
@@ -2505,11 +2686,21 @@ class MyClass:
 
 #### 3.19.8 내부 변수 작성
 
-- 내부 변수가 유추하기 어렵거나 불가능한 타입을 가지고 있는 경우, 다음과 같이 별도의 주석으로 설명할 수 있습니다.
+<a id="annotated-assignments"></a>
 
-```python
-a = SomeUndecoratedFunction()  # type: Foo
-```
+- [_Annotated Assignments_](#annotated-assignments): 내부 변수의 타입을 추론하기 어렵거나 불가능한 경우, 주석이 달린 할당으로 타입을 명시하세요. 변수 이름과 값 사이에 콜론과 타입을 사용합니다 (기본값이 있는 함수 인수와 동일한 방식으로).
+
+  ```python
+  a: Foo = SomeUndecoratedFunction()
+  ```
+
+<a id="type-comments"></a>
+
+- [_Type Comments_](#type-comments): 코드베이스에 여전히 남아 있을 수 있지만 (Python 3.6 이전에는 필요했음), 더 이상 `# type: <type name>` 주석을 줄 끝에 추가하지 마세요.
+
+  ```python
+  a = SomeUndecoratedFunction()  # type: Foo
+  ```
 
 <a id="s3.19.9-tuples-vs-lists"></a>
 <a id="s3.19.9-tuples"></a>
@@ -2521,30 +2712,38 @@ a = SomeUndecoratedFunction()  # type: Foo
 - 리스트는 함수의 반환 타입으로 일반적으로 사용된다.
 
 ```python
-a = [1, 2, 3]  # type: List[int]
-b = (1, 2, 3)  # type: Tuple[int, ...]
-c = (1, "2", 3.5)  # type: Tuple[int, str, float]
+a: list[int] = [1, 2, 3]
+b: tuple[int, ...] = (1, 2, 3)
+c: tuple[int, str, float] = (1, "2", 3.5)
 ```
 
 <a id="s3.19.10-typevars"></a>
 <a id="s3.19.10-type-var"></a>
+<a id="typevars"></a>
 
-#### 3.19.10 TypeVar
+#### 3.19.10 Type variables
 
 - 파이썬형 시스템은 일반성을 가지고 있다. 공장 기능인 TypeVar는 흔히 사용하는 방법입니다.
 
-- 파이선 Type에는 [generics](https://www.python.org/dev/peps/pep-0484/#generics)를 가지고 있습니다.
-- factory function `TypeVar`는 흔히 사용하는 방법입니다.
+- 파이선 Type에는 [generics](https://peps.python.org/pep-0484/#generics)를 가지고 있습니다.
+- `TypeVar`와 `ParamSpec`과 같은 타입 변수는 제너릭을 사용하는 일반적인 방법입니다.
 
   ```python
-  from typing import List, TypeVar
-  T = TypeVar("T")
+  from collections.abc import Callable
+  from typing import ParamSpec, TypeVar
+  _P = ParamSpec("_P")
+  _T = TypeVar("_T")
   ...
-  def next(l: List[T]) -> T:
-  return l.pop()
+  def next(l: list[_T]) -> _T:
+    return l.pop()
+  def print_when_called(f: Callable[_P, _T]) -> Callable[_P, _T]:
+    def inner(*args: _P.args, **kwargs: _P.kwargs) -> _T:
+      print("Function was called")
+      return f(*args, **kwargs)
+    return inner
   ```
 
-- TypeVar는 부자연스러울 수도 있습니다.
+- `TypeVar`는 부자연스러울 수도 있습니다.
 
   ```python
   AddableType = TypeVar("AddableType", int, float, str)
@@ -2552,7 +2751,7 @@ c = (1, "2", 3.5)  # type: Tuple[int, str, float]
   return a + b
   ```
 
-- `typing` 모듈의 흔히 미리 정의된 Type 변수는 `AnyStr`입니다. `bytes`, `unicode`일 수 있고 모두 같은 Type이어야 하는 여러 주석에 사용합니다.
+- `typing` 모듈의 흔히 미리 정의된 Type 변수는 `AnyStr`입니다. `bytes`, `str`일 수 있고 모두 같은 Type이어야 하는 여러 주석에 사용합니다.
 
   ```python
   from typing import AnyStr
@@ -2562,48 +2761,46 @@ c = (1, "2", 3.5)  # type: Tuple[int, str, float]
   raise ValueError()
   ```
 
-<a id="s3.19.11-string-types"></a>
-<a id="s3.19.11-strings"></a>
+- 타입 변수는 설명적인 이름을 가져야 합니다. 단, 다음 모든 기준을 충족하는 경우에는 예외입니다.
 
-#### 3.19.11 문자열 Type
+  - 외부에서 보이지 않는 경우
+  - 제약 조건이 없는 경우
 
-- String 주석에 대한 적절한 Type은 코드의 용도에 따라 달라집니다.
+  - 올바른 예
+
+    ```python
+      _T = TypeVar("_T")
+      _P = ParamSpec("_P")
+      AddableType = TypeVar("AddableType", int, float, str)
+      AnyFunction = TypeVar("AnyFunction", bound=Callable)
+    ```
 
-- `str`을 사용하는 것을 선호하지만 `Text`도 허용됩니다. 둘 중 하나를 일관성 있게 사용하세요.
-- 바이너리 데이터를 다루는 코드의 경우 `bytes`를 사용하세요.
-- 텍스트 데이터(Python 2에서는 `str` 또는 `unicode`, Python3에서는 `str`)를 처리하는 Python 2 호환 코드의 경우 `Text`를 사용하세요.
+  - 부적절한 예
 
-```python
-def deals_with_text_data_in_py3(x: str) -> str:
-  ...
-def deals_with_binary_data(x: bytes) -> bytes:
-  ...
-def py2_compatible_text_data_processor(x: Text) -> Text:
-  ...
-```
+    ```python
+      T = TypeVar("T")
+      P = ParamSpec("P")
+      _T = TypeVar("_T", int, float, str)
+      _F = TypeVar("_F", bound=Callable)
+    ```
 
-- 일부 흔하지 않은 Python2 호환성 사례에서는 `Text` 대신 `str`이 의미가 있을 수 있으며 일반적으로 Python2와 Python3 간에 반환 유형이 동일하지 않을 때 호환성을 돕기 위해 사용됩니다.
-- Python3에는 `unicode`가 없으므로 절대 사용하지 마세요.
-- 이러한 불일치가 존재하는 이유는 `str`이 Python3와 Python2에서 다른 의미를 갖기 때문입니다.
+<a id="s3.19.11-string-types"></a>
+<a id="s3.19.11-strings"></a>
+<a id="31911-string-types"></a>
+<a id="typing-strings"></a>
 
-- 부적절한 예
+#### 3.19.11 문자열 Type
 
-```python
-def py2_code(x: str) -> unicode:
-  ...
-```
+> 새로운 코드에서는 `typing.Text`를 사용하지 마세요. 이는 Python 2/3 호환성을 위한 것입니다.
 
-If the type can be either bytes or text, use `Union`, with the appropriate text
-type.
+- 문자열/텍스트 데이터에는 `str`을 사용하세요. 이진 데이터와 관련된 코드에서는 `bytes`를 사용하세요.
 
-```python
-from typing import Text, Union
-...
-def py3_only(x: Union[bytes, str]) -> Union[bytes, str]:
-  ...
-def py2_compatible(x: Union[bytes, Text]) -> Union[bytes, Text]:
-  ...
-```
+  ```python
+  def deals_with_text_data(x: str) -> str:
+    ...
+  def deals_with_binary_data(x: bytes) -> bytes:
+    ...
+  ```
 
 - 함수의 모든 string Type이 항상 동일한 경우(예, 반환 Type이 위의 코드에서 인자 Type과 동일한 경우) [AnyStr](#s3.19.10-type-var)를 사용하세요.
 
@@ -2614,19 +2811,31 @@ def py2_compatible(x: Union[bytes, Text]) -> Union[bytes, Text]:
 
 #### 3.19.12 Typing 추가
 
-- `typing` 모듈의 클래스는 항상 클래스 자체를 가져와야 합니다. `typing` 모듈에서 한 줄에 여러개의 특정 클래스를 가져올 수 있습니다.
+- `typing` 또는 `collections.abc` 모듈에서 정적 분석 및 타입 검사를 지원하기 위해 사용하는 심볼(타입, 함수, 상수 등)은 항상 심볼 자체를 임포트하세요.
+- 이렇게 하면 일반적인 주석이 더 간결해지고, 전 세계적으로 사용되는 타입 주석 관행에 맞출 수 있습니다.
+- `typing` 및 `collections.abc` 모듈에서 여러 개의 특정 심볼을 한 줄에서 명시적으로 임포트할 수 있습니다.
 
   ```python
-  from typing import Any, Dict, Optional
+  from collections.abc import Mapping, Sequence
+  from typing import Any, Generic, cast, TYPE_CHECKING
   ```
 
-- `typing`에서 가져오는 이러한 방식이 로컬 네임스페이스에 항목을 추가한다는 점에서, `typing`의 모든 이름은 키워드와 유사하게 취급되어야 하며, typing이든 아니든 Python 코드에 정의되어서는 안됩니다.
-- 모듈에 있는 Type과 기존 이름이 충돌하는 경우 `import x as y`를 사용해서 가져와야 합니다.
+- 이 방식으로 임포트하면 로컬 네임스페이스에 항목이 추가되므로, `typing` 또는 `collections.abc`의 이름은 키워드와 유사하게 취급되어야 하며, Python 코드에서 정의되지 않아야 합니다. 타입 여부와 관계없이 말입니다.
+- 모듈 내에서 타입과 기존 이름 간에 충돌이 있는 경우, `import x as y`를 사용하여 임포트하세요.
 
   ```python
   from typing import Any as AnyType
   ```
 
+- 가능한 경우, 주석으로 내장 타입을 사용하는 것이 좋습니다.
+- Prefer to use built-in types as annotations where available.
+- Python은 [PEP-585](https://peps.python.org/pep-0585/)를 통해 매개형 컨테이너 타입을 사용한 타입 주석을 지원하며, 이는 Python 3.9에서 도입되었습니다.
+
+  ```python
+  def generate_foo_scores(foo: set[str]) -> list[float]:
+    ...
+  ```
+
 <a id="typing-conditional-imports"></a>
 <a id="s3.19.13-conditional-imports"></a>
 
@@ -2667,7 +2876,7 @@ def f(x: "sketch.Sketch"): ...
   - 하지만 기술적으로 Circular 종속성을 유지하는 것은 가능하지만, 다양한 빌드 시스템은 다른 모듈에 의존해야 하기 때문에 그렇게 하도록 허락하지 않을 것입니다.
 
 - Circular 종속을 생성하는 모듈을 `Any`로 교체합니다.
-  - 의미있는 이름으로 [alias](#s3.19.6-aliases)를 지정하고 모듈의 실제 Type 이름을 사용하세요 (어떤 것의 어떤 속성인 Any).
+  - 의미있는 이름으로 [alias](#s3.19.6-aliases)를 지정하고 모듈의 실제 Type 이름을 사용하세요 (`Any`의 모든 속성은 `Any`입니다.).
   - Alias의 정의는 마지막으로 import와 한 줄로 분리합니다.
 
 ```python
@@ -2684,34 +2893,38 @@ def my_method(self, var: "some_mod.SomeType") -> None:
 
 #### 3.19.15 일반
 
-- 주석을 달때, 일반 Type를 지정하기를 선호하며 그렇지 [않을 때에는 `Any`로 가정합니다](https://www.python.org/dev/peps/pep-0484/#the-any-type).
+- 주석을 달때, 일반 Type를 지정하기를 선호하며 그렇지 [않을 때에는 `Any`로 가정합니다](https://peps.python.org/pep-0484/#the-any-type).
 
-```python
-def get_names(employee_ids: List[int]) -> Dict[int, Any]:
-  ...
-```
+  - 올바른 예
 
-```python
-# 두 개의 함수 모두 get_names(employee_ids: List[Any]) -> Dict[Any, Any]
-def get_names(employee_ids: list) -> Dict:
-  ...
+    ```python
+    def get_names(employee_ids: Sequence[int]) -> Mapping[int, str]:
+      ...
+    ```
 
-def get_names(employee_ids: List) -> Dict:
-  ...
-```
+  - 부적절한 예
+
+    ```python
+    # 이는 get_names(employee_ids: Sequence[Any]) -> Mapping[Any, Any]로 해석됩니다.
+    def get_names(employee_ids: Sequence) -> Mapping:
+    ```
 
 - 파라미터의 적합한 Type이 `Any`일 때, 명시적으로 표현되며, 많은 경우에 [`TypeVar`](#s3.19.10-type-var)가 더 적합할 수 있음을 기억해야합니다.
 
-```python
-def get_names(employee_ids: List[Any]) -> Dict[Any, str]:
-  """직원의 아이디를 이름과 연결하여 반환합니다."""
-```
+  - 부적절한 예
 
-```python
-T = TypeVar('T')
-def get_names(employee_ids: List[T]) -> Dict[T, str]:
-  """직원의 아이디를 이름과 연결하여 반환합니다."""
-```
+    ```python
+    def get_names(employee_ids: Sequence[Any]) -> Mapping[Any, str]:
+      """직원의 아이디를 이름과 연결하여 반환합니다."""
+    ```
+
+  - 올바른 예
+
+    ```python
+    _T = TypeVar('_T')
+    def get_names(employee_ids: Sequence[_T]) -> Mapping[_T, str]:
+      """직원의 아이디를 이름과 연결하여 반환합니다."""
+    ```
 
 ---
 
@@ -2724,9 +2937,14 @@ def get_names(employee_ids: List[T]) -> Dict[T, str]:
 <h3> 일관성을 유지하세요 </h3>
 
 - 당신이 코드를 수정한다면 몇 분을 투자해서 코드를 살펴보고 스타일을 파악하세요.
-- 만약 모든 산술 연산자에 공백을 넣었다면 당신도 그렇게 해야합니다. 만약 주석이 hash marks(`#`)으로 만든 박스 안에 들어있다면 당신의 주석도 그렇게 해야합니다.
+- 그들이 인덱스 변수 이름에 `_idx` 접미사를 사용하는 경우, 당신도 그렇게 해야 합니다. 만약 주석이 hash marks(`#`)으로 만든 박스 안에 들어있다면 당신의 주석도 그렇게 해야합니다.
+
 - 스타일 가이드라인의 요점은 코딩에서 공통된 어투를 갖는 것입니다. 그렇게 된다면 사람들은 당신의 코딩 형식보다는 당신의 코드에 집중할 수 있습니다
 - 우리는 여기서 사람들이 어휘를 알 수 있는 세계적인 코딩 스타일 규칙을 제공하지만 고유의 스타일도 중요합니다.
-- 파일에 코드를 추가했을 때 이 코드가 다른 코드와 비교하여 크게 달라 보이면 코드를 읽는 사람의 입장에서는 리듬이 깨집니다. 이 부분을 주의하세요.
+- 파일에 코드를 추가했을 때 이 코드가 다른 코드와 비교하여 크게 달라 보이면 코드를 읽는 사람의 입장에서는 리듬이 깨집니다.
+
+- 그러나 일관성에는 한계가 있습니다.
+- 일관성은 주로 지역적으로 적용되며, 전역 스타일에서 명시되지 않은 선택에 더 강하게 적용됩니다.
+- 일관성을 구식 스타일을 고수하는 정당화의 근거로 삼기보다는 새로운 스타일의 장점이나 코드베이스가 시간이 지남에 따라 새로운 스타일로 수렴하는 경향을 고려하는 것이 좋습니다.
 
 ---
diff --git "a/Google Python Style Guide/1. \353\260\260\352\262\275/1.1 \353\260\260\352\262\275.md" "b/Google Python Style Guide/1. \353\260\260\352\262\275/1.1 \353\260\260\352\262\275.md"
index 3d1bb9c..b8a52b9 100644
--- "a/Google Python Style Guide/1. \353\260\260\352\262\275/1.1 \353\260\260\352\262\275.md"	
+++ "b/Google Python Style Guide/1. \353\260\260\352\262\275/1.1 \353\260\260\352\262\275.md"	
@@ -2,4 +2,4 @@
 - 이 스타일 가이드는 Python 프로그램에서 _해야 할 것들과 하지 말아야 할 것_ 들을 적어놓았습니다.
 - 코드 형식을 정확하게 하는 것들 돕기 위해, 우리는 [settings file for Vim](google_python_style.vim)을 만들었습니다.
 - Emacs 편집기에서는 기본 설정값으로 사용하면 됩니다.
-- 많은 팀에서 형식에 대한 논쟁을 피하기 위해 [yapf](https://github.com/google/yapf/) auto-formatter 을 사용합니다.
+- 많은 팀에서 형식에 대한 논쟁을 피하기 위해 [Black](https://github.com/psf/black) 혹은 [Pyink](https://github.com/google/pyink) auto-formatter 을 사용합니다.
diff --git "a/Google Python Style Guide/1. \353\260\260\352\262\275/ReadMe.md" "b/Google Python Style Guide/1. \353\260\260\352\262\275/ReadMe.md"
index 95a60bc..6e36234 100644
--- "a/Google Python Style Guide/1. \353\260\260\352\262\275/ReadMe.md"	
+++ "b/Google Python Style Guide/1. \353\260\260\352\262\275/ReadMe.md"	
@@ -2,6 +2,6 @@
 - 이 스타일 가이드는 Python 프로그램에서 _해야 할 것들과 하지 말아야 할 것_ 들을 적어놓았습니다.
 - 코드 형식을 정확하게 하는 것들 돕기 위해, 우리는 [settings file for Vim](google_python_style.vim)을 만들었습니다.
 - Emacs 편집기에서는 기본 설정값으로 사용하면 됩니다.
-- 많은 팀에서 형식에 대한 논쟁을 피하기 위해 [yapf](https://github.com/google/yapf/) auto-formatter 을 사용합니다.
+- 많은 팀에서 형식에 대한 논쟁을 피하기 위해 [Black](https://github.com/psf/black) 혹은 [Pyink](https://github.com/google/pyink) auto-formatter 을 사용합니다.
 
 ---
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.1 Lint.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.1 Lint.md"
index bb18076..13bc698 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.1 Lint.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.1 Lint.md"	
@@ -38,7 +38,8 @@
 - 경고를 띄우지 않기 위해, 코드에 라인 단위로 주석을 달아야 합니다.
 
   ```python
-  dict = 'something awful'  # Bad Idea... pylint: disable=redefined-builtin
+  def do_PUT(self):  # WSGI name, so pylint: disable=invalid-name
+    ...
   ```
 
 - `pylint`의 경고는 각각 symbolic name(`empty-docstring`)으로 구별됩니다.
@@ -54,7 +55,7 @@
 - 각 메시지에 대해 자세한 정보를 얻고자 하는 경우 다음과 같은 방법으로 볼 수 있습니다.
 
   ```shell
-  pylint --help-msg=C6409
+  pylint --help-msg=invalid-name
   ```
 
 - `pyling: disable-msg`는 이전에 사용했던 방식으로 이제는 사용되지 않으며 `pylint: disable`를 사용합니다.
@@ -62,7 +63,7 @@
 - 아래 예시를 참고하세요.
 
   ```python
-  def viking_cafe_order(spam: str, beans: str, eggs: Optional[str] = None) -> str:
+  def viking_cafe_order(spam: str, beans: str, eggs: str | None = None) -> str:
       del beans, eggs  # Unused by vikings.
       return spam + spam + spam
   ```
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.10 \353\236\214\353\213\244.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.10 \353\236\214\353\213\244.md"
index 1dd955c..49be062 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.10 \353\236\214\353\213\244.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.10 \353\236\214\353\213\244.md"	
@@ -28,8 +28,6 @@
 
 #### 2.10.4 결론
 
-- 람다를 한 줄로 사용하세요. 만약 코드 내부에 있는 람다 함수가 60~80글자 수 정도로 길다면 그건 아마 더 일반적인 
-  [Lexical Scoping(렉시컬 스코핑)](#s2.16-lexical-scoping)으로 정의하는게 나을 것입니다.
-
+- 람다 함수는 허용하지만, 람다 함수 내부의 코드가 여러 줄에 걸치거나 60-80자를 넘는 경우, 일반적인 [중첩 함수](#s2.16-lexical-scoping)로 정의하는 것이 더 나을 수 있습니다.
 - 곱셈 같은 일반 연산자에서는 `operator`모듈 대신에 람다 함수를 사용하세요.
 - 예를 들어, `operator.mul`을 `lambda x,y : x * y` 처럼 사용하시면 됩니다.
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.12 \352\270\260\353\263\270 \354\235\270\354\236\220 \352\260\222.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.12 \352\270\260\353\263\270 \354\235\270\354\236\220 \352\260\222.md"
index cd25666..9241081 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.12 \352\270\260\353\263\270 \354\235\270\354\236\220 \352\260\222.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.12 \352\270\260\353\263\270 \354\235\270\354\236\220 \352\260\222.md"	
@@ -50,7 +50,7 @@
   def foo(a, b=None):
       if b is None:
           b = []
-  def foo(a, b: Optional[Sequence] = None):
+  def foo(a, b: Sequence | None = None):
       if b is None:
           b = []
   def foo(a, b: Sequence = ()):  # tuples은 불변하기 때문에 사용 가능합니다.
@@ -60,12 +60,15 @@
 - 부적절한 예
 
   ```python
+  from absl import flags
+  _FOO = flags.DEFINE_string(...)
+
   def foo(a, b=[]):
       ...
-  def foo(a, b=time.time()):  # 모듈이 로드가 될 때의 시간인가???
+  def foo(a, b=time.time()):  # `b`가 이 모듈이 로드된 시간을 나타내는 것인가요?
       ...
-  def foo(a, b=FLAGS.my_thing):  # sys.argv는 아직 구문 분석되지 않았습니다...
+  def foo(a, b=_FOO.value):  # sys.argv는 아직 구문 분석되지 않았습니다...
       ...
-  def foo(a, b: Mapping = {}):  # 확인되지 않은 코드로 전달 될 수 있습니다...
+  def foo(a, b: Mapping = {}):  # 확인되지 않은 코드로 전달 될 수 있습니다.
       ...
   ```
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.14 True, False \355\217\211\352\260\200.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.14 True, False \355\217\211\352\260\200.md"
index 6679926..dcbdbfc 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.14 True, False \355\217\211\352\260\200.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.14 True, False \355\217\211\352\260\200.md"	
@@ -2,7 +2,7 @@
 
 ### 2.14 True/False 평가
 
-- 가능한 경우 "암묵적(implicit)" `false`를 사용하세요.
+- 가능한 경우 "암묵적(implicit)" `false`를 사용하세요. (몇 가지 주의사항이 있지만)
 
 <a id="s2.14.1-definition"></a>
 
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.16 \353\240\211\354\213\234\354\273\254 \354\212\244\354\275\224\355\225\221(Lexical Scoping).md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.16 \353\240\211\354\213\234\354\273\254 \354\212\244\354\275\224\355\225\221(Lexical Scoping).md"
index d4be156..cc7b9b3 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.16 \353\240\211\354\213\234\354\273\254 \354\212\244\354\275\224\355\225\221(Lexical Scoping).md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.16 \353\240\211\354\213\234\354\273\254 \354\212\244\354\275\224\355\225\221(Lexical Scoping).md"	
@@ -33,7 +33,7 @@
 
 #### 2.16.3 단점
 
-- 혼란스러운 버그로 이어질 수 있습니다. [PEP-0227](http://www.google.com/url?sa=D&q=http://www.python.org/dev/peps/pep-0227/)에서 자세한 정보를 확인할 수 있습니다.
+- [PEP-0227](https://peps.python.org/pep-0227)을 기반으로 한 이 예시와 같이 혼란스러운 버그를 초래할 수 있습니다.
 
   ```python
   i = 4
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.17 \355\225\250\354\210\230\354\231\200 \353\251\224\354\204\234\353\223\234 Decorators.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.17 \355\225\250\354\210\230\354\231\200 \353\251\224\354\204\234\353\223\234 Decorators.md"
index 1dd350f..1621f76 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.17 \355\225\250\354\210\230\354\231\200 \353\251\224\354\204\234\353\223\234 Decorators.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.17 \355\225\250\354\210\230\354\231\200 \353\251\224\354\204\234\353\223\234 Decorators.md"	
@@ -49,6 +49,6 @@
 
 - Decorator는 분명한 이점이 있더라도 현명하게 사용해야 합니다. Decorator는 import와 명명 지침을 따라야 합니다. Decorator pydoc는 decorator 함수 임을 분명히 명시해야합니다. dcorator를 위한 유닛 테스트(unit test)를 사용해야합니다.
 - Decorator(예. 파일, 소켓, 데이터베이스 연결 등) 를 실행할 때 (`pydoc` 혹은 기타 도구를 import 시간에 가져올 때) 사용 못할 수 있으므로 Decorator의 외부 의존성을 피하세요. 유효한 매개변수를 가진 Decorator은 모든 경우에 작동할 수 있도록 보장되어야 합니다.
-- Decorator는 "Top level code"의 특별한 경우일 때에는 [main](#s3.17-main) 항목에 자세한 내용이 있습니다.
+- Decorator는 "Top-level code"의 특별한 경우일 때에는 [main](#s3.17-main) 항목에 자세한 내용이 있습니다.
 - 기존 라이브러리에 정의된 API와 통합하기 위해 강제하지 않는 한 "staticmethod"를 사용하지 마세요. 대신 모듈 레벨 함수를 쓰세요.
-- 프로세스 전체 캐시 등 필요한 global state를 수정하는 명명된 생성자 또는 클래스별 루틴을 작성할 때만 "classmethod"를 사용하세요.
+- classmethod는 명명된 생성자를 작성하거나 프로세스 전체 캐시와 같은 필수 전역 상태를 수정하는 클래스 특정 루틴을 작성할 때만 사용하세요.
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.18 \354\212\244\353\240\210\353\223\234.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.18 \354\212\244\353\240\210\353\223\234.md"
index cdaa505..e9f6d32 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.18 \354\212\244\353\240\210\353\223\234.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.18 \354\212\244\353\240\210\353\223\234.md"	
@@ -2,4 +2,4 @@
 
 ### 2.18 스레드
 
-- 내장된 타입의 원자성에 의존하지 마세요. 딕셔너리와 같은 Python의 내장된 타입은 원자 형태로 조작할 수 있지만 그러지 않은 경우(예: `__hash__`이나 `__eq__`가 Python 함수로 구현되는 경우)도 있으며 원자로 되어있다고 신뢰하면 안 됩니다. 또한, 원자 변수 할당에 의존해서는 안 됩니다. (결국, 딕셔너리에 달려있기 때문입니다) 스레드 간 데이터를 통신하는 데 선호하는 방법으로 큐 모듈의 `Queue` 데이터 타입을 사용하세요. 그렇지 않으면 threading 모듈이나 locking primitives를 사용하세요. lower-level lock 대신해 Condition variables와 `threading.Condition`를 선호하세요.
+- 내장된 타입의 원자성에 의존하지 마세요. 딕셔너리와 같은 Python의 내장된 타입은 원자 형태로 조작할 수 있지만 그러지 않은 경우(예: `__hash__`이나 `__eq__`가 Python 함수로 구현되는 경우)도 있으며 원자로 되어있다고 신뢰하면 안 됩니다. 또한, 원자 변수 할당에 의존해서는 안 됩니다. (결국, 딕셔너리에 달려있기 때문입니다) 스레드 간 데이터를 통신하는 데 선호하는 방법으로 `queue` 모듈의 `Queue` 데이터 타입을 사용하세요. 그렇지 않으면 `threading` 모듈이나 locking primitives를 사용하세요. lower-level lock 대신해 Condition variables와 `threading.Condition`를 선호하세요.
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.2 import.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.2 import.md"
index 540bedb..ca138c7 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.2 import.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.2 import.md"	
@@ -2,7 +2,7 @@
 
 ### 2.2 Imports
 
-- `import`문을 사용할때 package와 module에 사용하고 개별 클래스나 함수에 대해 사용하면 안됩니다. 다만 [typing 모듈](#s3.19.12-imports), [typing_extensions module](https://github.com/python/typing/tree/master/typing_extensions)에서 가져온 클래스 및 [six.moves module](https://six.readthedocs.io/#module-six.moves)에서의 리디렉션은 이 규칙에서 제외됩니다.
+- `import`문은 개별 타입, 클래스, 함수가 아니라 패키지와 모듈에만 사용하세요. (주: 개별 타입은 기본 자료형, 사용자 정의 클래스를 나타냅니다.)
 
 <a id="s2.2.1-definition"></a>
 
@@ -28,8 +28,13 @@
 
 - `import x`를 패키지와 모듈을 import할때 사용하세요.
 - `from x import y`를 `x`가 패키지의 접두어이고 `y`가 접두어가 없는 모듈일때 사용하세요.
-- 만약 `y` 로 이름이 지어진 두 모듈이 import되거나 `y` 가 불필요하게 너무 긴 이름을 가졌다면 `from x import y as z`를 사용세요.
-- `import y as z`를 `z` 가 공식적인 약어인 경우에만 사용하세요(e.g., `np` 는 `numpy` 를 의미합니다.)
+- 다음과 같은 상황에서는 `from x import y as z` 를 사용하세요.
+  - `y`라는 이름을 가진 두 개의 모듈을 가져옵니다.
+  - `y`는 현재 모듈에 정의된 최상위 이름과 충돌합니다.
+  - `y`는 공개 API의 일부인 공통 매개변수 이름(예: 'features')과 충돌합니다.
+  - `y`는 불편할 정도로 긴 이름입니다.
+  - `y`는 코드 컨텍스트에서 너무 일반적입니다(예: `from storage.file_system import options as fs_options`).
+- `import y as z`를 `z` 가 공식적인 약어인 경우에만 사용하세요(e.g., `import numpy as np`)
 
 - 예를들어 `sound.effects.echo`모듈이 import 된다면 아래와 같습니다.
 
@@ -42,3 +47,14 @@
 - import된것들과 관련있는 이름을 사용하지마세요.
 - 모듈이 같은 패키지에 있더라도 전체 패키지 이름을 사용하세요.
 - 이는 무심코 패키지를 두번 import 하는것을 예방하는 것에 도움이 됩니다.
+
+<a id="imports-exemptions"></a>
+
+##### 2.2.4.1 예외
+
+- 이 규칙의 예외는 다음과 같습니다.
+  - 다음 모듈의 심볼은 정적 분석 및 타입 검사를 지원하는 데 사용됩니다.
+    - [`typing` module](#typing-imports)
+    - [`collections.abc` module](#typing-imports)
+    - [`typing_extensions` module](https://github.com/python/typing_extensions/blob/main/README.md)
+  - [six.moves module](https://six.readthedocs.io/#module-six.moves)의 리다이렉션입니다.
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.20 \355\230\204\353\214\200\354\235\230 \355\214\214\354\235\264\354\215\254.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.20 Modern Python.md"
similarity index 58%
rename from "Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.20 \355\230\204\353\214\200\354\235\230 \355\214\214\354\235\264\354\215\254.md"
rename to "Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.20 Modern Python.md"
index 26c355b..740f633 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.20 \355\230\204\353\214\200\354\235\230 \355\214\214\354\235\264\354\215\254.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.20 Modern Python.md"	
@@ -40,22 +40,4 @@
   from __future__ import generator_stop
   ```
 
-- 2.7 버전을 계속 지원해야하는 부담이 있는 레거시 코드의 경우
-
-  ```python
-  from __future__ import absolute_import
-  from __future__ import division
-  from __future__ import print_function
-  ```
-
 - 자세한 내용은 [Python future statement definitions](https://docs.python.org/3/library/__future__.html) 문서를 읽어보세요.
-- 코드가 충분히 현대적인 환경에서만 사용된다는 확신이 들 때까지 이러한 import를 제거하지 마세요.
-- 현재 코드에서 특정 향후 import를 통해 활성화되는 기능을 현재 사용하지 않더라도 파일에 해당 기능을 유지하면 나중에 코드가 이전 동작에 따라 실수로 수정되는 것을 방지할 수 있습니다.
-- 적절하다고 생각되는 다른 `from __future__` import 문을 사용하세요.
-- 2.7버전 내에 여러 위치에서 도입된 암시적 기본 코덱 변환 결과로 인해 확실하지 않았기 때문에 2.7버전에 대한 권장 사항에 `unicode_literals`를 포함하지 않았습니다.
-- 대부분의 이중 버전 2-3 코드는 필요한 경우 `b''` 와 `u''` q바트와 유니코드 문자열 리터럴을 명시적으로 사용하는 것이 더 나았습니다.
-
-##### six, future 그리고 past 라이브러리
-
-- 프로젝트가 여전히 Python 2, 3 모두에서 사용을 지원해야하는 경우 적합하다고 판단되는 대로 [six](https://pypi.org/project/six/), [future](https://pypi.org/project/future/), 및 [past](https://pypi.org/project/past/) 라이브러리를 사용하세요.
-- 코드를 더 깨끗하고 삶을 더 쉽게 만들기 위해 존재합니다.
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.21 Type \354\243\274\354\204\235.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.21 Type \354\243\274\354\204\235.md"
index fed0b6b..1241ef4 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.21 Type \354\243\274\354\204\235.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.21 Type \354\243\274\354\204\235.md"	
@@ -3,8 +3,8 @@
 
 ### 2.21 Type 주석
 
-- Python 3에서 타입의 정보를 [PEP-484](https://www.python.org/dev/peps/pep-0484/)의 참고해서 주석으로 달 수 있습니다. 그리고 빌드 할 때 [pytype](https://github.com/google/pytype)같은 타입검사도구를 사용하세요.
-- Type에 대한 주석은 소스 안이나 [stub pyi 파일](https://www.python.org/dev/peps/pep-0484/#stub-files)에 있을 수 있습니다. 가능하면 주석은 소스안에 있어야 합니다. 타사 또는 확장 모듈에는 pyi 파일을 사용하세요.
+- Python에서 타입의 정보를 [PEP-484](https://www.python.org/dev/peps/pep-0484/)의 참고해서 주석으로 달 수 있습니다. 그리고 빌드 할 때 [pytype](https://github.com/google/pytype)같은 타입검사도구를 사용하세요.
+- Type에 대한 주석은 소스 안이나 [stub pyi 파일](https://peps.python.org/pep-0484/#stub-files)에 있을 수 있습니다. 가능하면 주석은 소스안에 있어야 합니다. 타사 또는 확장 모듈에는 pyi 파일을 사용하세요.
 
 <a id="s2.21.1-definition"></a>
 
@@ -13,21 +13,15 @@
 - Type의 주석(혹은 Type 정보)은 함수나 메서드의 인자값이나 반환값입니다
 
   ```python
-  def func(a: int) -> List[int]:
+  def func(a: int) -> list[int]:
   ```
 
-- [PEP-526](https://www.python.org/dev/peps/pep-0526/)구문 처럼 변수의 type을 선언할 때 사용합니다.
+- [PEP-526](https://peps.python.org/pep-0526/)구문 처럼 변수의 type을 선언할 때 사용합니다.
 
   ```python
   a: SomeType = some_func()
   ```
 
-- legacy Python version을 지원해야한다면 코드에 type 설명을 추가합니다.
-
-  ```python
-  a = some_func()  # type: SomeType
-  ```
-
 <a id="s2.21.2-pros"></a>
 
 #### 2.21.2 장점
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.3 package.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.3 package.md"
index 844e3bc..318c6d1 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.3 package.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.3 package.md"	
@@ -31,7 +31,7 @@
     import absl.flags
     from doctor.who import jodie
 
-    FLAGS = absl.flags.FLAGS
+    _FOO = absl.flags.DEFINE_string(...)
     ```
 
     ```python
@@ -39,7 +39,7 @@
     from absl import flags
     from doctor.who import jodie
 
-    FLAGS = flags.FLAGS
+    _FOO = flags.DEFINE_string(...)
     ```
 
   - 부적절한 예 _(이 파일은 `doctor/who/` 에 있다고 가정하고 `jodie.py`또한 존재한다고 가정합니다.)_
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.4 \354\230\210\354\231\270\354\262\230\353\246\254.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.4 \354\230\210\354\231\270\354\262\230\353\246\254.md"
index 48dbd10..c2b0ba4 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.4 \354\230\210\354\231\270\354\262\230\353\246\254.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.4 \354\230\210\354\231\270\354\262\230\353\246\254.md"	
@@ -30,10 +30,8 @@
 
 ##### 예외는 다음과 같은 조건을 만족해야 합니다
 
-- 적절한 경우 내장 예외 클래스를 사용하세요.
-- 예를 들어, 만약 양수를 예상하는데 음수가 통과한다면 `ValueError`를 발생시는 것이 그 예입니다.
-- 공공 API에 있는 인수의 값을 검증하기 위해 `assert`문을 사용하지마세요.
-- `assert`는 올바른 사용이나 예상치 못한 이벤트 발생을 나타내는 것이 아니라 내부적 정확성을 보장하기 위해 사용됩니다. 만약 나중에 예외가 필요하다면, raise문을 실행하세요.
+- 내장 예외 클래스를 사용하는 데에 문제가 없다면 사용합니다. 예를 들어, 함수 인자를 검증할 때와 같은 프로그래밍 오류나 위반된 전제조건을 나타내기 위해 `ValueError`를 발생시키세요.
+- `assert` 문을 조건문이나 전제조건 검증 대신 사용하지 마세요. application logic에 중요하지 않아야 합니다. `assert`문을 제거해도 코드가 정상적으로 작동한다면, 그것이 기준이 될 수 있습니다. assert 조건문은 평가될 것이라고 [보장되지 않습니다](https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement). [pytest](https://pytest.org)기반의 테스트에서는 `assert` 문을 사용하여 기대값을 검증하는 것이 적절하고 예상됩니다
 
   - 올바른 예
 
@@ -52,9 +50,10 @@
         if minimum < 1024:
             raise ValueError(f'Min. port must be at least 1024, not {minimum}.')
         port = self._find_next_open_port(minimum)
-        if not port:
+        if port is None:
           raise ConnectionError(
               f'Could not connect to service on port {minimum} or higher.')
+        # 이 코드의 결과는 이 assert에 의존하지 않습니다.
         assert port >= minimum, (
             f'Unexpected port {port} when minimum was {minimum}.')
         return port
@@ -72,8 +71,10 @@
         The new minimum port.
         """
         assert minimum >= 1024, 'Minimum port must be at least 1024.'
+        # 이 코드는 이전 assert에 의존합니다.
         port = self._find_next_open_port(minimum)
         assert port is not None
+        # 반환 값에 대한 타입 검사는 assert에 의존합니다.
         return port
     ```
 
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.5 \353\263\200\352\262\275 \352\260\200\353\212\245\355\225\234 \354\240\204\354\227\255 \354\203\201\355\203\234.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.5 \353\263\200\352\262\275 \352\260\200\353\212\245\355\225\234 \354\240\204\354\227\255 \354\203\201\355\203\234.md"
new file mode 100644
index 0000000..c55b77e
--- /dev/null
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.5 \353\263\200\352\262\275 \352\260\200\353\212\245\355\225\234 \354\240\204\354\227\255 \354\203\201\355\203\234.md"	
@@ -0,0 +1,40 @@
+<a id="s2.5-global-variables"></a>
+<a id="25-global-variables"></a>
+<a id="s2.5-global-state"></a>
+<a id="25-global-state"></a>
+
+### 2.5 변경 가능한 전역 상태
+
+- 변경 가능한 전역 상태를 사용하지 마세요.
+
+<a id="s2.5.1-definition"></a>
+
+#### 2.5.1 정의
+
+- 프로그램 실행 중 변경될 수 있는 모듈 수준의 값이나 클래스 속성을 말합니다.
+
+<a id="s2.5.2-pros"></a>
+
+#### 2.5.2 장점
+
+- 가끔 편리합니다.
+
+<a id="s2.5.3-cons"></a>
+<a id="253-cons"></a>
+<a id="global-variables-cons"></a>
+
+#### 2.5.3 단점
+
+- 캡슐화가 깨집니다.
+  - 이러한 설계는 유효한 목표를 달성하기 어렵게 만들 수 있습니다. 예를 들면, 전역 상태를 사용하여 데이터베이스 연결을 관리하는 경우, 두 개의 서로 다른 데이터베이스를 동시에 연결하는 것이 어려워질 수 있습니다(e.g., 마이그레이션 중 차이를 계산할 때). 전역 레지스트리에서도 유사한 문제가 쉽게 발생할 수 있습니다.
+- 모듈이 처음 임포트될 때 전역 변수에 대한 할당이 이루어지기 때문에, 모듈의 동작을 임포트 중에 변경할 가능성이 있습니다.
+
+<a id="s2.5.4-decision"></a>
+<a id="254-decision"></a>
+<a id="global-variables-decision"></a>
+
+#### 2.5.4 결론
+
+- 변경 가능한 전역 상태를 사용하지 마세요.
+  - 전역 상태를 사용하는 것이 드물게 필요한 경우, 변경 가능한 전역 엔티티는 모듈 수준이나 클래스 속성으로 선언하고, 이름 앞에 `_`를 붙여 내부적으로 사용해야 합니다. 필요한 경우, 변경 가능한 전역 상태에 대한 외부 접근은 공개 함수나 클래스 메소드를 통해 이루어져야 합니다. [Naming](#s3.16-naming)를 참고하세요. 변경 가능한 전역 상태를 사용하는 설계 이유에 대해서는 주석에 설명하거나 링크된 문서에서 설명해 주세요.
+  - 모듈 수준의 상수는 허용되며 권장됩니다. 예를 들어, 내부 용도의 상수에는 `_MAX_HOLY_HANDGRENADE_COUNT = 3`를 사용하고, Public API 상수에는 `SIR_LANCELOTS_FAVORITE_COLOR = "blue"`를 사용하세요. 상수는 모두 대문자와 밑줄을 사용하여 명명해야 합니다. [Naming](#s3.16-naming)를 참고하세요.
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.5 \354\240\204\354\227\255\353\263\200\354\210\230.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.5 \354\240\204\354\227\255\353\263\200\354\210\230.md"
deleted file mode 100644
index e633522..0000000
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.5 \354\240\204\354\227\255\353\263\200\354\210\230.md"	
+++ /dev/null
@@ -1,34 +0,0 @@
-<a id="s2.5-global-variables"></a>
-
-### 2.5 전역 변수
-
-- 전역 변수를 사용하지 마세요.
-
-<a id="s2.5.1-definition"></a>
-
-#### 2.5.1 정의
-
-- 모듈이나 클래스 속성으로 선언된 변수를 말합니다.
-
-<a id="s2.5.2-pros"></a>
-
-#### 2.5.2 장점
-
-- 가끔 편리합니다.
-
-<a id="s2.5.3-cons"></a>
-
-#### 2.5.3 단점
-
-- import되는 동안 모듈의 동작이 변경될 수도 있습니다. 왜냐하면 전역 변수의 할당은 모듈을 처음 import를 할때 수행이 되기 때문입니다.
-
-<a id="s2.5.4-decision"></a>
-
-#### 2.5.4 결론
-
-- 전역 변수를 사용하지 마세요.
-
-- 전역변수는 기술적으로는 변수이지만, module-level 상수가 허용되고 권장됩니다.
-- 예를들어 `_MAX_HOLY_HANDGRENADE_COUNT = 3`. 상수는 반드시 모든 공백 `_`를 넣어서 이름을 만들어야 합니다.
-- 만약 전역변수가 필요하다면 module-level에서 선언되고 모듈 내부에서 이름에 `_`를 붙여서 만들어져야 합니다.
-- 외부 접근은 반드시 public단위의 module-level 함수를 통해서 동작되어야 합니다. [Naming](#s3.16-naming)을 참고하세요.
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.6 \354\244\221\354\262\251.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.6 \354\244\221\354\262\251.md"
index d8fa7eb..4c9be0b 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.6 \354\244\221\354\262\251.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.6 \354\244\221\354\262\251.md"	
@@ -18,7 +18,7 @@
 #### 2.6.2 장점
 
 - 제한된 스코프 내에서 사용하는 유틸리티 클래스와 함수의 정의를 허용합니다.
-- [ADT](http://www.google.com/url?sa=D&q=http://en.wikipedia.org/wiki/Abstract_data_type)가 무엇인지 참고하세요.
+- [ADT](https://ko.wikipedia.org/wiki/추상_자료형)가 무엇인지 참고하세요.
 - 일반적으로 데코레이터를 구현할 때 사용됩니다.
 
 <a id="s2.6.3-cons"></a>
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.7 list_comprehensions.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.7 list_comprehensions.md"
index 7820afb..e61736b 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.7 list_comprehensions.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.7 list_comprehensions.md"	
@@ -28,19 +28,17 @@
 
 #### 2.7.4 결론
 
-- 복잡하지 않은 상황에서 사용하세요. 각각의 부분은 반드시 한 라인에서 끝나야 합니다.
-- map, for문, filter 표현식이 그 예입니다. 중첩 for문이나 filter문은 허용되지 않습니다.
-- loop문을 통해 코드를 단순화 할 수 있으면 사용하세요.
+- 컴프리헨션(comprehension)은 허용되지만, 여러 개의 for 절이나 필터 표현식은 허용되지 않습니다. 간결함보다는 가독성을 우선시하세요.
 - 올바른 예
 
   ```python
   result = [mapping_expr for value in iterable if filter_expr]
 
-  result = [{'key': value} for value in iterable
-              if a_long_filter_expression(value)]
-
-  result = [complicated_transform(x)
-              for x in iterable if predicate(x)]
+  result = [
+      is_valid(metric={'key': value})
+      for value in interesting_iterable
+      if a_longer_filter_expression(value)
+  ]
 
   descriptive_name = [
       transform({'key': key, 'value': value}, color='black')
@@ -50,35 +48,30 @@
 
   result = []
   for x in range(10):
-      for y in range(5):
-          if x * y > 10:
-              result.append((x, y))
-
-  return {x: complicated_transform(x)
-          for x in long_generator_function(parameter)
-          if x is not None}
-
-  squares_generator = (x**2 for x in range(10))
+    for y in range(5):
+      if x * y > 10:
+        result.append((x, y))
+  return {
+      x: complicated_transform(x)
+      for x in long_generator_function(parameter)
+      if x is not None
+  }
+  return (x**2 for x in range(10))
 
   unique_names = {user.name for user in users if user is not None}
-
-  eat(jelly_bean for jelly_bean in jelly_beans
-      if jelly_bean.color == 'black')
   ```
 
 - 부적절한 예
 
   ```python
-  result = [complicated_transform(
-                  x, some_argument=x+1)
-              for x in iterable if predicate(x)]
-
   result = [(x, y) for x in range(10) for y in range(5) if x * y > 10]
 
-  return ((x, y, z)
-          for x in range(5)
-          for y in range(5)
-          if x != y
-          for z in range(5)
-          if y != z)
+  return (
+      (x, y, z)
+      for x in range(5)
+      for y in range(5)
+      if x != y
+      for z in range(5)
+      if y != z
+  )
   ```
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.8 \352\270\260\353\263\270 \353\260\230\353\263\265\354\236\220\354\231\200 \354\227\260\354\202\260\354\236\220.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.8 \352\270\260\353\263\270 \353\260\230\353\263\265\354\236\220\354\231\200 \354\227\260\354\202\260\354\236\220.md"
index dbca5ac..6d1fd56 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.8 \352\270\260\353\263\270 \353\260\230\353\263\265\354\236\220\354\231\200 \354\227\260\354\202\260\354\236\220.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.8 \352\270\260\353\263\270 \353\260\230\353\263\265\354\236\220\354\231\200 \354\227\260\354\202\260\354\236\220.md"	
@@ -21,7 +21,7 @@
 
 #### 2.8.3 단점
 
-- 메소드 이름을 읽어도 객체의 타입을 유추할 수 없습니다.(e.g. `has_key()`는 딕셔너리를 의미합니다.) 이건 이점이 될 수도 있습니다.
+- 메소드 이름을 읽어도 객체의 타입을 유추할 수 없습니다.(변수에 타입 주석이 없는 경우) 이건 이점이 될 수도 있습니다.
 
 <a id="s2.8.4-decision"></a>
 
@@ -34,18 +34,14 @@
 
   ```python
   for key in adict: ...
-  if key not in adict: ...
   if obj in alist: ...
   for line in afile: ...
   for k, v in adict.items(): ...
-  for k, v in six.iteritems(adict): ...
   ```
 
 - 부적절한 예
 
   ```python
   for key in adict.keys(): ...
-  if not adict.has_key(key): ...
   for line in afile.readlines(): ...
-  for k, v in dict.iteritems(): ...
   ```
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.9 \354\240\234\353\204\210\353\240\210\354\235\264\355\204\260.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.9 \354\240\234\353\204\210\353\240\210\354\235\264\355\204\260.md"
index c7aa226..1118025 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.9 \354\240\234\353\204\210\353\240\210\354\235\264\355\204\260.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/2.9 \354\240\234\353\204\210\353\240\210\354\235\264\355\204\260.md"	
@@ -22,10 +22,12 @@
 
 #### 2.9.3 단점
 
-- 없습니다.
+- 제너레이터 내의 지역 변수는 제너레이터가 모두 소모되거나 자체적으로 가비지 컬렉션될 때까지 가비지 컬렉션되지 않습니다.
 
 <a id="s2.9.4-decision"></a>
 
 #### 2.9.4 결론
 
 - 제너레이터 함수에서 docstring에 대해 "Returns:"보다 "Yields:"를 사용하세요.
+- 제너레이터가 비용이 많이 드는 자원을 관리하는 경우, 정리 작업을 강제로 수행해야 합니다.
+- 정리 작업을 잘 수행하는 방법 중 하나는 제너레이터를 컨텍스트 매니저로 감싸는 것입니다 ([PEP-0533](https://peps.python.org/pep-0533/)).
diff --git "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/ReadMe.md" "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/ReadMe.md"
index cedd157..646f39a 100644
--- "a/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/ReadMe.md"	
+++ "b/Google Python Style Guide/2. Python \354\226\270\354\226\264 \352\267\234\354\271\231/ReadMe.md"	
@@ -38,7 +38,8 @@
 - 경고를 띄우지 않기 위해, 코드에 라인 단위로 주석을 달아야 합니다.
 
   ```python
-  dict = 'something awful'  # Bad Idea... pylint: disable=redefined-builtin
+  def do_PUT(self):  # WSGI name, so pylint: disable=invalid-name
+    ...
   ```
 
 - `pylint`의 경고는 각각 symbolic name(`empty-docstring`)으로 구별됩니다.
@@ -54,7 +55,7 @@
 - 각 메시지에 대해 자세한 정보를 얻고자 하는 경우 다음과 같은 방법으로 볼 수 있습니다.
 
   ```shell
-  pylint --help-msg=C6409
+  pylint --help-msg=invalid-name
   ```
 
 - `pyling: disable-msg`는 이전에 사용했던 방식으로 이제는 사용되지 않으며 `pylint: disable`를 사용합니다.
@@ -62,7 +63,7 @@
 - 아래 예시를 참고하세요.
 
   ```python
-  def viking_cafe_order(spam: str, beans: str, eggs: Optional[str] = None) -> str:
+  def viking_cafe_order(spam: str, beans: str, eggs: str | None = None) -> str:
       del beans, eggs  # Unused by vikings.
       return spam + spam + spam
   ```
@@ -74,7 +75,7 @@
 
 ### 2.2 Imports
 
-- `import`문을 사용할때 package와 module에 사용하고 개별 클래스나 함수에 대해 사용하면 안됩니다. 다만 [typing 모듈](#s3.19.12-imports), [typing_extensions module](https://github.com/python/typing/tree/master/typing_extensions)에서 가져온 클래스 및 [six.moves module](https://six.readthedocs.io/#module-six.moves)에서의 리디렉션은 이 규칙에서 제외됩니다.
+- `import`문은 개별 타입, 클래스, 함수가 아니라 패키지와 모듈에만 사용하세요. (주: 개별 타입은 기본 자료형, 사용자 정의 클래스를 나타냅니다.)
 
 <a id="s2.2.1-definition"></a>
 
@@ -100,8 +101,13 @@
 
 - `import x`를 패키지와 모듈을 import할때 사용하세요.
 - `from x import y`를 `x`가 패키지의 접두어이고 `y`가 접두어가 없는 모듈일때 사용하세요.
-- 만약 `y` 로 이름이 지어진 두 모듈이 import되거나 `y` 가 불필요하게 너무 긴 이름을 가졌다면 `from x import y as z`를 사용세요.
-- `import y as z`를 `z` 가 공식적인 약어인 경우에만 사용하세요(e.g., `np` 는 `numpy` 를 의미합니다.)
+- 다음과 같은 상황에서는 `from x import y as z` 를 사용하세요.
+  - `y`라는 이름을 가진 두 개의 모듈을 가져옵니다.
+  - `y`는 현재 모듈에 정의된 최상위 이름과 충돌합니다.
+  - `y`는 공개 API의 일부인 공통 매개변수 이름(예: 'features')과 충돌합니다.
+  - `y`는 불편할 정도로 긴 이름입니다.
+  - `y`는 코드 컨텍스트에서 너무 일반적입니다(예: `from storage.file_system import options as fs_options`).
+- `import y as z`를 `z` 가 공식적인 약어인 경우에만 사용하세요(e.g., `import numpy as np`)
 
 - 예를들어 `sound.effects.echo`모듈이 import 된다면 아래와 같습니다.
 
@@ -115,6 +121,17 @@
 - 모듈이 같은 패키지에 있더라도 전체 패키지 이름을 사용하세요.
 - 이는 무심코 패키지를 두번 import 하는것을 예방하는 것에 도움이 됩니다.
 
+<a id="imports-exemptions"></a>
+
+##### 2.2.4.1 예외
+
+- 이 규칙의 예외는 다음과 같습니다.
+  - 다음 모듈의 심볼은 정적 분석 및 타입 검사를 지원하는 데 사용됩니다.
+    - [`typing` module](#typing-imports)
+    - [`collections.abc` module](#typing-imports)
+    - [`typing_extensions` module](https://github.com/python/typing_extensions/blob/main/README.md)
+  - [six.moves module](https://six.readthedocs.io/#module-six.moves)의 리다이렉션입니다.
+
 ---
 <a id="s2.3-packages"></a>
 
@@ -149,7 +166,7 @@
     import absl.flags
     from doctor.who import jodie
 
-    FLAGS = absl.flags.FLAGS
+    _FOO = absl.flags.DEFINE_string(...)
     ```
 
     ```python
@@ -157,7 +174,7 @@
     from absl import flags
     from doctor.who import jodie
 
-    FLAGS = flags.FLAGS
+    _FOO = flags.DEFINE_string(...)
     ```
 
   - 부적절한 예 _(이 파일은 `doctor/who/` 에 있다고 가정하고 `jodie.py`또한 존재한다고 가정합니다.)_
@@ -205,10 +222,8 @@
 
 ##### 예외는 다음과 같은 조건을 만족해야 합니다
 
-- 적절한 경우 내장 예외 클래스를 사용하세요.
-- 예를 들어, 만약 양수를 예상하는데 음수가 통과한다면 `ValueError`를 발생시는 것이 그 예입니다.
-- 공공 API에 있는 인수의 값을 검증하기 위해 `assert`문을 사용하지마세요.
-- `assert`는 올바른 사용이나 예상치 못한 이벤트 발생을 나타내는 것이 아니라 내부적 정확성을 보장하기 위해 사용됩니다. 만약 나중에 예외가 필요하다면, raise문을 실행하세요.
+- 내장 예외 클래스를 사용하는 데에 문제가 없다면 사용합니다. 예를 들어, 함수 인자를 검증할 때와 같은 프로그래밍 오류나 위반된 전제조건을 나타내기 위해 `ValueError`를 발생시키세요.
+- `assert` 문을 조건문이나 전제조건 검증 대신 사용하지 마세요. application logic에 중요하지 않아야 합니다. `assert`문을 제거해도 코드가 정상적으로 작동한다면, 그것이 기준이 될 수 있습니다. assert 조건문은 평가될 것이라고 [보장되지 않습니다](https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement). [pytest](https://pytest.org)기반의 테스트에서는 `assert` 문을 사용하여 기대값을 검증하는 것이 적절하고 예상됩니다
 
   - 올바른 예
 
@@ -227,9 +242,10 @@
         if minimum < 1024:
             raise ValueError(f'Min. port must be at least 1024, not {minimum}.')
         port = self._find_next_open_port(minimum)
-        if not port:
+        if port is None:
           raise ConnectionError(
               f'Could not connect to service on port {minimum} or higher.')
+        # 이 코드의 결과는 이 assert에 의존하지 않습니다.
         assert port >= minimum, (
             f'Unexpected port {port} when minimum was {minimum}.')
         return port
@@ -247,8 +263,10 @@
         The new minimum port.
         """
         assert minimum >= 1024, 'Minimum port must be at least 1024.'
+        # 이 코드는 이전 assert에 의존합니다.
         port = self._find_next_open_port(minimum)
         assert port is not None
+        # 반환 값에 대한 타입 검사는 assert에 의존합니다.
         return port
     ```
 
@@ -261,16 +279,19 @@
 
 ---
 <a id="s2.5-global-variables"></a>
+<a id="25-global-variables"></a>
+<a id="s2.5-global-state"></a>
+<a id="25-global-state"></a>
 
-### 2.5 전역 변수
+### 2.5 변경 가능한 전역 상태
 
-- 전역 변수를 사용하지 마세요.
+- 변경 가능한 전역 상태를 사용하지 마세요.
 
 <a id="s2.5.1-definition"></a>
 
 #### 2.5.1 정의
 
-- 모듈이나 클래스 속성으로 선언된 변수를 말합니다.
+- 프로그램 실행 중 변경될 수 있는 모듈 수준의 값이나 클래스 속성을 말합니다.
 
 <a id="s2.5.2-pros"></a>
 
@@ -279,21 +300,24 @@
 - 가끔 편리합니다.
 
 <a id="s2.5.3-cons"></a>
+<a id="253-cons"></a>
+<a id="global-variables-cons"></a>
 
 #### 2.5.3 단점
 
-- import되는 동안 모듈의 동작이 변경될 수도 있습니다. 왜냐하면 전역 변수의 할당은 모듈을 처음 import를 할때 수행이 되기 때문입니다.
+- 캡슐화가 깨집니다.
+  - 이러한 설계는 유효한 목표를 달성하기 어렵게 만들 수 있습니다. 예를 들면, 전역 상태를 사용하여 데이터베이스 연결을 관리하는 경우, 두 개의 서로 다른 데이터베이스를 동시에 연결하는 것이 어려워질 수 있습니다(e.g., 마이그레이션 중 차이를 계산할 때). 전역 레지스트리에서도 유사한 문제가 쉽게 발생할 수 있습니다.
+- 모듈이 처음 임포트될 때 전역 변수에 대한 할당이 이루어지기 때문에, 모듈의 동작을 임포트 중에 변경할 가능성이 있습니다.
 
 <a id="s2.5.4-decision"></a>
+<a id="254-decision"></a>
+<a id="global-variables-decision"></a>
 
 #### 2.5.4 결론
 
-- 전역 변수를 사용하지 마세요.
-
-- 전역변수는 기술적으로는 변수이지만, module-level 상수가 허용되고 권장됩니다.
-- 예를들어 `_MAX_HOLY_HANDGRENADE_COUNT = 3`. 상수는 반드시 모든 공백 `_`를 넣어서 이름을 만들어야 합니다.
-- 만약 전역변수가 필요하다면 module-level에서 선언되고 모듈 내부에서 이름에 `_`를 붙여서 만들어져야 합니다.
-- 외부 접근은 반드시 public단위의 module-level 함수를 통해서 동작되어야 합니다. [Naming](#s3.16-naming)을 참고하세요.
+- 변경 가능한 전역 상태를 사용하지 마세요.
+  - 전역 상태를 사용하는 것이 드물게 필요한 경우, 변경 가능한 전역 엔티티는 모듈 수준이나 클래스 속성으로 선언하고, 이름 앞에 `_`를 붙여 내부적으로 사용해야 합니다. 필요한 경우, 변경 가능한 전역 상태에 대한 외부 접근은 공개 함수나 클래스 메소드를 통해 이루어져야 합니다. [Naming](#s3.16-naming)를 참고하세요. 변경 가능한 전역 상태를 사용하는 설계 이유에 대해서는 주석에 설명하거나 링크된 문서에서 설명해 주세요.
+  - 모듈 수준의 상수는 허용되며 권장됩니다. 예를 들어, 내부 용도의 상수에는 `_MAX_HOLY_HANDGRENADE_COUNT = 3`를 사용하고, Public API 상수에는 `SIR_LANCELOTS_FAVORITE_COLOR = "blue"`를 사용하세요. 상수는 모두 대문자와 밑줄을 사용하여 명명해야 합니다. [Naming](#s3.16-naming)를 참고하세요.
 
 ---
 <a id="s2.6-nested"></a>
@@ -316,7 +340,7 @@
 #### 2.6.2 장점
 
 - 제한된 스코프 내에서 사용하는 유틸리티 클래스와 함수의 정의를 허용합니다.
-- [ADT](http://www.google.com/url?sa=D&q=http://en.wikipedia.org/wiki/Abstract_data_type)가 무엇인지 참고하세요.
+- [ADT](https://ko.wikipedia.org/wiki/추상_자료형)가 무엇인지 참고하세요.
 - 일반적으로 데코레이터를 구현할 때 사용됩니다.
 
 <a id="s2.6.3-cons"></a>
@@ -365,19 +389,17 @@
 
 #### 2.7.4 결론
 
-- 복잡하지 않은 상황에서 사용하세요. 각각의 부분은 반드시 한 라인에서 끝나야 합니다.
-- map, for문, filter 표현식이 그 예입니다. 중첩 for문이나 filter문은 허용되지 않습니다.
-- loop문을 통해 코드를 단순화 할 수 있으면 사용하세요.
+- 컴프리헨션(comprehension)은 허용되지만, 여러 개의 for 절이나 필터 표현식은 허용되지 않습니다. 간결함보다는 가독성을 우선시하세요.
 - 올바른 예
 
   ```python
   result = [mapping_expr for value in iterable if filter_expr]
 
-  result = [{'key': value} for value in iterable
-              if a_long_filter_expression(value)]
-
-  result = [complicated_transform(x)
-              for x in iterable if predicate(x)]
+  result = [
+      is_valid(metric={'key': value})
+      for value in interesting_iterable
+      if a_longer_filter_expression(value)
+  ]
 
   descriptive_name = [
       transform({'key': key, 'value': value}, color='black')
@@ -387,37 +409,32 @@
 
   result = []
   for x in range(10):
-      for y in range(5):
-          if x * y > 10:
-              result.append((x, y))
-
-  return {x: complicated_transform(x)
-          for x in long_generator_function(parameter)
-          if x is not None}
-
-  squares_generator = (x**2 for x in range(10))
+    for y in range(5):
+      if x * y > 10:
+        result.append((x, y))
+  return {
+      x: complicated_transform(x)
+      for x in long_generator_function(parameter)
+      if x is not None
+  }
+  return (x**2 for x in range(10))
 
   unique_names = {user.name for user in users if user is not None}
-
-  eat(jelly_bean for jelly_bean in jelly_beans
-      if jelly_bean.color == 'black')
   ```
 
 - 부적절한 예
 
   ```python
-  result = [complicated_transform(
-                  x, some_argument=x+1)
-              for x in iterable if predicate(x)]
-
   result = [(x, y) for x in range(10) for y in range(5) if x * y > 10]
 
-  return ((x, y, z)
-          for x in range(5)
-          for y in range(5)
-          if x != y
-          for z in range(5)
-          if y != z)
+  return (
+      (x, y, z)
+      for x in range(5)
+      for y in range(5)
+      if x != y
+      for z in range(5)
+      if y != z
+  )
   ```
 
 ---
@@ -444,7 +461,7 @@
 
 #### 2.8.3 단점
 
-- 메소드 이름을 읽어도 객체의 타입을 유추할 수 없습니다.(e.g. `has_key()`는 딕셔너리를 의미합니다.) 이건 이점이 될 수도 있습니다.
+- 메소드 이름을 읽어도 객체의 타입을 유추할 수 없습니다.(변수에 타입 주석이 없는 경우) 이건 이점이 될 수도 있습니다.
 
 <a id="s2.8.4-decision"></a>
 
@@ -457,20 +474,16 @@
 
   ```python
   for key in adict: ...
-  if key not in adict: ...
   if obj in alist: ...
   for line in afile: ...
   for k, v in adict.items(): ...
-  for k, v in six.iteritems(adict): ...
   ```
 
 - 부적절한 예
 
   ```python
   for key in adict.keys(): ...
-  if not adict.has_key(key): ...
   for line in afile.readlines(): ...
-  for k, v in dict.iteritems(): ...
   ```
 
 ---
@@ -498,13 +511,15 @@
 
 #### 2.9.3 단점
 
-- 없습니다.
+- 제너레이터 내의 지역 변수는 제너레이터가 모두 소모되거나 자체적으로 가비지 컬렉션될 때까지 가비지 컬렉션되지 않습니다.
 
 <a id="s2.9.4-decision"></a>
 
 #### 2.9.4 결론
 
 - 제너레이터 함수에서 docstring에 대해 "Returns:"보다 "Yields:"를 사용하세요.
+- 제너레이터가 비용이 많이 드는 자원을 관리하는 경우, 정리 작업을 강제로 수행해야 합니다.
+- 정리 작업을 잘 수행하는 방법 중 하나는 제너레이터를 컨텍스트 매니저로 감싸는 것입니다 ([PEP-0533](https://peps.python.org/pep-0533/)).
 
 ---
 <a id="s2.10-lambda-functions"></a>
@@ -537,9 +552,7 @@
 
 #### 2.10.4 결론
 
-- 람다를 한 줄로 사용하세요. 만약 코드 내부에 있는 람다 함수가 60~80글자 수 정도로 길다면 그건 아마 더 일반적인 
-  [Lexical Scoping(렉시컬 스코핑)](#s2.16-lexical-scoping)으로 정의하는게 나을 것입니다.
-
+- 람다 함수는 허용하지만, 람다 함수 내부의 코드가 여러 줄에 걸치거나 60-80자를 넘는 경우, 일반적인 [중첩 함수](#s2.16-lexical-scoping)로 정의하는 것이 더 나을 수 있습니다.
 - 곱셈 같은 일반 연산자에서는 `operator`모듈 대신에 람다 함수를 사용하세요.
 - 예를 들어, `operator.mul`을 `lambda x,y : x * y` 처럼 사용하시면 됩니다.
 
@@ -649,7 +662,7 @@
   def foo(a, b=None):
       if b is None:
           b = []
-  def foo(a, b: Optional[Sequence] = None):
+  def foo(a, b: Sequence | None = None):
       if b is None:
           b = []
   def foo(a, b: Sequence = ()):  # tuples은 불변하기 때문에 사용 가능합니다.
@@ -659,13 +672,16 @@
 - 부적절한 예
 
   ```python
+  from absl import flags
+  _FOO = flags.DEFINE_string(...)
+
   def foo(a, b=[]):
       ...
-  def foo(a, b=time.time()):  # 모듈이 로드가 될 때의 시간인가???
+  def foo(a, b=time.time()):  # `b`가 이 모듈이 로드된 시간을 나타내는 것인가요?
       ...
-  def foo(a, b=FLAGS.my_thing):  # sys.argv는 아직 구문 분석되지 않았습니다...
+  def foo(a, b=_FOO.value):  # sys.argv는 아직 구문 분석되지 않았습니다...
       ...
-  def foo(a, b: Mapping = {}):  # 확인되지 않은 코드로 전달 될 수 있습니다...
+  def foo(a, b: Mapping = {}):  # 확인되지 않은 코드로 전달 될 수 있습니다.
       ...
   ```
 
@@ -718,7 +734,7 @@
 
 ### 2.14 True/False 평가
 
-- 가능한 경우 "암묵적(implicit)" `false`를 사용하세요.
+- 가능한 경우 "암묵적(implicit)" `false`를 사용하세요. (몇 가지 주의사항이 있지만)
 
 <a id="s2.14.1-definition"></a>
 
@@ -818,7 +834,7 @@
 
 #### 2.16.3 단점
 
-- 혼란스러운 버그로 이어질 수 있습니다. [PEP-0227](http://www.google.com/url?sa=D&q=http://www.python.org/dev/peps/pep-0227/)에서 자세한 정보를 확인할 수 있습니다.
+- [PEP-0227](https://peps.python.org/pep-0227)을 기반으로 한 이 예시와 같이 혼란스러운 버그를 초래할 수 있습니다.
 
   ```python
   i = 4
@@ -893,16 +909,16 @@
 
 - Decorator는 분명한 이점이 있더라도 현명하게 사용해야 합니다. Decorator는 import와 명명 지침을 따라야 합니다. Decorator pydoc는 decorator 함수 임을 분명히 명시해야합니다. dcorator를 위한 유닛 테스트(unit test)를 사용해야합니다.
 - Decorator(예. 파일, 소켓, 데이터베이스 연결 등) 를 실행할 때 (`pydoc` 혹은 기타 도구를 import 시간에 가져올 때) 사용 못할 수 있으므로 Decorator의 외부 의존성을 피하세요. 유효한 매개변수를 가진 Decorator은 모든 경우에 작동할 수 있도록 보장되어야 합니다.
-- Decorator는 "Top level code"의 특별한 경우일 때에는 [main](#s3.17-main) 항목에 자세한 내용이 있습니다.
+- Decorator는 "Top-level code"의 특별한 경우일 때에는 [main](#s3.17-main) 항목에 자세한 내용이 있습니다.
 - 기존 라이브러리에 정의된 API와 통합하기 위해 강제하지 않는 한 "staticmethod"를 사용하지 마세요. 대신 모듈 레벨 함수를 쓰세요.
-- 프로세스 전체 캐시 등 필요한 global state를 수정하는 명명된 생성자 또는 클래스별 루틴을 작성할 때만 "classmethod"를 사용하세요.
+- classmethod는 명명된 생성자를 작성하거나 프로세스 전체 캐시와 같은 필수 전역 상태를 수정하는 클래스 특정 루틴을 작성할 때만 사용하세요.
 
 ---
 <a id="s2.18-threading"></a>
 
 ### 2.18 스레드
 
-- 내장된 타입의 원자성에 의존하지 마세요. 딕셔너리와 같은 Python의 내장된 타입은 원자 형태로 조작할 수 있지만 그러지 않은 경우(예: `__hash__`이나 `__eq__`가 Python 함수로 구현되는 경우)도 있으며 원자로 되어있다고 신뢰하면 안 됩니다. 또한, 원자 변수 할당에 의존해서는 안 됩니다. (결국, 딕셔너리에 달려있기 때문입니다) 스레드 간 데이터를 통신하는 데 선호하는 방법으로 큐 모듈의 `Queue` 데이터 타입을 사용하세요. 그렇지 않으면 threading 모듈이나 locking primitives를 사용하세요. lower-level lock 대신해 Condition variables와 `threading.Condition`를 선호하세요.
+- 내장된 타입의 원자성에 의존하지 마세요. 딕셔너리와 같은 Python의 내장된 타입은 원자 형태로 조작할 수 있지만 그러지 않은 경우(예: `__hash__`이나 `__eq__`가 Python 함수로 구현되는 경우)도 있으며 원자로 되어있다고 신뢰하면 안 됩니다. 또한, 원자 변수 할당에 의존해서는 안 됩니다. (결국, 딕셔너리에 달려있기 때문입니다) 스레드 간 데이터를 통신하는 데 선호하는 방법으로 `queue` 모듈의 `Queue` 데이터 타입을 사용하세요. 그렇지 않으면 `threading` 모듈이나 locking primitives를 사용하세요. lower-level lock 대신해 Condition variables와 `threading.Condition`를 선호하세요.
 
 ---
 <a id="s2.19-power-features"></a>
@@ -980,25 +996,7 @@
   from __future__ import generator_stop
   ```
 
-- 2.7 버전을 계속 지원해야하는 부담이 있는 레거시 코드의 경우
-
-  ```python
-  from __future__ import absolute_import
-  from __future__ import division
-  from __future__ import print_function
-  ```
-
 - 자세한 내용은 [Python future statement definitions](https://docs.python.org/3/library/__future__.html) 문서를 읽어보세요.
-- 코드가 충분히 현대적인 환경에서만 사용된다는 확신이 들 때까지 이러한 import를 제거하지 마세요.
-- 현재 코드에서 특정 향후 import를 통해 활성화되는 기능을 현재 사용하지 않더라도 파일에 해당 기능을 유지하면 나중에 코드가 이전 동작에 따라 실수로 수정되는 것을 방지할 수 있습니다.
-- 적절하다고 생각되는 다른 `from __future__` import 문을 사용하세요.
-- 2.7버전 내에 여러 위치에서 도입된 암시적 기본 코덱 변환 결과로 인해 확실하지 않았기 때문에 2.7버전에 대한 권장 사항에 `unicode_literals`를 포함하지 않았습니다.
-- 대부분의 이중 버전 2-3 코드는 필요한 경우 `b''` 와 `u''` q바트와 유니코드 문자열 리터럴을 명시적으로 사용하는 것이 더 나았습니다.
-
-##### six, future 그리고 past 라이브러리
-
-- 프로젝트가 여전히 Python 2, 3 모두에서 사용을 지원해야하는 경우 적합하다고 판단되는 대로 [six](https://pypi.org/project/six/), [future](https://pypi.org/project/future/), 및 [past](https://pypi.org/project/past/) 라이브러리를 사용하세요.
-- 코드를 더 깨끗하고 삶을 더 쉽게 만들기 위해 존재합니다.
 
 ---
 <a id="s2.21-type-annotated-code"></a>
@@ -1006,8 +1004,8 @@
 
 ### 2.21 Type 주석
 
-- Python 3에서 타입의 정보를 [PEP-484](https://www.python.org/dev/peps/pep-0484/)의 참고해서 주석으로 달 수 있습니다. 그리고 빌드 할 때 [pytype](https://github.com/google/pytype)같은 타입검사도구를 사용하세요.
-- Type에 대한 주석은 소스 안이나 [stub pyi 파일](https://www.python.org/dev/peps/pep-0484/#stub-files)에 있을 수 있습니다. 가능하면 주석은 소스안에 있어야 합니다. 타사 또는 확장 모듈에는 pyi 파일을 사용하세요.
+- Python에서 타입의 정보를 [PEP-484](https://www.python.org/dev/peps/pep-0484/)의 참고해서 주석으로 달 수 있습니다. 그리고 빌드 할 때 [pytype](https://github.com/google/pytype)같은 타입검사도구를 사용하세요.
+- Type에 대한 주석은 소스 안이나 [stub pyi 파일](https://peps.python.org/pep-0484/#stub-files)에 있을 수 있습니다. 가능하면 주석은 소스안에 있어야 합니다. 타사 또는 확장 모듈에는 pyi 파일을 사용하세요.
 
 <a id="s2.21.1-definition"></a>
 
@@ -1016,21 +1014,15 @@
 - Type의 주석(혹은 Type 정보)은 함수나 메서드의 인자값이나 반환값입니다
 
   ```python
-  def func(a: int) -> List[int]:
+  def func(a: int) -> list[int]:
   ```
 
-- [PEP-526](https://www.python.org/dev/peps/pep-0526/)구문 처럼 변수의 type을 선언할 때 사용합니다.
+- [PEP-526](https://peps.python.org/pep-0526/)구문 처럼 변수의 type을 선언할 때 사용합니다.
 
   ```python
   a: SomeType = some_func()
   ```
 
-- legacy Python version을 지원해야한다면 코드에 type 설명을 추가합니다.
-
-  ```python
-  a = some_func()  # type: SomeType
-  ```
-
 <a id="s2.21.2-pros"></a>
 
 #### 2.21.2 장점
diff --git "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.10 \353\254\270\354\236\220\354\227\264.md" "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.10 \353\254\270\354\236\220\354\227\264.md"
index b54023b..7b5d2ae 100644
--- "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.10 \353\254\270\354\236\220\354\227\264.md"	
+++ "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.10 \353\254\270\354\236\220\354\227\264.md"	
@@ -3,25 +3,24 @@
 ### 3.10 Strings
 
 - 매개변수가 모두 문자열인 경우에도 [f-string](https://docs.python.org/3/reference/lexical_analysis.html#f-strings), `format` 메소드나 `%` 연산자를 사용하여 포메팅하세요.
-- 물론 `+` 나 `%` (또는 `format`) 를 언제 사용할지는 개발자의 판단에 따릅니다.
-- 문자열을 합치기 위해 `%` 또는 `format`을 사용하지 마세요.
+- 문자열 포맷팅 옵션 사이에서 최상의 판단을 사용하세요.
+- `+`를 사용한 단일 join은 괜찮지만, `+`를 사용한 포맷팅은 피하세요.
 
   - 올바른 예
 
     ```python
-    x = a + b
+    x = f'name: {name}; score: {n}'
     x = '%s, %s!' % (imperative, expletive)
     x = '{}, {}'.format(first, second)
     x = 'name: %s; score: %d' % (name, n)
+    x = 'name: %(name)s; score: %(score)d' % {'name':name, 'score':n}
     x = 'name: {}; score: {}'.format(name, n)
-    x = f'name: {name}; score: {n}'
+    x = a + b
     ```
 
   - 부적절한 예
 
     ```python
-    x = '%s%s' % (a, b)  # use + in this case
-    x = '{}{}'.format(a, b)  # use + in this case
     x = first + ', ' + second
     x = 'name: ' + name + '; score: ' + str(n)
     ```
@@ -109,6 +108,9 @@
         will collapse common leading spaces in each line.""")
     ```
 
+- 여기서 백슬래시를 사용하는 것은 [명시적인 줄 이어쓰기](#line-length)에 대한 금지를 위반하지 않습니다.
+- 이 경우, 백슬래시는 문자열 리터럴에서 [줄바꿈을 이스케이프](https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals)하는 것입니다.
+
 <a id="s3.10.1-logging"></a>
 
 #### 3.10.1 Logging
@@ -159,7 +161,7 @@
 ```python
   올바른 예:
   if not 0 <= p <= 1:
-    raise ValueError(f'Not a probability: {p!r}')
+    raise ValueError(f'Not a probability: {p=}')
   try:
     os.rmdir(workdir)
   except OSError as error:
@@ -170,7 +172,7 @@
 ```python
   잘못된 예:
   if p < 0 or p > 1:  # PROBLEM: also false for float('nan')!
-    raise ValueError(f'Not a probability: {p!r}')
+    raise ValueError(f'Not a probability: {p=}')
   try:
     os.rmdir(workdir)
   except OSError:
diff --git "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.12 TODO \354\243\274\354\204\235.md" "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.12 TODO \354\243\274\354\204\235.md"
index 65490df..1853b33 100644
--- "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.12 TODO \354\243\274\354\204\235.md"	
+++ "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.12 TODO \354\243\274\354\204\235.md"	
@@ -4,16 +4,27 @@
 
 - 임시적, 잠시 사용하려는 코드 또는 좋기는 하지만 완벽하지 않은 코드의 경우 `TODO` 주석을 사용하세요.
 
-- `TODO` 주석은 대문자로 되어있는 `TODO` 문구로 시작하며 해당 코드에 대한 가장 높은 이해도를 가진 인물의 이름, 이메일 주소 또는 다른 신원구분 문구를 괄호안에 넣어 포함하여야 합니다.
-- 이것 뒤에 무엇을 해야하는 지에 대한 내용을 추가합니다.
+- `TODO` 주석은 모두 대문자로 된 `TODO`로 시작하고, 다음에 콜론을 붙이며, 맥락이 포함된 리소스에 대한 링크(이상적으로는 버그 참조)를 포함해야 합니다.
+- 버그 참조가 선호됩니다. 왜냐하면 버그는 추적되며 후속 댓글이 달리기 때문입니다.
+- 이 문맥 다음에 하이픈 `-`으로 시작하는 설명 문자열을 추가하세요..
+- 목적은 일관된 `TODO` 형식을 유지하여, 더 많은 세부 정보를 찾기 위해 검색할 수 있도록 하는 것입니다.
 
-- 목적은 `TODO`가 일관된 형식을 이용하여 추후 필요한 세부정보를 검색할 수 있어야 한다는 것입니다.
-- `TODO` 는 본인이 아닌 다른 개발자가 문제를 해결하겠다는 약속이 아닙니다.
-- 따라서 `TODO` 를 만드셨다면 거의 항상 작성한 본인의 이름이 들어가야 합니다.
+  ```python
+  # TODO: crbug.com/192795 - Investigate cpufreq optimizations.
+  ```
 
-```python
-# TODO(kl@gmail.com): Use a "*" here for string repetition.
-# TODO(Zeke) Change this to use relations.
-```
+- 이전 스타일로, 예전에는 권장되었지만 새로운 코드에서는 사용이 권장되지 않습니다.
 
-- 만약 작성한 `TODO` 가 "추후 무엇을 진행할 것" 이라는 형식을 담고 있다면 반드시 ("2009년 11월까지") 와 같은 구체적인 기간이나 ("모든 클라이언트가 XML 요청을 해결 할수 있을때 이 코드 삭제") 처럼 목적을 포함하여야 합니다.
+  ```python
+  # TODO(crbug.com/192795): Investigate cpufreq optimizations.
+  # TODO(yourusername): Use a "\*" here for concatenation operator.
+  ```
+
+- 문맥으로 개인이나 팀을 참조하는 TODO를 추가하는 것을 피하세요.
+
+  ```python
+  # TODO: @yourusername - File an issue and use a '*' for repetition.
+  ```
+
+- `TODO`가 "미래의 어느 시점에 무엇을 해야 한다"는 형식이라면, 미래의 코드 유지 관리자가 이해할 수 있도록 매우 구체적인 날짜("2009년 11월까지")나 사건("모든 클라이언트가 XML 요청을 해결 할수 있을때 이 코드 삭제")을 포함해야 합니다.
+- 이슈는 이를 추적하는 데 이상적입니다.
diff --git "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.13 import\355\230\225\354\213\235.md" "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.13 import\355\230\225\354\213\235.md"
index 28c1607..fd875c1 100644
--- "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.13 import\355\230\225\354\213\235.md"	
+++ "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.13 import\355\230\225\354\213\235.md"	
@@ -2,14 +2,14 @@
 
 ### 3.13 import 형식
 
-- imports는 개별적인 라인에 두어야 합니다; [`typing` imports에 대한 예외가 있습니다.](#s3.19.12-imports).
+- imports는 개별적인 라인에 두어야 합니다; [`typing` 그리고 `collections.abc` imports에 대한 예외가 있습니다.](#s3.19.12-imports).
 
   - 올바른 예
 
     ```python
     import os
     import sys
-    from typing import Mapping, Sequence
+    from typing import Any, NewType
     ```
 
   - 부적절한 예
@@ -21,7 +21,15 @@
 - import는 모듈의 주석 과 docstring 바로 다음, 모듈 전역 및 상수 바로 앞 파일의 맨 위에 배치됩니다.
 - import는 가장 일반적인 것 부터 최소한의 일반적인 것들까지 묶여야 합니다.
 
-1. 파이썬의 표준 라이브러리
+1. Python의 **future** import 문
+
+   ```python
+   from __future__ import annotations
+   ```
+
+   자세한 내용은 [위](#from-future-imports)를 참조하세요.
+
+2. 파이썬의 표준 라이브러리
 
    - import 예시는 다음과 같습니다.
 
@@ -29,7 +37,7 @@
    import sys
    ```
 
-2. [third-party](https://pypi.org/)
+3. [third-party](https://pypi.org/)
 
    - 모듈이나 패키지의 import 예시는 다음과 같습니다.
 
@@ -37,7 +45,7 @@
    import tensorflow as tf
    ```
 
-3. Code repository
+4. Code repository
 
    - 서브 패키지의 import 예시는 다음과 같습니다.
 
@@ -45,7 +53,7 @@
    from otherproject.ai import mind
    ```
 
-4. 동일한 top 레벨에 속하는 어플리케이션의 특정을 import하는 것은 **더 이상 사용되지 않습니다**
+5. 동일한 top 레벨에 속하는 어플리케이션의 특정을 import하는 것은 **더 이상 사용되지 않습니다**
 
    - 서브 패키지의 파일 import 예시는 다음과 같습니다.
 
diff --git "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.16 \353\204\244\354\235\264\353\260\215.md" "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.16 \353\204\244\354\235\264\353\260\215.md"
index ee536e6..744e67b 100644
--- "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.16 \353\204\244\354\235\264\353\260\215.md"	
+++ "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.16 \353\204\244\354\235\264\353\260\215.md"	
@@ -12,7 +12,9 @@
 `global_var_name`,
 `instance_var_name`,
 `function_parameter_name`,
-`local_var_name`.
+`local_var_name`,
+`query_proper_noun_for_thing`,
+`send_acronym_via_https`.
 
 - 함수 이름, 변수 이름, 그리고 파일 이름은 설명적이여야 하고 약어로 적는 일을 피해야 합니다.
 - 특히 모호하거나 프로젝트에 참여하지 않은 사람들이 읽었을 때 익숙하지 않은 약어를 사용하지마세요. 그리고 절대 단어에서 글자를 지워 줄이지 마세요.
@@ -23,15 +25,20 @@
 
 #### 3.16.1 피해야 할 이름
 
-1. 아래와 같은 특별한 경우를 제외한 단일 글자는 피합니다.
+- 아래와 같은 특별한 경우를 제외한 단일 글자는 피합니다.
+
+  - counters이나 iterators에서 사용할 때 (예. `i`, `j`, `k`, `v` 등)
+  - `try/except`문에서 예외 식별자로 `e`를 사용할 때
+  - with문의 파일 핸들에서 `f`를 사용할 때
+  - 제약 조건이 없는 비공식적인 [type variables](#typing-type-var)를 사용할 때 (e.g., `_T = TypeVar("_T"), _P = ParamSpec("_P")`)
 
-- counters이나 iterators에서 사용할 때 (예. `i`, `j`, `k`, `v` 등)
-- `try/except`문에서 예외 식별자로 `e`를 사용할 때
-- with문의 파일 핸들에서 `f`를 사용할 때
   단일 글자를 남용하지 않도록 주의해야합니다. 일반적으로 말해서 서술성은 이름의 가시성 범위에 비례해야합니다. 예를 들어 `i`는 5행 코드 블록에 적합한 이름일 수 있지만 중첩된 여러 범위 내에서는 너무 모호할 수 있습니다.
+
 - package/module 이름에서 dashes(`-`)를 사용할 때
 - `__이중_선행_및_후행_밑줄__` 이름을 사용할 때 (Python에서 예약어)
+
   - 원본에 없는 추가 설명 : double leading and trailing underscore : (앞 뒤로 \_가 2개씩 있는것 e.g **name**, **init**)
+
 - 공격적인 단어
 - 불필요하게 변수 타입을 포함하는 이름 (예 : `id_to_name_dict`)
 
@@ -43,16 +50,20 @@
 
 - "Internal"는 모듈의 내부 또는 클래스 내에서 protected 또는 private를 의미합니다.
 - 단일 밑줄(`_`)을 추가하면 모듈 변수와 함수를 보호하기 위한 몇 가지 지원이 있습니다. (linters는 보호된 멤버 접근에 플래그를 지정합니다.)
+- 단일 언더스코어(`_`)를 접두사로 사용하는 것은 모듈 변수와 함수 보호를 위한 일부 지원을 제공합니다 (linters가 보호된 멤버 접근을 경고할 수 있습니다). 그러나 유닛 테스트가 테스트 중인 모듈의 보호된 상수에 접근하는 것은 괜찮습니다.
 - 인스턴스 변수나 메소드에 이중 밑줄(`__` : dunder)을 추가하면 변수나 메소드가 해당 클래스에 대해 효과적으로 private 됩니다.
   - 가독성과 테스트 가능성에 영향을 미치고 _실제로_ 비공개가 아니므로 사용을 권장하지 않습니다.
   - 하나의 밑줄을 선호합니다.
 - 모듈에 관련 클래스와 top-level 함수를 함께 배치합니다.
 - 자바와는 다르게 하나의 모듈에 대해 하나의 클래스로 제한을 할 필요가 없습니다.
 - CapWords(단어의 첫 글자를 대문자로 하는 방식)을 사용하지만 모듈의 이름이 \_with_under.py 같은 경우에는 소문자로 합니다.
+
   - 비록 몇몇 오래된 모듈의 이름이 CapWords.py일지라도 이제는 모듈의 이름을 class이름에 따라 짓게 되면 혼란스러우므로 권장하지 않습니다. (e.g "잠깐만, -- 내가 `import StringIO`를 한거야 아니면 `from StringIO import StringIO`를 한거야 ?" 같은 상황이 발생할 수 있습니다.)
-- 구성 요소가 CapWord를 사용하더라도 "test"로 시작하는 _unittest_ 메서드 이름에 Undercore가 나타날 수 있습니다.
-  - 한 가지 가능한 패턴은 `test<MethodUnderTest>_<state>`로, 예를 들어 `testPop_EmptyStack`같은 패턴은 괜찮습니다.
-  - test 메서드에 에 이름을 붙이는 올바른 방법은 없습니다.
+
+- 새로운 유닛 테스트 파일은 PEP 8을 준수하는 소문자와 언더스코어 방식의 메서드 이름을 따릅니다.
+  - 예를 들어, `test*<method*under_test>*<state>`와 같은 형식을 사용합니다.
+  - 일관성을 위해(\*) 이전 모듈에서 CapWords 함수 이름을 따르는 경우, `test`로 시작하는 메서드 이름에 논리적 구성 요소를 구분하기 위해 언더스코어가 포함될 수 있습니다.
+  - 하나의 가능한 패턴은 `test<MethodUnderTest>_<state>`입니다.
 
 <a id="s3.16.3-file-naming"></a>
 
diff --git "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.19 Type \354\243\274\354\204\235 \353\260\251\353\262\225.md" "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.19 Type \354\243\274\354\204\235 \353\260\251\353\262\225.md"
index 2502927..4ea4d38 100644
--- "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.19 Type \354\243\274\354\204\235 \353\260\251\353\262\225.md"	
+++ "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.19 Type \354\243\274\354\204\235 \353\260\251\353\262\225.md"	
@@ -6,9 +6,24 @@
 
 #### 3.19.1 일반적인 규칙
 
-- [PEP-484](https://www.python.org/dev/peps/pep-0484/)을 읽으세요.
-- 메서드에서는 `self`, `cls`는 Type의 정보가 필요한 경우에서만 주석을 달아야합니다. 예) `@classmethod def create(cls: Type[T]) -> T: return cls()`
+- [PEP-484](https://peps.python.org/pep-0484/)을 읽으세요.
+
+- `self` 또는 `cls`에 주석을 달 필요는 일반적으로 없습니다. 올바른 타입 정보를 위해 필요한 경우에만 [`Self`](https://docs.python.org/3/library/typing.html#typing.Self)를 사용할 수 있습니다.
+
+  ```python
+  from typing import Self
+  class BaseClass:
+    @classmethod
+    def create(cls) -> Self:
+      ...
+    def difference(self, other: Self) -> float:
+      ...
+  ```
+
+- 마찬가지로, `__init__`의 반환 값에 주석을 달 필요는 없습니다 (여기서 `None`만 유효한 옵션입니다).
+
 - 모든 변수나 반환되는 Type이 정해지지 않았다면 `Any`를 사용하세요.
+
 - 모듈에서 모든 함수에 주석을 달 필요는 없습니다.
   - Public API에는 최소한의 주석을 답니다.
   - 판단력을 사용하여 한편으로는 안전성과 명확성, 그리고 다른 한편으로는 유연성 사이의 균형을 잘 잡아야 합니다.
@@ -23,12 +38,15 @@
 - 기존의 [들여쓰기](#s3.4-indentation) 규칙을 따르세요.
 
 - 주석처리하고나서 많은 함수는 "한 줄에 하나의 파라미터"가 될 것입니다.
+- 반환 타입이 별도의 줄에 표시되도록 보장하기 위해, 마지막 매개변수 뒤에 쉼표를 추가할 수 있습니다.
 
   ```python
-  def my_method(self,
-              first_var: int,
-              second_var: Foo,
-              third_var: Optional[Bar]) -> int:
+  def my_method(
+      self,
+      first_var: int,
+      second_var: Foo,
+      third_var: Bar | None,
+  ) -> int:
   ...
   ```
 
@@ -40,23 +58,25 @@
   ```
 
 - 함수 이름, 마지막 매개 변수 및 리턴 Type의 조합이 너무 길면 새 행에서 4만큼 들여 쓰기됩니다.
+- 줄 바꿈을 사용할 때는 각 매개변수와 반환 타입을 별도의 줄에 배치하고, 닫는 괄호를 `def`와 정렬하는 것이 좋습니다.
 
   ```python
   def my_method(
-      self, first_var: int) -> Tuple[MyLongType1, MyLongType1]:
+      self,
+      other_arg: MyLongType | None,
+  ) -> tuple[MyLongType1, MyLongType1]:
   ...
   ```
 
-리턴 유형이 마지막 파라미터와 같은 라인에 맞지 않을 경우, 선호되는 방법은 파라미터를 4만큼 새 라인에 들여쓰고 닫히는 괄호를 "def"와 정렬하는 것이다.
+- 선택적으로, 반환 타입을 마지막 매개변수와 같은 줄에 배치할 수도 있습니다.
 
-- 반환 Type이 마지막 파라미터와 같은 줄이 아닐 때, 선호하는 방법은 파라미터를 4만큼 새 라인에 들여쓰고 닫히는 괄호를 `def`와 정렬합니다.
-
-  - 올바른 예
+  - 괜찮은 예
 
     ```python
     def my_method(
-        self, **kw_args: Optional[MyLongType]
-    ) -> Dict[OtherLongType, MyLongType]:
+      self,
+      first_var: int,
+      second_var: int) -> dict[OtherLongType, MyLongType]:
     ...
     ```
 
@@ -66,8 +86,8 @@
 
     ```python
     def my_method(self,
-                **kw_args: Optional[MyLongType]
-                ) -> Dict[OtherLongType, MyLongType]:
+              other_arg: MyLongType | None,
+             ) -> dict[OtherLongType, MyLongType]:
     ...
     ```
 
@@ -77,10 +97,11 @@
   ```python
   def my_method(
       self,
-      first_var: Tuple[List[MyLongType1],
-                      List[MyLongType2]],
-      second_var: List[Dict[
-          MyLongType3, MyLongType4]]) -> None:
+      first_var: tuple[list[MyLongType1],
+                      list[MyLongType2]],
+      second_var: list[dict[
+          MyLongType3, MyLongType4]],
+  ) -> None:
   ...
   ```
 
@@ -111,23 +132,34 @@
 
 #### 3.19.3 전방선언
 
-- 아직 정의되지 않은 동일한 모듈의 클래스 이름을 사용해야 하는 경우(예, 클래스 선언 내에 클래스가 필요한 경우 또는 아래에 정의된 클래스를 사용하는 경우) `from __future__ import annotations`를 사용하세요.
-- 간단한 경우에는 주석을 사용하거나 클래스 이름에 문자열을 사용하세요.
+- 아직 정의되지 않은 클래스 이름(예를 들어, 클래스 선언 내부에서 클래스 이름이 필요하거나 코드에서 나중에 정의된 클래스를 사용할 경우)을 사용해야 할 경우, `from __future__ import annotations`를 사용하거나 클래스 이름을 문자열로 사용하세요.
 
-```python
-from __future__ import annotations
+  - 올바른 예
 
-class MyClass:
+    ```python
+    from __future__ import annotations
 
-  def __init__(self, stack: Sequence[MyClass]) -> None:
-```
+    class MyClass:
+      def __init__(self, stack: Sequence[MyClass], item: OtherClass) -> None:
+
+    class OtherClass:
+      ...
+    ```
+
+    ```python
+    class MyClass:
+      def __init__(self, stack: Sequence['MyClass'], item: 'OtherClass') -> None:
+
+    class OtherClass:
+      ...
+    ```
 
 <a id="s3.19.4-default-values"></a>
 
 #### 3.19.4 기본 값
 
 - PEP-008에 따라 유형 주석과 기본값이 모두 있는 인수의 경우 "=" \_ only" 주위에 공백을 사용하십시오.
-- [PEP-008](https://www.python.org/dev/peps/pep-0008/#other-recommendations)에 따라 Type 주석과 기본 값이 모두 있는 인수의 경우 `=` _only_ 주위에 공백을 사용하세요,
+- [PEP-008](https://peps.python.org/pep-0008/#other-recommendations)에 따라 Type 주석과 기본 값이 모두 있는 인수의 경우 `=` _only_ 주위에 공백을 사용하세요,
 
 - 올바른 예
 
@@ -147,19 +179,20 @@ class MyClass:
 
 #### 3.19.5 NoneType
 
-- 파이썬형에서 노네타입(NoneType)은 퍼스트클래스형이며, 타이핑을 위해 노네타입(NoneType)은 노네타입(NoneType)의 별칭이다. 논쟁이 '없음'이 될 수 있다면 선언해야 한다! 유니온(Union)은 사용할 수 있지만, 다른 유형이 하나만 있는 경우에는 선택사항(Option)을 사용하십시오.
+- 파이썬형에서 노네타입(NoneType)은 퍼스트클래스형이며, 타이핑을 위해 노네타입(NoneType)은 노네타입(NoneType)의 별칭이다.
+- 인자가 `None`이 될 수 있는 경우, 이를 선언해야 합니다!
+- 새로운 Python 3.10+ 코드에서는 `|` 유니온 타입 표현식을 사용하는 것이 권장되며, 이전에는 `Optional`과 `Union` 구문을 사용할 수 있습니다.
 
-- 파이썬 타입 시스템에서 `NoneType`은 "first class" Type 이며 작성을 위해 `None`은 `NoneType`의 alias(별칭)입니다. 인자는 `None`이 될 수 있다면 선언을 해야합니다! `Union`을 사용할 수 있지만 다른 Type이 하나만 있는 경우 `Optional`를 사용하세요.
-
-- 암시적 `Optional` 대신 명시적 `Optional` 사용해야 합니다. PEP 484 이전 버전에서는 `a: Optional[str] = None` 대신에 `a: str = None` 를 선호했지만 지금은 그렇지 않습니다.
+- 암시적인 대신 명시적인 `X | None`을 사용하세요.
+- 이전 버전의 PEP 484에서는 `a: str = None`을 `a: str | None = None`으로 해석할 수 있었지만, 이제는 이것이 선호되는 동작이 아닙니다.
 
 - 올바른 예
 
   ```python
-  def func(a: Optional[str], b: Optional[str] = None) -> str:
-  ...
-  def multiple_nullable_union(a: Union[None, str, int]) -> str:
-  ...
+  def modern_or_union(a: str | int | None, b: str | None = None) -> str:
+    ...
+  def union_optional(a: Union[str, int, None], b: Optional[str] = None) -> str:
+    ...
   ```
 
 - 부적절한 예
@@ -180,14 +213,13 @@ class MyClass:
 
 - 어려운 Type을 별칭으로 선언할 수 있습니다. 별칭은 CapWorded여야 합니다. 별칭이 이 모듈에서만 사용하는 경우에는 \_Private여야 합니다.
 
-- 예를 들어 Type과 함께 모듈의 이름이 너무 긴 경우
+- TypeAlias 주석은 버전 3.10 이상에서만 지원된다는 점에 유의하세요.
 
-  ```python
-  _ShortName = module_with_long_name.TypeWithLongName
-  ComplexMap = Mapping[str, List[Tuple[int, int]]]
-  ```
-
-- 다른 예로는 복잡한 중첩 유형과 함수의 복수 반환 변수(튜플)가 있습니다.
+```python
+from typing import TypeAlias
+_LossAndGradient: TypeAlias = tuple[tf.Tensor, tf.Tensor]
+ComplexTFMap: TypeAlias = Mapping[str, _LossAndGradient]
+```
 
 <a id="s3.19.7-ignoring-types"></a>
 <a id="s3.19.7-ignore"></a>
@@ -207,11 +239,21 @@ class MyClass:
 
 #### 3.19.8 내부 변수 작성
 
-- 내부 변수가 유추하기 어렵거나 불가능한 타입을 가지고 있는 경우, 다음과 같이 별도의 주석으로 설명할 수 있습니다.
+<a id="annotated-assignments"></a>
 
-```python
-a = SomeUndecoratedFunction()  # type: Foo
-```
+- [_Annotated Assignments_](#annotated-assignments): 내부 변수의 타입을 추론하기 어렵거나 불가능한 경우, 주석이 달린 할당으로 타입을 명시하세요. 변수 이름과 값 사이에 콜론과 타입을 사용합니다 (기본값이 있는 함수 인수와 동일한 방식으로).
+
+  ```python
+  a: Foo = SomeUndecoratedFunction()
+  ```
+
+<a id="type-comments"></a>
+
+- [_Type Comments_](#type-comments): 코드베이스에 여전히 남아 있을 수 있지만 (Python 3.6 이전에는 필요했음), 더 이상 `# type: <type name>` 주석을 줄 끝에 추가하지 마세요.
+
+  ```python
+  a = SomeUndecoratedFunction()  # type: Foo
+  ```
 
 <a id="s3.19.9-tuples-vs-lists"></a>
 <a id="s3.19.9-tuples"></a>
@@ -223,30 +265,38 @@ a = SomeUndecoratedFunction()  # type: Foo
 - 리스트는 함수의 반환 타입으로 일반적으로 사용된다.
 
 ```python
-a = [1, 2, 3]  # type: List[int]
-b = (1, 2, 3)  # type: Tuple[int, ...]
-c = (1, "2", 3.5)  # type: Tuple[int, str, float]
+a: list[int] = [1, 2, 3]
+b: tuple[int, ...] = (1, 2, 3)
+c: tuple[int, str, float] = (1, "2", 3.5)
 ```
 
 <a id="s3.19.10-typevars"></a>
 <a id="s3.19.10-type-var"></a>
+<a id="typevars"></a>
 
-#### 3.19.10 TypeVar
+#### 3.19.10 Type variables
 
 - 파이썬형 시스템은 일반성을 가지고 있다. 공장 기능인 TypeVar는 흔히 사용하는 방법입니다.
 
-- 파이선 Type에는 [generics](https://www.python.org/dev/peps/pep-0484/#generics)를 가지고 있습니다.
-- factory function `TypeVar`는 흔히 사용하는 방법입니다.
+- 파이선 Type에는 [generics](https://peps.python.org/pep-0484/#generics)를 가지고 있습니다.
+- `TypeVar`와 `ParamSpec`과 같은 타입 변수는 제너릭을 사용하는 일반적인 방법입니다.
 
   ```python
-  from typing import List, TypeVar
-  T = TypeVar("T")
+  from collections.abc import Callable
+  from typing import ParamSpec, TypeVar
+  _P = ParamSpec("_P")
+  _T = TypeVar("_T")
   ...
-  def next(l: List[T]) -> T:
-  return l.pop()
+  def next(l: list[_T]) -> _T:
+    return l.pop()
+  def print_when_called(f: Callable[_P, _T]) -> Callable[_P, _T]:
+    def inner(*args: _P.args, **kwargs: _P.kwargs) -> _T:
+      print("Function was called")
+      return f(*args, **kwargs)
+    return inner
   ```
 
-- TypeVar는 부자연스러울 수도 있습니다.
+- `TypeVar`는 부자연스러울 수도 있습니다.
 
   ```python
   AddableType = TypeVar("AddableType", int, float, str)
@@ -254,7 +304,7 @@ c = (1, "2", 3.5)  # type: Tuple[int, str, float]
   return a + b
   ```
 
-- `typing` 모듈의 흔히 미리 정의된 Type 변수는 `AnyStr`입니다. `bytes`, `unicode`일 수 있고 모두 같은 Type이어야 하는 여러 주석에 사용합니다.
+- `typing` 모듈의 흔히 미리 정의된 Type 변수는 `AnyStr`입니다. `bytes`, `str`일 수 있고 모두 같은 Type이어야 하는 여러 주석에 사용합니다.
 
   ```python
   from typing import AnyStr
@@ -264,48 +314,46 @@ c = (1, "2", 3.5)  # type: Tuple[int, str, float]
   raise ValueError()
   ```
 
-<a id="s3.19.11-string-types"></a>
-<a id="s3.19.11-strings"></a>
+- 타입 변수는 설명적인 이름을 가져야 합니다. 단, 다음 모든 기준을 충족하는 경우에는 예외입니다.
 
-#### 3.19.11 문자열 Type
+  - 외부에서 보이지 않는 경우
+  - 제약 조건이 없는 경우
 
-- String 주석에 대한 적절한 Type은 코드의 용도에 따라 달라집니다.
+  - 올바른 예
 
-- `str`을 사용하는 것을 선호하지만 `Text`도 허용됩니다. 둘 중 하나를 일관성 있게 사용하세요.
-- 바이너리 데이터를 다루는 코드의 경우 `bytes`를 사용하세요.
-- 텍스트 데이터(Python 2에서는 `str` 또는 `unicode`, Python3에서는 `str`)를 처리하는 Python 2 호환 코드의 경우 `Text`를 사용하세요.
+    ```python
+      _T = TypeVar("_T")
+      _P = ParamSpec("_P")
+      AddableType = TypeVar("AddableType", int, float, str)
+      AnyFunction = TypeVar("AnyFunction", bound=Callable)
+    ```
 
-```python
-def deals_with_text_data_in_py3(x: str) -> str:
-  ...
-def deals_with_binary_data(x: bytes) -> bytes:
-  ...
-def py2_compatible_text_data_processor(x: Text) -> Text:
-  ...
-```
+  - 부적절한 예
 
-- 일부 흔하지 않은 Python2 호환성 사례에서는 `Text` 대신 `str`이 의미가 있을 수 있으며 일반적으로 Python2와 Python3 간에 반환 유형이 동일하지 않을 때 호환성을 돕기 위해 사용됩니다.
-- Python3에는 `unicode`가 없으므로 절대 사용하지 마세요.
-- 이러한 불일치가 존재하는 이유는 `str`이 Python3와 Python2에서 다른 의미를 갖기 때문입니다.
+    ```python
+      T = TypeVar("T")
+      P = ParamSpec("P")
+      _T = TypeVar("_T", int, float, str)
+      _F = TypeVar("_F", bound=Callable)
+    ```
 
-- 부적절한 예
+<a id="s3.19.11-string-types"></a>
+<a id="s3.19.11-strings"></a>
+<a id="31911-string-types"></a>
+<a id="typing-strings"></a>
 
-```python
-def py2_code(x: str) -> unicode:
-  ...
-```
+#### 3.19.11 문자열 Type
 
-If the type can be either bytes or text, use `Union`, with the appropriate text
-type.
+> 새로운 코드에서는 `typing.Text`를 사용하지 마세요. 이는 Python 2/3 호환성을 위한 것입니다.
 
-```python
-from typing import Text, Union
-...
-def py3_only(x: Union[bytes, str]) -> Union[bytes, str]:
-  ...
-def py2_compatible(x: Union[bytes, Text]) -> Union[bytes, Text]:
-  ...
-```
+- 문자열/텍스트 데이터에는 `str`을 사용하세요. 이진 데이터와 관련된 코드에서는 `bytes`를 사용하세요.
+
+  ```python
+  def deals_with_text_data(x: str) -> str:
+    ...
+  def deals_with_binary_data(x: bytes) -> bytes:
+    ...
+  ```
 
 - 함수의 모든 string Type이 항상 동일한 경우(예, 반환 Type이 위의 코드에서 인자 Type과 동일한 경우) [AnyStr](#s3.19.10-type-var)를 사용하세요.
 
@@ -316,19 +364,31 @@ def py2_compatible(x: Union[bytes, Text]) -> Union[bytes, Text]:
 
 #### 3.19.12 Typing 추가
 
-- `typing` 모듈의 클래스는 항상 클래스 자체를 가져와야 합니다. `typing` 모듈에서 한 줄에 여러개의 특정 클래스를 가져올 수 있습니다.
+- `typing` 또는 `collections.abc` 모듈에서 정적 분석 및 타입 검사를 지원하기 위해 사용하는 심볼(타입, 함수, 상수 등)은 항상 심볼 자체를 임포트하세요.
+- 이렇게 하면 일반적인 주석이 더 간결해지고, 전 세계적으로 사용되는 타입 주석 관행에 맞출 수 있습니다.
+- `typing` 및 `collections.abc` 모듈에서 여러 개의 특정 심볼을 한 줄에서 명시적으로 임포트할 수 있습니다.
 
   ```python
-  from typing import Any, Dict, Optional
+  from collections.abc import Mapping, Sequence
+  from typing import Any, Generic, cast, TYPE_CHECKING
   ```
 
-- `typing`에서 가져오는 이러한 방식이 로컬 네임스페이스에 항목을 추가한다는 점에서, `typing`의 모든 이름은 키워드와 유사하게 취급되어야 하며, typing이든 아니든 Python 코드에 정의되어서는 안됩니다.
-- 모듈에 있는 Type과 기존 이름이 충돌하는 경우 `import x as y`를 사용해서 가져와야 합니다.
+- 이 방식으로 임포트하면 로컬 네임스페이스에 항목이 추가되므로, `typing` 또는 `collections.abc`의 이름은 키워드와 유사하게 취급되어야 하며, Python 코드에서 정의되지 않아야 합니다. 타입 여부와 관계없이 말입니다.
+- 모듈 내에서 타입과 기존 이름 간에 충돌이 있는 경우, `import x as y`를 사용하여 임포트하세요.
 
   ```python
   from typing import Any as AnyType
   ```
 
+- 가능한 경우, 주석으로 내장 타입을 사용하는 것이 좋습니다.
+- Prefer to use built-in types as annotations where available.
+- Python은 [PEP-585](https://peps.python.org/pep-0585/)를 통해 매개형 컨테이너 타입을 사용한 타입 주석을 지원하며, 이는 Python 3.9에서 도입되었습니다.
+
+  ```python
+  def generate_foo_scores(foo: set[str]) -> list[float]:
+    ...
+  ```
+
 <a id="typing-conditional-imports"></a>
 <a id="s3.19.13-conditional-imports"></a>
 
@@ -369,7 +429,7 @@ def f(x: "sketch.Sketch"): ...
   - 하지만 기술적으로 Circular 종속성을 유지하는 것은 가능하지만, 다양한 빌드 시스템은 다른 모듈에 의존해야 하기 때문에 그렇게 하도록 허락하지 않을 것입니다.
 
 - Circular 종속을 생성하는 모듈을 `Any`로 교체합니다.
-  - 의미있는 이름으로 [alias](#s3.19.6-aliases)를 지정하고 모듈의 실제 Type 이름을 사용하세요 (어떤 것의 어떤 속성인 Any).
+  - 의미있는 이름으로 [alias](#s3.19.6-aliases)를 지정하고 모듈의 실제 Type 이름을 사용하세요 (`Any`의 모든 속성은 `Any`입니다.).
   - Alias의 정의는 마지막으로 import와 한 줄로 분리합니다.
 
 ```python
@@ -386,31 +446,35 @@ def my_method(self, var: "some_mod.SomeType") -> None:
 
 #### 3.19.15 일반
 
-- 주석을 달때, 일반 Type를 지정하기를 선호하며 그렇지 [않을 때에는 `Any`로 가정합니다](https://www.python.org/dev/peps/pep-0484/#the-any-type).
+- 주석을 달때, 일반 Type를 지정하기를 선호하며 그렇지 [않을 때에는 `Any`로 가정합니다](https://peps.python.org/pep-0484/#the-any-type).
 
-```python
-def get_names(employee_ids: List[int]) -> Dict[int, Any]:
-  ...
-```
+  - 올바른 예
 
-```python
-# 두 개의 함수 모두 get_names(employee_ids: List[Any]) -> Dict[Any, Any]
-def get_names(employee_ids: list) -> Dict:
-  ...
+    ```python
+    def get_names(employee_ids: Sequence[int]) -> Mapping[int, str]:
+      ...
+    ```
 
-def get_names(employee_ids: List) -> Dict:
-  ...
-```
+  - 부적절한 예
+
+    ```python
+    # 이는 get_names(employee_ids: Sequence[Any]) -> Mapping[Any, Any]로 해석됩니다.
+    def get_names(employee_ids: Sequence) -> Mapping:
+    ```
 
 - 파라미터의 적합한 Type이 `Any`일 때, 명시적으로 표현되며, 많은 경우에 [`TypeVar`](#s3.19.10-type-var)가 더 적합할 수 있음을 기억해야합니다.
 
-```python
-def get_names(employee_ids: List[Any]) -> Dict[Any, str]:
-  """직원의 아이디를 이름과 연결하여 반환합니다."""
-```
+  - 부적절한 예
 
-```python
-T = TypeVar('T')
-def get_names(employee_ids: List[T]) -> Dict[T, str]:
-  """직원의 아이디를 이름과 연결하여 반환합니다."""
-```
+    ```python
+    def get_names(employee_ids: Sequence[Any]) -> Mapping[Any, str]:
+      """직원의 아이디를 이름과 연결하여 반환합니다."""
+    ```
+
+  - 올바른 예
+
+    ```python
+    _T = TypeVar('_T')
+    def get_names(employee_ids: Sequence[_T]) -> Mapping[_T, str]:
+      """직원의 아이디를 이름과 연결하여 반환합니다."""
+    ```
diff --git "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.2 \354\244\204 \352\270\270\354\235\264.md" "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.2 \354\244\204 \352\270\270\354\235\264.md"
index b359776..d43bf1c 100644
--- "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.2 \354\244\204 \352\270\270\354\235\264.md"	
+++ "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.2 \354\244\204 \352\270\270\354\235\264.md"	
@@ -10,10 +10,10 @@
     - 경로이름이나 URLs와 같은 공백을 포함하지 않는 긴 모듈수준 문자상수는 여러 줄에 나누어 기록하기 불편할 경우
     - Pylint 비활성화 주석문 (e.g.: `# pylint: disable=invalid-name`)
 
-- 3개 이상의 컨텍스트 매니저를 요구하는 `with` 구문을 제외하고 백슬래쉬(`\`) 를 이용한 문장연장을 사용하지 마세요.
-
-- Python의 [소/중/대 괄호 내부의 묵시적 라인결합](http://docs.python.org/reference/lexical_analysis.html#implicit-line-joining)을 사용하세요.
+- [명시적인 줄 연속](https://docs.python.org/3/reference/lexical_analysis.html#explicit-line-joining)을 위해 백슬래시를 사용하지 마세요.
+- 대신에 Python의 [소/중/대 괄호 내부의 묵시적 라인결합](http://docs.python.org/reference/lexical_analysis.html#implicit-line-joining)을 사용하세요.
 - 필요하다면, 구문 양쪽에 추가로 괄호를 더할 수 있습니다.
+- 이 규칙은 문자열 내에서 백슬래시로 이스케이프된 개행을 금지하지 않습니다(아래 [참조](#strings)).
 
   - 올바른 예
 
@@ -21,8 +21,29 @@
     foo_bar(self, width, height, color='black', design=None, x='foo',
     emphasis=None, highlight=0)
 
-        if (width == 0 and height == 0 and
-            color == 'red' and emphasis == 'strong'):
+    if (width == 0 and height == 0 and
+         color == 'red' and emphasis == 'strong'):
+     (bridge_questions.clarification_on
+      .average_airspeed_of.unladen_swallow) = 'African or European?'
+     with (
+         very_long_first_expression_function() as spam,
+         very_long_second_expression_function() as beans,
+         third_thing() as eggs,
+     ):
+       place_order(eggs, beans, spam, beans)
+    ```
+
+  - 부적절한 예
+
+    ```python
+    if width == 0 and height == 0 and \
+         color == 'red' and emphasis == 'strong':
+     bridge_questions.clarification_on \
+         .average_airspeed_of.unladen_swallow = 'African or European?'
+     with very_long_first_expression_function() as spam, \
+           very_long_second_expression_function() as beans, \
+           third_thing() as eggs:
+       place_order(eggs, beans, spam, beans)
     ```
 
 - 만약 리터럴 문자열을 한 줄에 표현하기 어렵다면 아래와 같이 괄호를 이용하여 묵시적 라인결합을 사용하세요.
@@ -32,53 +53,51 @@
       'long long long long long long string')
   ```
 
-- 주석의 경우 긴 URLs 들은 한줄에 표현하세요.
+- 가능한 가장 높은 구문 수준에서 줄을 나누는 것을 선호하세요. 줄을 두 번 나눠야 하는 경우, 두 번 모두 동일한 구문 수준에서 나누세요.
 
   - 올바른 예
 
     ```python
-    # See details at
-    # http://www.example.com/us/developer/documentation/api/content/v2.0/csv_file_name_extension_full_specification.html
+    bridgekeeper.answer(
+         name="Arthur", quest=questlib.find(owner="Arthur", perilous=True))
+     answer = (a_long_line().of_chained_methods()
+               .that_eventually_provides().an_answer())
+     if (
+         config is None
+         or 'editor.language' not in config
+         or config['editor.language'].use_spaces is False
+     ):
+       use_tabs()
     ```
 
   - 부적절한 예
 
     ```python
-    # See details at
-    # http://www.example.com/us/developer/documentation/api/content/\
-    # v2.0/csv_file_name_extension_full_specification.html
+    bridgekeeper.answer(name="Arthur", quest=questlib.find(
+        owner="Arthur", perilous=True))
+    answer = a_long_line().of_chained_methods().that_eventually_provides(
+        ).an_answer()
+    if (config is None or 'editor.language' not in config or config[
+        'editor.language'].use_spaces is False):
+      use_tabs()
     ```
 
-- 3줄 이상이 필요한 `with` 구문을 정의할 때는 백슬래쉬(`\`) 를 이용한 문장연장이 허용됩니다. 2줄인 경우 네스티드 `with`를 사용하세요
+- 주석의 경우 긴 URLs 들은 한줄에 표현하세요.
 
   - 올바른 예
 
     ```python
-        with very_long_first_expression_function() as spam, \
-            very_long_second_expression_function() as beans, \
-            third_thing() as eggs:
-            place_order(eggs, beans, spam, beans)
+    # See details at
+    # http://www.example.com/us/developer/documentation/api/content/v2.0/csv_file_name_extension_full_specification.html
     ```
 
   - 부적절한 예
 
     ```python
-    with VeryLongFirstExpressionFunction() as spam, \
-            VeryLongSecondExpressionFunction() as beans:
-        PlaceOrder(beans, spam)
-    ```
-
-  - 올바른 예
-
-    ```python
-    with very_long_first_expression_function() as spam:
-        with very_long_second_expression_function() as beans:
-            place_order(beans, spam)
+    # See details at
+    # http://www.example.com/us/developer/documentation/api/content/\
+    # v2.0/csv_file_name_extension_full_specification.html
     ```
 
 - 위의 예시에서 각 요소에 사용된 들여쓰기를 잘 기억하세요. 더 자세한 정보는 [들여쓰기](#s3.4-indentation) 챕터를 확인하세요.
-
-위에서 언급되지 않은 상황에서 한 줄의 길이가 80자를 초과함에도 
-[yapf](https://github.com/google/yapf/)
-오토포메터가 별다른 도움을 주지 못한다면 80자 이상 초과가 허용됩니다.  
-작성자는 상식적인 수준내에서 위 문서의 사항을 참고하여 줄을 분리하는것이 바람직합니다.
\ No newline at end of file
+- 위에서 언급되지 않은 상황에서 한 줄의 길이가 80자를 초과함에도 [Black](https://github.com/psf/black) 혹은 [Pyink](https://github.com/google/pyink) 오토포메터가 별다른 도움을 주지 못한다면 80자 이상 초과가 허용됩니다. 작성자는 상식적인 수준내에서 위 문서의 사항을 참고하여 줄을 분리하는것이 바람직합니다.
diff --git "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.4 \353\223\244\354\227\254\354\223\260\352\270\260.md" "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.4 \353\223\244\354\227\254\354\223\260\352\270\260.md"
index bacd85f..e2bed6c 100644
--- "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.4 \353\223\244\354\227\254\354\223\260\352\270\260.md"	
+++ "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.4 \353\223\244\354\227\254\354\223\260\352\270\260.md"	
@@ -4,26 +4,26 @@
 
 - 코드를 작성할 때 _4 칸_ 들여쓰기를 하세요.
 
-- 탭을 사용하거나 탭과 스페이스를 섞어서 사용하지 마세요.
-- 묵시적 문장연장의 경우 [line length](#s3.2-line-length) 섹션의 예시처럼 동일한 문장에 포함된 요소들을 수직정렬하거나 첫 열린괄호 이후로는 아무것도 없는 4 칸 hanging indent 를 적용하여야 합니다.
+- 탭을 절대 사용하지 마세요. 암시된 줄 연속은 래핑된 요소를 수직으로 정렬해야 하며([줄 길이 예제](#s3.2-line-length) 참조), 또는 4개의 공백을 사용하여 행을 들여쓰기 하세요.
+- 닫는 괄호(원, 대각선 또는 중괄호)는 표현식의 끝에 배치하거나 별도의 줄에 배치할 수 있지만, 이 경우 해당 여는 괄호와 같은 줄에 들여쓰기해야 합니다.
 
 - 올바른 예
 
   ```python
-  # Aligned with opening delimiter
+  # 여는 구분 기호와 정렬됨
   foo = long_function_name(var_one, var_two,
                           var_three, var_four)
   meal = (spam,
           beans)
 
-  # Aligned with opening delimiter in a dictionary
+  # 딕셔너리의 여는 구분 기호와 정렬됨
   foo = {
       'long_dictionary_key': value1 +
                              value2,
       ...
   }
 
-  # 4-space hanging indent; nothing on first line
+  # 4칸 공백의 걸쳐서 들여쓰기, 첫 번째 줄에는 아무것도 없음
   foo = long_function_name(
       var_one, var_two, var_three,
       var_four)
@@ -31,7 +31,16 @@
       spam,
       beans)
 
-  # 4-space hanging indent in a dictionary
+  # 4칸 공백의 걸쳐서 들여쓰기; 첫 번째 줄에는 아무것도 없음, 닫는 괄호는 새 줄에 배치
+  foo = long_function_name(
+      var_one, var_two, var_three,
+      var_four
+  )
+  meal = (
+      spam,
+      beans,
+  )
+  # 딕셔너리에서 4칸 공백의 걸쳐서 들여쓰기
   foo = {
       'long_dictionary_key':
           long_dictionary_value,
@@ -42,18 +51,18 @@
 - 부적절한 예
 
   ```python
-  # Stuff on first line forbidden
+  # 첫 번째 줄에 내용이 있어서는 안 됩니다.
   foo = long_function_name(var_one, var_two,
       var_three, var_four)
   meal = (spam,
       beans)
 
-  # 2-space hanging indent forbidden
+  # 2칸 공백의 걸쳐서 들여쓰기는 금지됩니다.
   foo = long_function_name(
       var_one, var_two, var_three,
       var_four)
 
-  # No hanging indent in a dictionary
+  # 딕셔너리에서는 걸쳐서 들여쓰기를 사용하지 않습니다.
   foo = {
       'long_dictionary_key':
       long_dictionary_value,
@@ -65,8 +74,8 @@
 
 #### 3.4.1 원소 나열 시 후행 쉼표
 
-- 여러 원소를 나열할 때 후행 쉼표는 `]`, `)`, `}` 와 같이 컨테이너를 닫는 토큰이 마지막 원소와 같은 줄에 있지 않을 때만 권장됩니다.
-- 또한 후행 쉼표의 존재 여부는 파이썬 코드 오토-포메터 [YAPF](https://pypi.org/project/yapf/) 가 컨테이너의 원소를 한 줄에 하나씩 `,` 기호를 붙여 자동 정렬하도록 지시하는 힌트로도 사용됩니다.
+- 후행 쉼표는 시퀀스의 요소에서 닫는 구문 기호 `]`, `)`, 또는 `}`가 마지막 요소와 같은 줄에 나타나지 않는 경우와 단일 요소를 가진 튜플에 대해서만 권장됩니다.
+- 후행 쉼표의 존재는 Python 코드 자동 포맷터인 [Black](https://github.com/psf/black)이나 [Pyink](https://github.com/google/pyink)에게 마지막 요소 뒤에 `,`가 있을 때 항목의 컨테이너를 한 줄에 하나의 항목씩 자동으로 포맷하도록 지시하는 힌트로도 사용됩니다.
 
 - 올바른 예
 
@@ -87,6 +96,5 @@
           0,
           1,
           4,
-          6
-          ]
+          6,]
   ```
diff --git "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.5 \353\271\210 \354\244\204.md" "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.5 \353\271\210 \354\244\204.md"
index 7097185..47435be 100644
--- "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.5 \353\271\210 \354\244\204.md"	
+++ "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.5 \353\271\210 \354\244\204.md"	
@@ -3,7 +3,7 @@
 ### 3.5 Blank Lines
 
 - 함수 선언이든 객체 선언이든 최상위 선언문과는 2개의 빈 줄을 사이에 두어야 합니다.
-- 각 메소드 선언 또는 `class` 줄과 젓 번째 메소드 선언 시 그 사이에는 한 개의 빈 줄이 있어야 합니다.
+- 각 메소드 선언 또는 `class`의 docstring 줄과 젓 번째 메소드 선언 시 그 사이에는 한 개의 빈 줄이 있어야 합니다.
 - `def` 줄 이후에는 빈 줄이 없어야 합니다.
 - 함수와 메소드 사이에 개발자의 판단하에 적절하게 한 개의 빈 줄을 사용하세요.
 
diff --git "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.7 Shebang_Line.md" "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.7 Shebang_Line.md"
index d8d5885..7f3e8db 100644
--- "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.7 Shebang_Line.md"	
+++ "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.7 Shebang_Line.md"	
@@ -3,7 +3,7 @@
 ### 3.7 Shebang Line
 
 - 대부분의 `.py` 파일은 `#!` 로 시작하지 않아도 됩니다.
-- [PEP-394](https://www.python.org/dev/peps/pep-0394/)에 따라 프로그램의 메인 파일 첫 줄에 `#!/usr/bin/env python3` (virtualenvs 지원) 또는 `#!/usr/bin/python3`사용하면 됩니다.
+- [PEP-394](https://peps.python.org/pep-0394/)에 따라 프로그램의 메인 파일 첫 줄에 `#!/usr/bin/env python3` (virtualenvs 지원) 또는 `#!/usr/bin/python3`사용하면 됩니다.
 
 - 이 줄은 파이썬 파일을 import 할때는 무시되지만 실행 될때는 커널이 어떤 파이썬 인터프리터를 사용해야 하는지 알려줍니다.
 - 따라서 직접 실행될 파일에 기록하는것이 적합합니다.
diff --git "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.8 \354\243\274\354\204\235\352\263\274 docstring.md" "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.8 \354\243\274\354\204\235\352\263\274 docstring.md"
index 480875d..efb1916 100644
--- "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.8 \354\243\274\354\204\235\352\263\274 docstring.md"	
+++ "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/3.8 \354\243\274\354\204\235\352\263\274 docstring.md"	
@@ -11,7 +11,7 @@
 - 파이썬은 코드를 문서화 할 때 _docstring_ 을 사용합니다.
 - docstring 은 패키지, 모듈, 클래스나 함수의 첫번째 선언되는 문자열입니다.
 - 이 문자열은 `pydoc` 이 사용하는 `__doc__` 멤버 오브젝트에서 자동으로 추출될 수 있습니다. (여러분의 모듈에서 `pydoc` 를 실행 후 결과를 확인해보세요)
-- [PEP257](https://www.google.com/url?sa=D&q=http://www.python.org/dev/peps/pep-0257/) 에 따라 docstring 을 시작하거나 끝낼 때는 `"""` 를 사용하세요.
+- [PEP257](https://peps.python.org/pep-0257/) 에 따라 docstring 을 시작하거나 끝낼 때는 `"""` 를 사용하세요.
 - docstring은 마침표, 물음표, 느낌표로 끝나는 요약줄(한 줄)로 시작하여야 하며 한 줄의 공백을 두고 내용을 담고있는 나머지 docstring 이 이어져야 합니다.
 - 또한 내용을 담고있는 docstring 은 `"""` 와 같은 커서위치에서 시작하여야 합니다.
 
@@ -19,36 +19,70 @@
 
 #### 3.8.2 Modules
 
-- 모든 파일은 라이센스 보일러 플레이트를 가지고 있어야 합니다.
 - 프로젝트에 알맞는 라이센스 보일러 플레이트를 선택하세요. (예를 들면, Apache 2.0, BSD, LGPL, GPL)
+- 모든 파일은 라이센스 보일러 플레이트를 가지고 있어야 합니다.
+
+  ```python
+  """모듈이나 프로그램에 대한 한 줄 요약으로, 마침표로 끝나야 합니다.
+
+  한 줄을 비워두세요. 이 docstring의 나머지 부분에는 모듈이나 프로그램에
+  대한 전반적인 설명이 포함되어야 합니다. 선택적으로, 내보낸 클래스와
+  함수에 대한 간단한 설명 및/또는 사용 예시도 포함될 수 있습니다.
+
+  전형적인 사용 예시:
+
+    foo = ClassFoo()
+    bar = foo.FunctionBar()
+  """
+  ```
+
+<a id="s3.8.2.1-test-modules"></a>
+<a id="test-docs"></a>
+
+##### 3.8.2.1 Test modules
+
+- 테스트 파일의 모듈 수준 docstring은 필수는 아닙니다.
+- 추가적인 정보를 제공할 필요가 있는 경우에만 포함해야 합니다.
+- 예를 들면, 테스트를 실행하는 방법에 대한 구체적인 내용, 특이한 설정 패턴에 대한 설명, 외부 환경에 대한 의존성 등이 포함될 수 있습니다.
+
+```python
+"""이 Blaze 테스트는 golden 파일을 사용합니다.
+`google3` 디렉토리에서
+`blaze run //foo/bar:foo_test -- --update_golden_files` 명령어를 실행하여
+이러한 파일을 업데이트할 수 있습니다.
+"""
+```
+
+- 새로운 정보를 제공하지 않는 docstring은 사용하지 말아야 합니다.
+
+```python
+"""Tests for foo.bar."""
+```
 
 <a id="s3.8.3-functions-and-methods"></a>
 
 #### 3.8.3 Functions and Methods
 
-- 이 섹션에서 "함수"는 메소드, 함수 또는 제너레이터를 의미합니다.
+- 이 섹션에서 ‘function’은 메소드, 함수, 제너레이터 또는 속성을 의미합니다.
 
-- 아래의 조건을 만족하지 않는 이상 함수는 반드시 docstring 을 가지고 있어야 합니다.
+- 다음 중 하나 이상의 속성을 가진 모든 함수에는 docstring이 필수입니다.
 
-  - 외부에서 보이지 않음
-  - 매우 짧음
-  - 잘 알려져 있음
+  - 공개 API의 일부인 경우
+  - 비교적 큰 경우
+  - 직관적이지 않은 로직을 가진 경우
 
-- docstring 은 직접 함수의 코드를 읽어보지 않더라도 충분히 함수를 호출하는 코드를 작성 할 수 있을만큼 정보를 제공해야 합니다.
-- docstring은 함수의 호출방식이나 시멘틱등을 반드시 기술하되 함수의 사용함에 있어 영항을 주지 않는 한 함수 내부의 상세한 구현방법은 기술하지 아니합니다
-- 예를들어 한 함수가 구동과정에서 인자로 받은 변수 하나를 변형시킨다면 이는 docstring에 기술되어야 합니다.
-- 이외 함수의 호출과 상관이 없는 자잘하지만 중요한 항목들은 함수 내 docstring 보단 주석으로 기록하는 것이 좋습니다
-- docstring 은 (`"""Fetches rows from a Bigtable."""`) 처럼 _설명조_ 를 사용하여야 하며 (`"""Fetch rows from a Bigtable."""`) 처럼 _명령조_ 를 사용하지 않아야 합니다.
-- docstring 은 함수의 구현방식이 아닌 호출 방법과 의미를 기술해야 합니다.
-- 복잡한 코드의 경우 docstring 을 사용하는 것보다 코드 한 줄마다 주석을 첨가하는 것이 더 알맞습니다.
+- docstring은 함수의 코드를 읽지 않고도 함수 호출을 작성할 수 있을 만큼 충분한 정보를 제공해야 합니다.
+- docstring은 함수의 호출 구문과 의미를 설명해야 하며, 일반적으로 구현 세부 사항은 포함하지 않아야 하지만, 이러한 세부 사항이 함수 사용 방법에 중요하다면 예외입니다.
+- 예를 들어, 인자를 사이드 임펙트로 변경하는 함수는 그 점을 docstring에 명시해야 합니다.
 
-- 다른 기본 객체의 메소드를 오버라이드하는 메소드는 `"""See base class."""` 처럼 개발자가 작성한 docstring 에 오버라이드된 메소드가 있음을 알려주는 docstring 을 전달 할 수도 있습니다.
-- 그 이유는 같은 문서를 여러곳에서 반복하는 것을 방지하기 위함입니다.
-- 하지만 오버라이딩된 메소드가 기존의 메소드와 확연하게 다른 동작방식을 가지고 있거나 세부적인 내용(e.g., 잠재적인 부작용 등)이 존재한다면 적어도 그러한 차이점들은 docstring 을 통해 기록되어야 합니다.
+- 그렇지 않으면, 호출자에게 중요하지 않은 함수 구현의 미묘하지만 중요한 세부 사항은 함수의 docstring보다는 코드 옆에 주석으로 표현하는 것이 좋습니다.
+- docstring은 서술형(`"""Fetches rows from a Bigtable."""`) 또는 명령형(`"""Fetch rows from a Bigtable."""`) 스타일일 수 있지만, 파일 내에서 스타일은 일관되게 유지해야 합니다.
+- `@property` 속성의 docstring은 속성이나 [함수 인자](#doc-function-args)의 docstring과 같은 스타일을 사용해야 합니다 (`"""The Bigtable path."""` 대신에 `"""Returns the Bigtable path."""`).
 
-- 다만 함수의 몇가지 특정 부분들은 아래처럼 별도의 특별섹션으로 기록해야 합니다.
-- 각 섹션은 표제로 시작하며 콜론으로 끝맺습니다.
-- 각 섹션은 표제를 제외하고 2칸 들여쓰기를 합니다.
+- 함수의 특정 측면은 아래에 나열된 특별한 섹션에서 문서화해야 합니다.
+- 각 섹션은 콜론으로 끝나는 제목 행으로 시작합니다.
+- 제목을 제외한 모든 섹션은 2칸 또는 4칸 공백의 걸쳐서 들여쓰기를 유지해야 합니다 (파일 내에서 일관되게 유지).
+- 함수의 이름과 시그니처가 충분히 정보를 제공하여 한 줄의 docstring으로 적절히 설명할 수 있는 경우, 이러한 섹션은 생략할 수 있습니다.
 
 <a id="doc-function-args"></a>
 
@@ -63,12 +97,13 @@
 
 ##### [_Returns:_ (제너레이터에는 _Yields:_)](#doc-function-returns)
 
-- 반환값의 자료형과 의미를 기록합니다. 만약 함수가 None만을 반환한다면 이 섹션은 필요없습니다.
-- 또한 만약 docstring이 Returns 나 Yields로 시작하거나(e.g. `"""Returns row from Bigtable as a tuple of strings."""`) 충분한 설명이 제공된다면 생략 될 수 있습니다.
-- Tuple 반환 값을 개별 이름이 있는 여러 반환 값인 것처럼 자주 문서화하는 'NumPy style' ([example](http://numpy.org/doc/stable/reference/generated/numpy.linalg.qr.html))을 모방하지 마세요. (Tuple를 언급하지 않습니다.)
-- 대신, 다음과 같은 반환값으로 기술하세요.
-  - "Returns a tuple (mat_a, mat_b), where mat_a is ..., and ...".
-- Docstring의 보조 이름은 함수 본문에 사용된 내부 이름과 반드시 일치할 필요는 없습니다. (해당 이름은 API의 일부가 아니기 때문입니다.)
+- 반환 값의 의미를 설명하고, 타입 어노테이션에서 제공하지 않는 타입 정보도 포함해야 합니다.
+- 함수가 None만 반환하는 경우, 이 섹션은 필요하지 않습니다.
+- docstring이 "Return", "Returns", "Yield", "Yields"로 시작하고(e.g. `"""Returns row from Bigtable as a tuple of strings."""`), 첫 번째 문장이 반환 값을 설명하기에 충분할 경우, 이 섹션은 생략될 수 있습니다.
+- 이전의 'NumPy 스타일'을 모방하지 마세요. ([example](https://numpy.org/doc/1.24/reference/generated/numpy.linalg.qr.html)) 이 스타일은 종종 튜플 반환 값을 여러 개의 개별 반환 값처럼 각각의 이름으로 문서화했습니다. (튜플이라는 점을 언급하지 않고)
+- 대신, 반환 값을 다음과 같이 설명하세요: "Returns: A tuple (mat_a, mat_b), where mat_a is ..., and ...".
+- docstring에서 사용되는 설명용 이름은 함수 본문에서 사용되는 내부 이름과 반드시 일치할 필요는 없습니다 (내부 이름은 API의 일부가 아니기 때문입니다)
+- 함수가 `yield`를 사용하는 경우(즉, 제너레이터인 경우), `Yields:` 섹션에서는 호출 결과로 반환되는 제너레이터 객체가 아니라, `next()`에 의해 반환되는 객체를 문서화해야 합니다.
 
 <a id="doc-function-raises"></a>
 
@@ -79,10 +114,11 @@
 - 명시된 API가 docstring을 위반했을 될 경우, 예외를 문서화하지 않습니다. (왜냐하면 이것은 역설적으로 API의 API를 위반하는 행동을 만들 수 있기 때문이다.)
 
   ```python
-  def fetch_smalltable_rows(table_handle: smalltable.Table,
-                          keys: Sequence[Union[bytes, str]],
-                          require_all_keys: bool = False,
-  ) -> Mapping[bytes, Tuple[str, ...]]:
+  def fetch_smalltable_rows(
+      table_handle: smalltable.Table,
+      keys: Sequence[bytes | str],
+      require_all_keys: bool = False,
+  ) -> Mapping[bytes, tuple[str, ...]]:
     """Fetches rows from a Smalltable.
 
     Retrieves rows pertaining to the given keys from the Table instance
@@ -116,10 +152,11 @@
 - 마찬가지로, 줄 바꿈이 있는 `Args:`도 허용합니다.
 
   ```python
-  def fetch_smalltable_rows(table_handle: smalltable.Table,
-                            keys: Sequence[Union[bytes, str]],
-                            require_all_keys: bool = False,
-  ) -> Mapping[bytes, Tuple[str, ...]]:
+  def fetch_smalltable_rows(
+      table_handle: smalltable.Table,
+      keys: Sequence[bytes | str],
+      require_all_keys: bool = False,
+  ) -> Mapping[bytes, tuple[str, ...]]:
       """Fetches rows from a Smalltable.
 
       Retrieves rows pertaining to the given keys from the Table instance
@@ -152,19 +189,51 @@
       """
   ```
 
+<a id="s3.8.3.1-overridden-methods"></a>
+<a id="overridden-method-docs"></a>
+
+##### 3.8.3.1 Overridden Methods
+
+- 기본 클래스의 메서드를 오버라이드하는 메서드는 [`@override`](https://typing-extensions.readthedocs.io/en/latest/#override) 데코레이터(`typing_extensions` 또는 `typing` 모듈에서 제공)를 명시적으로 사용하는 경우 docstring이 필요하지 않습니다.
+- 단, 오버라이딩된 메서드의 동작이 기본 메서드의 계약을 실질적으로 개선하거나, 추가적인 사이드 임펙트 등을 문서화해야 하는 경우에는, 그러한 차이점이 최소한 포함된 docstring이 오버라이딩 메서드에 필요합니다.
+
+  ```python
+  from typing_extensions import override
+  class Parent:
+    def do_something(self):
+      """Parent method, includes docstring."""
+  # 자식 클래스, 오버라이드로 주석이 달린 메서드.
+  class Child(Parent):
+    @override
+    def do_something(self):
+      pass
+  ```
+
+  ```python
+  # 자식 클래스에서 @override 데코레이터가 없는 경우, docstring이 필요합니다.
+  class Child(Parent):
+    def do_something(self):
+      pass
+  # docstring이 단순한 경우, @override만으로도 문서가 기본 클래스에 있음을 표시할 수 있습니다.
+  class Child(Parent):
+    @override
+    def do_something(self):
+      """See base class."""
+  ```
+
 <a id="s3.8.4-comments-in-classes"></a>
 
 #### 3.8.4 Classes
 
 - 클래스는 선언 바로 아래에 해당 클래스를 설명하는 docstring 를 가지고 있어야 합니다.
-- 만약 클래스가 public attributes 를 가지고 있다면 [function's `Args`](#doc-function-args) 섹션과 같은 형식을 사용해 `Attributes` 섹션을 작성해야 합니다.
+- [properties](#properties)을 제외한 공개 속성은 `Attributes` 섹션에서 문서화해야 하며, [함수의 `Args`](#doc-function-args) 섹션과 동일한 형식을 따라야 합니다.
 
 ```python
 class SampleClass:
     """Summary of class here.
 
-    Longer class information....
-    Longer class information....
+    Longer class information...
+    Longer class information...
 
     Attributes:
         likes_spam: A boolean indicating if we like SPAM or not.
@@ -172,14 +241,42 @@ class SampleClass:
     """
 
     def __init__(self, likes_spam: bool = False):
-        """Inits SampleClass with blah."""
+        """Initializes the instance based on spam preference.
+        Args:
+          likes_spam: Defines if instance exhibits this preference.
+        """
         self.likes_spam = likes_spam
         self.eggs = 0
 
-    def public_method(self):
-        """Performs operation blah."""
+    @property
+    def butter_sticks(self) -> int:
+        """The number of butter sticks we have."""
 ```
 
+- 모든 클래스의 docstring은 클래스 인스턴스가 무엇을 나타내는지를 설명하는 한 줄 요약으로 시작해야 합니다. 이는 `Exception`의 서브클래스도 예외가 무엇을 나타내는지를 설명해야 하며, 발생할 수 있는 컨텍스트에 대해서는 설명하지 않아야 함을 의미합니다. 클래스의 docstring은 클래스가 클래스라는 등의 불필요한 정보를 반복해서는 안 됩니다.
+
+- 올바른 예
+
+  ```python
+  class CheeseShopAddress:
+    """The address of a cheese shop.
+    ...
+    """
+  class OutOfCheeseError(Exception):
+    """No more cheese is available."""
+  ```
+
+- 부적절한 예
+
+  ```python
+  class CheeseShopAddress:
+    """Class that describes the address of a cheese shop.
+    ...
+    """
+  class OutOfCheeseError(Exception):
+    """Raised when no more cheese is available."""
+  ```
+
 <a id="s3.8.5-block-and-inline-comments"></a>
 <a id="s3.8.5-comments-in-block-and-inline"></a>
 
diff --git "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/ReadMe.md" "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/ReadMe.md"
index 41c38b2..2a79363 100644
--- "a/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/ReadMe.md"	
+++ "b/Google Python Style Guide/3. Python \354\212\244\355\203\200\354\235\274 \352\267\234\354\271\231/ReadMe.md"	
@@ -17,10 +17,10 @@
     - 경로이름이나 URLs와 같은 공백을 포함하지 않는 긴 모듈수준 문자상수는 여러 줄에 나누어 기록하기 불편할 경우
     - Pylint 비활성화 주석문 (e.g.: `# pylint: disable=invalid-name`)
 
-- 3개 이상의 컨텍스트 매니저를 요구하는 `with` 구문을 제외하고 백슬래쉬(`\`) 를 이용한 문장연장을 사용하지 마세요.
-
-- Python의 [소/중/대 괄호 내부의 묵시적 라인결합](http://docs.python.org/reference/lexical_analysis.html#implicit-line-joining)을 사용하세요.
+- [명시적인 줄 연속](https://docs.python.org/3/reference/lexical_analysis.html#explicit-line-joining)을 위해 백슬래시를 사용하지 마세요.
+- 대신에 Python의 [소/중/대 괄호 내부의 묵시적 라인결합](http://docs.python.org/reference/lexical_analysis.html#implicit-line-joining)을 사용하세요.
 - 필요하다면, 구문 양쪽에 추가로 괄호를 더할 수 있습니다.
+- 이 규칙은 문자열 내에서 백슬래시로 이스케이프된 개행을 금지하지 않습니다(아래 [참조](#strings)).
 
   - 올바른 예
 
@@ -28,8 +28,29 @@
     foo_bar(self, width, height, color='black', design=None, x='foo',
     emphasis=None, highlight=0)
 
-        if (width == 0 and height == 0 and
-            color == 'red' and emphasis == 'strong'):
+    if (width == 0 and height == 0 and
+         color == 'red' and emphasis == 'strong'):
+     (bridge_questions.clarification_on
+      .average_airspeed_of.unladen_swallow) = 'African or European?'
+     with (
+         very_long_first_expression_function() as spam,
+         very_long_second_expression_function() as beans,
+         third_thing() as eggs,
+     ):
+       place_order(eggs, beans, spam, beans)
+    ```
+
+  - 부적절한 예
+
+    ```python
+    if width == 0 and height == 0 and \
+         color == 'red' and emphasis == 'strong':
+     bridge_questions.clarification_on \
+         .average_airspeed_of.unladen_swallow = 'African or European?'
+     with very_long_first_expression_function() as spam, \
+           very_long_second_expression_function() as beans, \
+           third_thing() as eggs:
+       place_order(eggs, beans, spam, beans)
     ```
 
 - 만약 리터럴 문자열을 한 줄에 표현하기 어렵다면 아래와 같이 괄호를 이용하여 묵시적 라인결합을 사용하세요.
@@ -39,56 +60,55 @@
       'long long long long long long string')
   ```
 
-- 주석의 경우 긴 URLs 들은 한줄에 표현하세요.
+- 가능한 가장 높은 구문 수준에서 줄을 나누는 것을 선호하세요. 줄을 두 번 나눠야 하는 경우, 두 번 모두 동일한 구문 수준에서 나누세요.
 
   - 올바른 예
 
     ```python
-    # See details at
-    # http://www.example.com/us/developer/documentation/api/content/v2.0/csv_file_name_extension_full_specification.html
+    bridgekeeper.answer(
+         name="Arthur", quest=questlib.find(owner="Arthur", perilous=True))
+     answer = (a_long_line().of_chained_methods()
+               .that_eventually_provides().an_answer())
+     if (
+         config is None
+         or 'editor.language' not in config
+         or config['editor.language'].use_spaces is False
+     ):
+       use_tabs()
     ```
 
   - 부적절한 예
 
     ```python
-    # See details at
-    # http://www.example.com/us/developer/documentation/api/content/\
-    # v2.0/csv_file_name_extension_full_specification.html
+    bridgekeeper.answer(name="Arthur", quest=questlib.find(
+        owner="Arthur", perilous=True))
+    answer = a_long_line().of_chained_methods().that_eventually_provides(
+        ).an_answer()
+    if (config is None or 'editor.language' not in config or config[
+        'editor.language'].use_spaces is False):
+      use_tabs()
     ```
 
-- 3줄 이상이 필요한 `with` 구문을 정의할 때는 백슬래쉬(`\`) 를 이용한 문장연장이 허용됩니다. 2줄인 경우 네스티드 `with`를 사용하세요
+- 주석의 경우 긴 URLs 들은 한줄에 표현하세요.
 
   - 올바른 예
 
     ```python
-        with very_long_first_expression_function() as spam, \
-            very_long_second_expression_function() as beans, \
-            third_thing() as eggs:
-            place_order(eggs, beans, spam, beans)
+    # See details at
+    # http://www.example.com/us/developer/documentation/api/content/v2.0/csv_file_name_extension_full_specification.html
     ```
 
   - 부적절한 예
 
     ```python
-    with VeryLongFirstExpressionFunction() as spam, \
-            VeryLongSecondExpressionFunction() as beans:
-        PlaceOrder(beans, spam)
-    ```
-
-  - 올바른 예
-
-    ```python
-    with very_long_first_expression_function() as spam:
-        with very_long_second_expression_function() as beans:
-            place_order(beans, spam)
+    # See details at
+    # http://www.example.com/us/developer/documentation/api/content/\
+    # v2.0/csv_file_name_extension_full_specification.html
     ```
 
 - 위의 예시에서 각 요소에 사용된 들여쓰기를 잘 기억하세요. 더 자세한 정보는 [들여쓰기](#s3.4-indentation) 챕터를 확인하세요.
+- 위에서 언급되지 않은 상황에서 한 줄의 길이가 80자를 초과함에도 [Black](https://github.com/psf/black) 혹은 [Pyink](https://github.com/google/pyink) 오토포메터가 별다른 도움을 주지 못한다면 80자 이상 초과가 허용됩니다. 작성자는 상식적인 수준내에서 위 문서의 사항을 참고하여 줄을 분리하는것이 바람직합니다.
 
-위에서 언급되지 않은 상황에서 한 줄의 길이가 80자를 초과함에도 
-[yapf](https://github.com/google/yapf/)
-오토포메터가 별다른 도움을 주지 못한다면 80자 이상 초과가 허용됩니다.  
-작성자는 상식적인 수준내에서 위 문서의 사항을 참고하여 줄을 분리하는것이 바람직합니다.
 ---
 <a id="s3.3-parentheses"></a>
 
@@ -135,26 +155,26 @@
 
 - 코드를 작성할 때 _4 칸_ 들여쓰기를 하세요.
 
-- 탭을 사용하거나 탭과 스페이스를 섞어서 사용하지 마세요.
-- 묵시적 문장연장의 경우 [line length](#s3.2-line-length) 섹션의 예시처럼 동일한 문장에 포함된 요소들을 수직정렬하거나 첫 열린괄호 이후로는 아무것도 없는 4 칸 hanging indent 를 적용하여야 합니다.
+- 탭을 절대 사용하지 마세요. 암시된 줄 연속은 래핑된 요소를 수직으로 정렬해야 하며([줄 길이 예제](#s3.2-line-length) 참조), 또는 4개의 공백을 사용하여 행을 들여쓰기 하세요.
+- 닫는 괄호(원, 대각선 또는 중괄호)는 표현식의 끝에 배치하거나 별도의 줄에 배치할 수 있지만, 이 경우 해당 여는 괄호와 같은 줄에 들여쓰기해야 합니다.
 
 - 올바른 예
 
   ```python
-  # Aligned with opening delimiter
+  # 여는 구분 기호와 정렬됨
   foo = long_function_name(var_one, var_two,
                           var_three, var_four)
   meal = (spam,
           beans)
 
-  # Aligned with opening delimiter in a dictionary
+  # 딕셔너리의 여는 구분 기호와 정렬됨
   foo = {
       'long_dictionary_key': value1 +
                              value2,
       ...
   }
 
-  # 4-space hanging indent; nothing on first line
+  # 4칸 공백의 걸쳐서 들여쓰기, 첫 번째 줄에는 아무것도 없음
   foo = long_function_name(
       var_one, var_two, var_three,
       var_four)
@@ -162,7 +182,16 @@
       spam,
       beans)
 
-  # 4-space hanging indent in a dictionary
+  # 4칸 공백의 걸쳐서 들여쓰기; 첫 번째 줄에는 아무것도 없음, 닫는 괄호는 새 줄에 배치
+  foo = long_function_name(
+      var_one, var_two, var_three,
+      var_four
+  )
+  meal = (
+      spam,
+      beans,
+  )
+  # 딕셔너리에서 4칸 공백의 걸쳐서 들여쓰기
   foo = {
       'long_dictionary_key':
           long_dictionary_value,
@@ -173,18 +202,18 @@
 - 부적절한 예
 
   ```python
-  # Stuff on first line forbidden
+  # 첫 번째 줄에 내용이 있어서는 안 됩니다.
   foo = long_function_name(var_one, var_two,
       var_three, var_four)
   meal = (spam,
       beans)
 
-  # 2-space hanging indent forbidden
+  # 2칸 공백의 걸쳐서 들여쓰기는 금지됩니다.
   foo = long_function_name(
       var_one, var_two, var_three,
       var_four)
 
-  # No hanging indent in a dictionary
+  # 딕셔너리에서는 걸쳐서 들여쓰기를 사용하지 않습니다.
   foo = {
       'long_dictionary_key':
       long_dictionary_value,
@@ -196,8 +225,8 @@
 
 #### 3.4.1 원소 나열 시 후행 쉼표
 
-- 여러 원소를 나열할 때 후행 쉼표는 `]`, `)`, `}` 와 같이 컨테이너를 닫는 토큰이 마지막 원소와 같은 줄에 있지 않을 때만 권장됩니다.
-- 또한 후행 쉼표의 존재 여부는 파이썬 코드 오토-포메터 [YAPF](https://pypi.org/project/yapf/) 가 컨테이너의 원소를 한 줄에 하나씩 `,` 기호를 붙여 자동 정렬하도록 지시하는 힌트로도 사용됩니다.
+- 후행 쉼표는 시퀀스의 요소에서 닫는 구문 기호 `]`, `)`, 또는 `}`가 마지막 요소와 같은 줄에 나타나지 않는 경우와 단일 요소를 가진 튜플에 대해서만 권장됩니다.
+- 후행 쉼표의 존재는 Python 코드 자동 포맷터인 [Black](https://github.com/psf/black)이나 [Pyink](https://github.com/google/pyink)에게 마지막 요소 뒤에 `,`가 있을 때 항목의 컨테이너를 한 줄에 하나의 항목씩 자동으로 포맷하도록 지시하는 힌트로도 사용됩니다.
 
 - 올바른 예
 
@@ -218,8 +247,7 @@
           0,
           1,
           4,
-          6
-          ]
+          6,]
   ```
 
 ---
@@ -228,7 +256,7 @@
 ### 3.5 Blank Lines
 
 - 함수 선언이든 객체 선언이든 최상위 선언문과는 2개의 빈 줄을 사이에 두어야 합니다.
-- 각 메소드 선언 또는 `class` 줄과 젓 번째 메소드 선언 시 그 사이에는 한 개의 빈 줄이 있어야 합니다.
+- 각 메소드 선언 또는 `class`의 docstring 줄과 젓 번째 메소드 선언 시 그 사이에는 한 개의 빈 줄이 있어야 합니다.
 - `def` 줄 이후에는 빈 줄이 없어야 합니다.
 - 함수와 메소드 사이에 개발자의 판단하에 적절하게 한 개의 빈 줄을 사용하세요.
 
@@ -366,7 +394,7 @@
 ### 3.7 Shebang Line
 
 - 대부분의 `.py` 파일은 `#!` 로 시작하지 않아도 됩니다.
-- [PEP-394](https://www.python.org/dev/peps/pep-0394/)에 따라 프로그램의 메인 파일 첫 줄에 `#!/usr/bin/env python3` (virtualenvs 지원) 또는 `#!/usr/bin/python3`사용하면 됩니다.
+- [PEP-394](https://peps.python.org/pep-0394/)에 따라 프로그램의 메인 파일 첫 줄에 `#!/usr/bin/env python3` (virtualenvs 지원) 또는 `#!/usr/bin/python3`사용하면 됩니다.
 
 - 이 줄은 파이썬 파일을 import 할때는 무시되지만 실행 될때는 커널이 어떤 파이썬 인터프리터를 사용해야 하는지 알려줍니다.
 - 따라서 직접 실행될 파일에 기록하는것이 적합합니다.
@@ -385,7 +413,7 @@
 - 파이썬은 코드를 문서화 할 때 _docstring_ 을 사용합니다.
 - docstring 은 패키지, 모듈, 클래스나 함수의 첫번째 선언되는 문자열입니다.
 - 이 문자열은 `pydoc` 이 사용하는 `__doc__` 멤버 오브젝트에서 자동으로 추출될 수 있습니다. (여러분의 모듈에서 `pydoc` 를 실행 후 결과를 확인해보세요)
-- [PEP257](https://www.google.com/url?sa=D&q=http://www.python.org/dev/peps/pep-0257/) 에 따라 docstring 을 시작하거나 끝낼 때는 `"""` 를 사용하세요.
+- [PEP257](https://peps.python.org/pep-0257/) 에 따라 docstring 을 시작하거나 끝낼 때는 `"""` 를 사용하세요.
 - docstring은 마침표, 물음표, 느낌표로 끝나는 요약줄(한 줄)로 시작하여야 하며 한 줄의 공백을 두고 내용을 담고있는 나머지 docstring 이 이어져야 합니다.
 - 또한 내용을 담고있는 docstring 은 `"""` 와 같은 커서위치에서 시작하여야 합니다.
 
@@ -393,36 +421,70 @@
 
 #### 3.8.2 Modules
 
-- 모든 파일은 라이센스 보일러 플레이트를 가지고 있어야 합니다.
 - 프로젝트에 알맞는 라이센스 보일러 플레이트를 선택하세요. (예를 들면, Apache 2.0, BSD, LGPL, GPL)
+- 모든 파일은 라이센스 보일러 플레이트를 가지고 있어야 합니다.
+
+  ```python
+  """모듈이나 프로그램에 대한 한 줄 요약으로, 마침표로 끝나야 합니다.
+
+  한 줄을 비워두세요. 이 docstring의 나머지 부분에는 모듈이나 프로그램에
+  대한 전반적인 설명이 포함되어야 합니다. 선택적으로, 내보낸 클래스와
+  함수에 대한 간단한 설명 및/또는 사용 예시도 포함될 수 있습니다.
+
+  전형적인 사용 예시:
+
+    foo = ClassFoo()
+    bar = foo.FunctionBar()
+  """
+  ```
+
+<a id="s3.8.2.1-test-modules"></a>
+<a id="test-docs"></a>
+
+##### 3.8.2.1 Test modules
+
+- 테스트 파일의 모듈 수준 docstring은 필수는 아닙니다.
+- 추가적인 정보를 제공할 필요가 있는 경우에만 포함해야 합니다.
+- 예를 들면, 테스트를 실행하는 방법에 대한 구체적인 내용, 특이한 설정 패턴에 대한 설명, 외부 환경에 대한 의존성 등이 포함될 수 있습니다.
+
+```python
+"""이 Blaze 테스트는 golden 파일을 사용합니다.
+`google3` 디렉토리에서
+`blaze run //foo/bar:foo_test -- --update_golden_files` 명령어를 실행하여
+이러한 파일을 업데이트할 수 있습니다.
+"""
+```
+
+- 새로운 정보를 제공하지 않는 docstring은 사용하지 말아야 합니다.
+
+```python
+"""Tests for foo.bar."""
+```
 
 <a id="s3.8.3-functions-and-methods"></a>
 
 #### 3.8.3 Functions and Methods
 
-- 이 섹션에서 "함수"는 메소드, 함수 또는 제너레이터를 의미합니다.
+- 이 섹션에서 ‘function’은 메소드, 함수, 제너레이터 또는 속성을 의미합니다.
 
-- 아래의 조건을 만족하지 않는 이상 함수는 반드시 docstring 을 가지고 있어야 합니다.
+- 다음 중 하나 이상의 속성을 가진 모든 함수에는 docstring이 필수입니다.
 
-  - 외부에서 보이지 않음
-  - 매우 짧음
-  - 잘 알려져 있음
+  - 공개 API의 일부인 경우
+  - 비교적 큰 경우
+  - 직관적이지 않은 로직을 가진 경우
 
-- docstring 은 직접 함수의 코드를 읽어보지 않더라도 충분히 함수를 호출하는 코드를 작성 할 수 있을만큼 정보를 제공해야 합니다.
-- docstring은 함수의 호출방식이나 시멘틱등을 반드시 기술하되 함수의 사용함에 있어 영항을 주지 않는 한 함수 내부의 상세한 구현방법은 기술하지 아니합니다
-- 예를들어 한 함수가 구동과정에서 인자로 받은 변수 하나를 변형시킨다면 이는 docstring에 기술되어야 합니다.
-- 이외 함수의 호출과 상관이 없는 자잘하지만 중요한 항목들은 함수 내 docstring 보단 주석으로 기록하는 것이 좋습니다
-- docstring 은 (`"""Fetches rows from a Bigtable."""`) 처럼 _설명조_ 를 사용하여야 하며 (`"""Fetch rows from a Bigtable."""`) 처럼 _명령조_ 를 사용하지 않아야 합니다.
-- docstring 은 함수의 구현방식이 아닌 호출 방법과 의미를 기술해야 합니다.
-- 복잡한 코드의 경우 docstring 을 사용하는 것보다 코드 한 줄마다 주석을 첨가하는 것이 더 알맞습니다.
+- docstring은 함수의 코드를 읽지 않고도 함수 호출을 작성할 수 있을 만큼 충분한 정보를 제공해야 합니다.
+- docstring은 함수의 호출 구문과 의미를 설명해야 하며, 일반적으로 구현 세부 사항은 포함하지 않아야 하지만, 이러한 세부 사항이 함수 사용 방법에 중요하다면 예외입니다.
+- 예를 들어, 인자를 사이드 임펙트로 변경하는 함수는 그 점을 docstring에 명시해야 합니다.
 
-- 다른 기본 객체의 메소드를 오버라이드하는 메소드는 `"""See base class."""` 처럼 개발자가 작성한 docstring 에 오버라이드된 메소드가 있음을 알려주는 docstring 을 전달 할 수도 있습니다.
-- 그 이유는 같은 문서를 여러곳에서 반복하는 것을 방지하기 위함입니다.
-- 하지만 오버라이딩된 메소드가 기존의 메소드와 확연하게 다른 동작방식을 가지고 있거나 세부적인 내용(e.g., 잠재적인 부작용 등)이 존재한다면 적어도 그러한 차이점들은 docstring 을 통해 기록되어야 합니다.
+- 그렇지 않으면, 호출자에게 중요하지 않은 함수 구현의 미묘하지만 중요한 세부 사항은 함수의 docstring보다는 코드 옆에 주석으로 표현하는 것이 좋습니다.
+- docstring은 서술형(`"""Fetches rows from a Bigtable."""`) 또는 명령형(`"""Fetch rows from a Bigtable."""`) 스타일일 수 있지만, 파일 내에서 스타일은 일관되게 유지해야 합니다.
+- `@property` 속성의 docstring은 속성이나 [함수 인자](#doc-function-args)의 docstring과 같은 스타일을 사용해야 합니다 (`"""The Bigtable path."""` 대신에 `"""Returns the Bigtable path."""`).
 
-- 다만 함수의 몇가지 특정 부분들은 아래처럼 별도의 특별섹션으로 기록해야 합니다.
-- 각 섹션은 표제로 시작하며 콜론으로 끝맺습니다.
-- 각 섹션은 표제를 제외하고 2칸 들여쓰기를 합니다.
+- 함수의 특정 측면은 아래에 나열된 특별한 섹션에서 문서화해야 합니다.
+- 각 섹션은 콜론으로 끝나는 제목 행으로 시작합니다.
+- 제목을 제외한 모든 섹션은 2칸 또는 4칸 공백의 걸쳐서 들여쓰기를 유지해야 합니다 (파일 내에서 일관되게 유지).
+- 함수의 이름과 시그니처가 충분히 정보를 제공하여 한 줄의 docstring으로 적절히 설명할 수 있는 경우, 이러한 섹션은 생략할 수 있습니다.
 
 <a id="doc-function-args"></a>
 
@@ -437,12 +499,13 @@
 
 ##### [_Returns:_ (제너레이터에는 _Yields:_)](#doc-function-returns)
 
-- 반환값의 자료형과 의미를 기록합니다. 만약 함수가 None만을 반환한다면 이 섹션은 필요없습니다.
-- 또한 만약 docstring이 Returns 나 Yields로 시작하거나(e.g. `"""Returns row from Bigtable as a tuple of strings."""`) 충분한 설명이 제공된다면 생략 될 수 있습니다.
-- Tuple 반환 값을 개별 이름이 있는 여러 반환 값인 것처럼 자주 문서화하는 'NumPy style' ([example](http://numpy.org/doc/stable/reference/generated/numpy.linalg.qr.html))을 모방하지 마세요. (Tuple를 언급하지 않습니다.)
-- 대신, 다음과 같은 반환값으로 기술하세요.
-  - "Returns a tuple (mat_a, mat_b), where mat_a is ..., and ...".
-- Docstring의 보조 이름은 함수 본문에 사용된 내부 이름과 반드시 일치할 필요는 없습니다. (해당 이름은 API의 일부가 아니기 때문입니다.)
+- 반환 값의 의미를 설명하고, 타입 어노테이션에서 제공하지 않는 타입 정보도 포함해야 합니다.
+- 함수가 None만 반환하는 경우, 이 섹션은 필요하지 않습니다.
+- docstring이 "Return", "Returns", "Yield", "Yields"로 시작하고(e.g. `"""Returns row from Bigtable as a tuple of strings."""`), 첫 번째 문장이 반환 값을 설명하기에 충분할 경우, 이 섹션은 생략될 수 있습니다.
+- 이전의 'NumPy 스타일'을 모방하지 마세요. ([example](https://numpy.org/doc/1.24/reference/generated/numpy.linalg.qr.html)) 이 스타일은 종종 튜플 반환 값을 여러 개의 개별 반환 값처럼 각각의 이름으로 문서화했습니다. (튜플이라는 점을 언급하지 않고)
+- 대신, 반환 값을 다음과 같이 설명하세요: "Returns: A tuple (mat_a, mat_b), where mat_a is ..., and ...".
+- docstring에서 사용되는 설명용 이름은 함수 본문에서 사용되는 내부 이름과 반드시 일치할 필요는 없습니다 (내부 이름은 API의 일부가 아니기 때문입니다)
+- 함수가 `yield`를 사용하는 경우(즉, 제너레이터인 경우), `Yields:` 섹션에서는 호출 결과로 반환되는 제너레이터 객체가 아니라, `next()`에 의해 반환되는 객체를 문서화해야 합니다.
 
 <a id="doc-function-raises"></a>
 
@@ -453,10 +516,11 @@
 - 명시된 API가 docstring을 위반했을 될 경우, 예외를 문서화하지 않습니다. (왜냐하면 이것은 역설적으로 API의 API를 위반하는 행동을 만들 수 있기 때문이다.)
 
   ```python
-  def fetch_smalltable_rows(table_handle: smalltable.Table,
-                          keys: Sequence[Union[bytes, str]],
-                          require_all_keys: bool = False,
-  ) -> Mapping[bytes, Tuple[str, ...]]:
+  def fetch_smalltable_rows(
+      table_handle: smalltable.Table,
+      keys: Sequence[bytes | str],
+      require_all_keys: bool = False,
+  ) -> Mapping[bytes, tuple[str, ...]]:
     """Fetches rows from a Smalltable.
 
     Retrieves rows pertaining to the given keys from the Table instance
@@ -490,10 +554,11 @@
 - 마찬가지로, 줄 바꿈이 있는 `Args:`도 허용합니다.
 
   ```python
-  def fetch_smalltable_rows(table_handle: smalltable.Table,
-                            keys: Sequence[Union[bytes, str]],
-                            require_all_keys: bool = False,
-  ) -> Mapping[bytes, Tuple[str, ...]]:
+  def fetch_smalltable_rows(
+      table_handle: smalltable.Table,
+      keys: Sequence[bytes | str],
+      require_all_keys: bool = False,
+  ) -> Mapping[bytes, tuple[str, ...]]:
       """Fetches rows from a Smalltable.
 
       Retrieves rows pertaining to the given keys from the Table instance
@@ -526,19 +591,51 @@
       """
   ```
 
+<a id="s3.8.3.1-overridden-methods"></a>
+<a id="overridden-method-docs"></a>
+
+##### 3.8.3.1 Overridden Methods
+
+- 기본 클래스의 메서드를 오버라이드하는 메서드는 [`@override`](https://typing-extensions.readthedocs.io/en/latest/#override) 데코레이터(`typing_extensions` 또는 `typing` 모듈에서 제공)를 명시적으로 사용하는 경우 docstring이 필요하지 않습니다.
+- 단, 오버라이딩된 메서드의 동작이 기본 메서드의 계약을 실질적으로 개선하거나, 추가적인 사이드 임펙트 등을 문서화해야 하는 경우에는, 그러한 차이점이 최소한 포함된 docstring이 오버라이딩 메서드에 필요합니다.
+
+  ```python
+  from typing_extensions import override
+  class Parent:
+    def do_something(self):
+      """Parent method, includes docstring."""
+  # 자식 클래스, 오버라이드로 주석이 달린 메서드.
+  class Child(Parent):
+    @override
+    def do_something(self):
+      pass
+  ```
+
+  ```python
+  # 자식 클래스에서 @override 데코레이터가 없는 경우, docstring이 필요합니다.
+  class Child(Parent):
+    def do_something(self):
+      pass
+  # docstring이 단순한 경우, @override만으로도 문서가 기본 클래스에 있음을 표시할 수 있습니다.
+  class Child(Parent):
+    @override
+    def do_something(self):
+      """See base class."""
+  ```
+
 <a id="s3.8.4-comments-in-classes"></a>
 
 #### 3.8.4 Classes
 
 - 클래스는 선언 바로 아래에 해당 클래스를 설명하는 docstring 를 가지고 있어야 합니다.
-- 만약 클래스가 public attributes 를 가지고 있다면 [function's `Args`](#doc-function-args) 섹션과 같은 형식을 사용해 `Attributes` 섹션을 작성해야 합니다.
+- [properties](#properties)을 제외한 공개 속성은 `Attributes` 섹션에서 문서화해야 하며, [함수의 `Args`](#doc-function-args) 섹션과 동일한 형식을 따라야 합니다.
 
 ```python
 class SampleClass:
     """Summary of class here.
 
-    Longer class information....
-    Longer class information....
+    Longer class information...
+    Longer class information...
 
     Attributes:
         likes_spam: A boolean indicating if we like SPAM or not.
@@ -546,14 +643,42 @@ class SampleClass:
     """
 
     def __init__(self, likes_spam: bool = False):
-        """Inits SampleClass with blah."""
+        """Initializes the instance based on spam preference.
+        Args:
+          likes_spam: Defines if instance exhibits this preference.
+        """
         self.likes_spam = likes_spam
         self.eggs = 0
 
-    def public_method(self):
-        """Performs operation blah."""
+    @property
+    def butter_sticks(self) -> int:
+        """The number of butter sticks we have."""
 ```
 
+- 모든 클래스의 docstring은 클래스 인스턴스가 무엇을 나타내는지를 설명하는 한 줄 요약으로 시작해야 합니다. 이는 `Exception`의 서브클래스도 예외가 무엇을 나타내는지를 설명해야 하며, 발생할 수 있는 컨텍스트에 대해서는 설명하지 않아야 함을 의미합니다. 클래스의 docstring은 클래스가 클래스라는 등의 불필요한 정보를 반복해서는 안 됩니다.
+
+- 올바른 예
+
+  ```python
+  class CheeseShopAddress:
+    """The address of a cheese shop.
+    ...
+    """
+  class OutOfCheeseError(Exception):
+    """No more cheese is available."""
+  ```
+
+- 부적절한 예
+
+  ```python
+  class CheeseShopAddress:
+    """Class that describes the address of a cheese shop.
+    ...
+    """
+  class OutOfCheeseError(Exception):
+    """Raised when no more cheese is available."""
+  ```
+
 <a id="s3.8.5-block-and-inline-comments"></a>
 <a id="s3.8.5-comments-in-block-and-inline"></a>
 
@@ -604,25 +729,24 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 ### 3.10 Strings
 
 - 매개변수가 모두 문자열인 경우에도 [f-string](https://docs.python.org/3/reference/lexical_analysis.html#f-strings), `format` 메소드나 `%` 연산자를 사용하여 포메팅하세요.
-- 물론 `+` 나 `%` (또는 `format`) 를 언제 사용할지는 개발자의 판단에 따릅니다.
-- 문자열을 합치기 위해 `%` 또는 `format`을 사용하지 마세요.
+- 문자열 포맷팅 옵션 사이에서 최상의 판단을 사용하세요.
+- `+`를 사용한 단일 join은 괜찮지만, `+`를 사용한 포맷팅은 피하세요.
 
   - 올바른 예
 
     ```python
-    x = a + b
+    x = f'name: {name}; score: {n}'
     x = '%s, %s!' % (imperative, expletive)
     x = '{}, {}'.format(first, second)
     x = 'name: %s; score: %d' % (name, n)
+    x = 'name: %(name)s; score: %(score)d' % {'name':name, 'score':n}
     x = 'name: {}; score: {}'.format(name, n)
-    x = f'name: {name}; score: {n}'
+    x = a + b
     ```
 
   - 부적절한 예
 
     ```python
-    x = '%s%s' % (a, b)  # use + in this case
-    x = '{}{}'.format(a, b)  # use + in this case
     x = first + ', ' + second
     x = 'name: ' + name + '; score: ' + str(n)
     ```
@@ -710,6 +834,9 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
         will collapse common leading spaces in each line.""")
     ```
 
+- 여기서 백슬래시를 사용하는 것은 [명시적인 줄 이어쓰기](#line-length)에 대한 금지를 위반하지 않습니다.
+- 이 경우, 백슬래시는 문자열 리터럴에서 [줄바꿈을 이스케이프](https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals)하는 것입니다.
+
 <a id="s3.10.1-logging"></a>
 
 #### 3.10.1 Logging
@@ -760,7 +887,7 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 ```python
   올바른 예:
   if not 0 <= p <= 1:
-    raise ValueError(f'Not a probability: {p!r}')
+    raise ValueError(f'Not a probability: {p=}')
   try:
     os.rmdir(workdir)
   except OSError as error:
@@ -771,7 +898,7 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 ```python
   잘못된 예:
   if p < 0 or p > 1:  # PROBLEM: also false for float('nan')!
-    raise ValueError(f'Not a probability: {p!r}')
+    raise ValueError(f'Not a probability: {p=}')
   try:
     os.rmdir(workdir)
   except OSError:
@@ -846,33 +973,44 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 
 - 임시적, 잠시 사용하려는 코드 또는 좋기는 하지만 완벽하지 않은 코드의 경우 `TODO` 주석을 사용하세요.
 
-- `TODO` 주석은 대문자로 되어있는 `TODO` 문구로 시작하며 해당 코드에 대한 가장 높은 이해도를 가진 인물의 이름, 이메일 주소 또는 다른 신원구분 문구를 괄호안에 넣어 포함하여야 합니다.
-- 이것 뒤에 무엇을 해야하는 지에 대한 내용을 추가합니다.
+- `TODO` 주석은 모두 대문자로 된 `TODO`로 시작하고, 다음에 콜론을 붙이며, 맥락이 포함된 리소스에 대한 링크(이상적으로는 버그 참조)를 포함해야 합니다.
+- 버그 참조가 선호됩니다. 왜냐하면 버그는 추적되며 후속 댓글이 달리기 때문입니다.
+- 이 문맥 다음에 하이픈 `-`으로 시작하는 설명 문자열을 추가하세요..
+- 목적은 일관된 `TODO` 형식을 유지하여, 더 많은 세부 정보를 찾기 위해 검색할 수 있도록 하는 것입니다.
 
-- 목적은 `TODO`가 일관된 형식을 이용하여 추후 필요한 세부정보를 검색할 수 있어야 한다는 것입니다.
-- `TODO` 는 본인이 아닌 다른 개발자가 문제를 해결하겠다는 약속이 아닙니다.
-- 따라서 `TODO` 를 만드셨다면 거의 항상 작성한 본인의 이름이 들어가야 합니다.
+  ```python
+  # TODO: crbug.com/192795 - Investigate cpufreq optimizations.
+  ```
 
-```python
-# TODO(kl@gmail.com): Use a "*" here for string repetition.
-# TODO(Zeke) Change this to use relations.
-```
+- 이전 스타일로, 예전에는 권장되었지만 새로운 코드에서는 사용이 권장되지 않습니다.
 
-- 만약 작성한 `TODO` 가 "추후 무엇을 진행할 것" 이라는 형식을 담고 있다면 반드시 ("2009년 11월까지") 와 같은 구체적인 기간이나 ("모든 클라이언트가 XML 요청을 해결 할수 있을때 이 코드 삭제") 처럼 목적을 포함하여야 합니다.
+  ```python
+  # TODO(crbug.com/192795): Investigate cpufreq optimizations.
+  # TODO(yourusername): Use a "\*" here for concatenation operator.
+  ```
+
+- 문맥으로 개인이나 팀을 참조하는 TODO를 추가하는 것을 피하세요.
+
+  ```python
+  # TODO: @yourusername - File an issue and use a '*' for repetition.
+  ```
+
+- `TODO`가 "미래의 어느 시점에 무엇을 해야 한다"는 형식이라면, 미래의 코드 유지 관리자가 이해할 수 있도록 매우 구체적인 날짜("2009년 11월까지")나 사건("모든 클라이언트가 XML 요청을 해결 할수 있을때 이 코드 삭제")을 포함해야 합니다.
+- 이슈는 이를 추적하는 데 이상적입니다.
 
 ---
 <a id="s3.13-imports-formatting"></a>
 
 ### 3.13 import 형식
 
-- imports는 개별적인 라인에 두어야 합니다; [`typing` imports에 대한 예외가 있습니다.](#s3.19.12-imports).
+- imports는 개별적인 라인에 두어야 합니다; [`typing` 그리고 `collections.abc` imports에 대한 예외가 있습니다.](#s3.19.12-imports).
 
   - 올바른 예
 
     ```python
     import os
     import sys
-    from typing import Mapping, Sequence
+    from typing import Any, NewType
     ```
 
   - 부적절한 예
@@ -884,7 +1022,15 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 - import는 모듈의 주석 과 docstring 바로 다음, 모듈 전역 및 상수 바로 앞 파일의 맨 위에 배치됩니다.
 - import는 가장 일반적인 것 부터 최소한의 일반적인 것들까지 묶여야 합니다.
 
-1. 파이썬의 표준 라이브러리
+1. Python의 **future** import 문
+
+   ```python
+   from __future__ import annotations
+   ```
+
+   자세한 내용은 [위](#from-future-imports)를 참조하세요.
+
+2. 파이썬의 표준 라이브러리
 
    - import 예시는 다음과 같습니다.
 
@@ -892,7 +1038,7 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
    import sys
    ```
 
-2. [third-party](https://pypi.org/)
+3. [third-party](https://pypi.org/)
 
    - 모듈이나 패키지의 import 예시는 다음과 같습니다.
 
@@ -900,7 +1046,7 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
    import tensorflow as tf
    ```
 
-3. Code repository
+4. Code repository
 
    - 서브 패키지의 import 예시는 다음과 같습니다.
 
@@ -908,7 +1054,7 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
    from otherproject.ai import mind
    ```
 
-4. 동일한 top 레벨에 속하는 어플리케이션의 특정을 import하는 것은 **더 이상 사용되지 않습니다**
+5. 동일한 top 레벨에 속하는 어플리케이션의 특정을 import하는 것은 **더 이상 사용되지 않습니다**
 
    - 서브 패키지의 파일 import 예시는 다음과 같습니다.
 
@@ -1006,7 +1152,9 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 `global_var_name`,
 `instance_var_name`,
 `function_parameter_name`,
-`local_var_name`.
+`local_var_name`,
+`query_proper_noun_for_thing`,
+`send_acronym_via_https`.
 
 - 함수 이름, 변수 이름, 그리고 파일 이름은 설명적이여야 하고 약어로 적는 일을 피해야 합니다.
 - 특히 모호하거나 프로젝트에 참여하지 않은 사람들이 읽었을 때 익숙하지 않은 약어를 사용하지마세요. 그리고 절대 단어에서 글자를 지워 줄이지 마세요.
@@ -1017,15 +1165,20 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 
 #### 3.16.1 피해야 할 이름
 
-1. 아래와 같은 특별한 경우를 제외한 단일 글자는 피합니다.
+- 아래와 같은 특별한 경우를 제외한 단일 글자는 피합니다.
+
+  - counters이나 iterators에서 사용할 때 (예. `i`, `j`, `k`, `v` 등)
+  - `try/except`문에서 예외 식별자로 `e`를 사용할 때
+  - with문의 파일 핸들에서 `f`를 사용할 때
+  - 제약 조건이 없는 비공식적인 [type variables](#typing-type-var)를 사용할 때 (e.g., `_T = TypeVar("_T"), _P = ParamSpec("_P")`)
 
-- counters이나 iterators에서 사용할 때 (예. `i`, `j`, `k`, `v` 등)
-- `try/except`문에서 예외 식별자로 `e`를 사용할 때
-- with문의 파일 핸들에서 `f`를 사용할 때
   단일 글자를 남용하지 않도록 주의해야합니다. 일반적으로 말해서 서술성은 이름의 가시성 범위에 비례해야합니다. 예를 들어 `i`는 5행 코드 블록에 적합한 이름일 수 있지만 중첩된 여러 범위 내에서는 너무 모호할 수 있습니다.
+
 - package/module 이름에서 dashes(`-`)를 사용할 때
 - `__이중_선행_및_후행_밑줄__` 이름을 사용할 때 (Python에서 예약어)
+
   - 원본에 없는 추가 설명 : double leading and trailing underscore : (앞 뒤로 \_가 2개씩 있는것 e.g **name**, **init**)
+
 - 공격적인 단어
 - 불필요하게 변수 타입을 포함하는 이름 (예 : `id_to_name_dict`)
 
@@ -1037,16 +1190,20 @@ if i & (i-1) == 0:  # True if i is 0 or a power of 2.
 
 - "Internal"는 모듈의 내부 또는 클래스 내에서 protected 또는 private를 의미합니다.
 - 단일 밑줄(`_`)을 추가하면 모듈 변수와 함수를 보호하기 위한 몇 가지 지원이 있습니다. (linters는 보호된 멤버 접근에 플래그를 지정합니다.)
+- 단일 언더스코어(`_`)를 접두사로 사용하는 것은 모듈 변수와 함수 보호를 위한 일부 지원을 제공합니다 (linters가 보호된 멤버 접근을 경고할 수 있습니다). 그러나 유닛 테스트가 테스트 중인 모듈의 보호된 상수에 접근하는 것은 괜찮습니다.
 - 인스턴스 변수나 메소드에 이중 밑줄(`__` : dunder)을 추가하면 변수나 메소드가 해당 클래스에 대해 효과적으로 private 됩니다.
   - 가독성과 테스트 가능성에 영향을 미치고 _실제로_ 비공개가 아니므로 사용을 권장하지 않습니다.
   - 하나의 밑줄을 선호합니다.
 - 모듈에 관련 클래스와 top-level 함수를 함께 배치합니다.
 - 자바와는 다르게 하나의 모듈에 대해 하나의 클래스로 제한을 할 필요가 없습니다.
 - CapWords(단어의 첫 글자를 대문자로 하는 방식)을 사용하지만 모듈의 이름이 \_with_under.py 같은 경우에는 소문자로 합니다.
+
   - 비록 몇몇 오래된 모듈의 이름이 CapWords.py일지라도 이제는 모듈의 이름을 class이름에 따라 짓게 되면 혼란스러우므로 권장하지 않습니다. (e.g "잠깐만, -- 내가 `import StringIO`를 한거야 아니면 `from StringIO import StringIO`를 한거야 ?" 같은 상황이 발생할 수 있습니다.)
-- 구성 요소가 CapWord를 사용하더라도 "test"로 시작하는 _unittest_ 메서드 이름에 Undercore가 나타날 수 있습니다.
-  - 한 가지 가능한 패턴은 `test<MethodUnderTest>_<state>`로, 예를 들어 `testPop_EmptyStack`같은 패턴은 괜찮습니다.
-  - test 메서드에 에 이름을 붙이는 올바른 방법은 없습니다.
+
+- 새로운 유닛 테스트 파일은 PEP 8을 준수하는 소문자와 언더스코어 방식의 메서드 이름을 따릅니다.
+  - 예를 들어, `test*<method*under_test>*<state>`와 같은 형식을 사용합니다.
+  - 일관성을 위해(\*) 이전 모듈에서 CapWords 함수 이름을 따르는 경우, `test`로 시작하는 메서드 이름에 논리적 구성 요소를 구분하기 위해 언더스코어가 포함될 수 있습니다.
+  - 하나의 가능한 패턴은 `test<MethodUnderTest>_<state>`입니다.
 
 <a id="s3.16.3-file-naming"></a>
 
@@ -1146,9 +1303,24 @@ if __name__ == '__main__':
 
 #### 3.19.1 일반적인 규칙
 
-- [PEP-484](https://www.python.org/dev/peps/pep-0484/)을 읽으세요.
-- 메서드에서는 `self`, `cls`는 Type의 정보가 필요한 경우에서만 주석을 달아야합니다. 예) `@classmethod def create(cls: Type[T]) -> T: return cls()`
+- [PEP-484](https://peps.python.org/pep-0484/)을 읽으세요.
+
+- `self` 또는 `cls`에 주석을 달 필요는 일반적으로 없습니다. 올바른 타입 정보를 위해 필요한 경우에만 [`Self`](https://docs.python.org/3/library/typing.html#typing.Self)를 사용할 수 있습니다.
+
+  ```python
+  from typing import Self
+  class BaseClass:
+    @classmethod
+    def create(cls) -> Self:
+      ...
+    def difference(self, other: Self) -> float:
+      ...
+  ```
+
+- 마찬가지로, `__init__`의 반환 값에 주석을 달 필요는 없습니다 (여기서 `None`만 유효한 옵션입니다).
+
 - 모든 변수나 반환되는 Type이 정해지지 않았다면 `Any`를 사용하세요.
+
 - 모듈에서 모든 함수에 주석을 달 필요는 없습니다.
   - Public API에는 최소한의 주석을 답니다.
   - 판단력을 사용하여 한편으로는 안전성과 명확성, 그리고 다른 한편으로는 유연성 사이의 균형을 잘 잡아야 합니다.
@@ -1163,12 +1335,15 @@ if __name__ == '__main__':
 - 기존의 [들여쓰기](#s3.4-indentation) 규칙을 따르세요.
 
 - 주석처리하고나서 많은 함수는 "한 줄에 하나의 파라미터"가 될 것입니다.
+- 반환 타입이 별도의 줄에 표시되도록 보장하기 위해, 마지막 매개변수 뒤에 쉼표를 추가할 수 있습니다.
 
   ```python
-  def my_method(self,
-              first_var: int,
-              second_var: Foo,
-              third_var: Optional[Bar]) -> int:
+  def my_method(
+      self,
+      first_var: int,
+      second_var: Foo,
+      third_var: Bar | None,
+  ) -> int:
   ...
   ```
 
@@ -1180,23 +1355,25 @@ if __name__ == '__main__':
   ```
 
 - 함수 이름, 마지막 매개 변수 및 리턴 Type의 조합이 너무 길면 새 행에서 4만큼 들여 쓰기됩니다.
+- 줄 바꿈을 사용할 때는 각 매개변수와 반환 타입을 별도의 줄에 배치하고, 닫는 괄호를 `def`와 정렬하는 것이 좋습니다.
 
   ```python
   def my_method(
-      self, first_var: int) -> Tuple[MyLongType1, MyLongType1]:
+      self,
+      other_arg: MyLongType | None,
+  ) -> tuple[MyLongType1, MyLongType1]:
   ...
   ```
 
-리턴 유형이 마지막 파라미터와 같은 라인에 맞지 않을 경우, 선호되는 방법은 파라미터를 4만큼 새 라인에 들여쓰고 닫히는 괄호를 "def"와 정렬하는 것이다.
+- 선택적으로, 반환 타입을 마지막 매개변수와 같은 줄에 배치할 수도 있습니다.
 
-- 반환 Type이 마지막 파라미터와 같은 줄이 아닐 때, 선호하는 방법은 파라미터를 4만큼 새 라인에 들여쓰고 닫히는 괄호를 `def`와 정렬합니다.
-
-  - 올바른 예
+  - 괜찮은 예
 
     ```python
     def my_method(
-        self, **kw_args: Optional[MyLongType]
-    ) -> Dict[OtherLongType, MyLongType]:
+      self,
+      first_var: int,
+      second_var: int) -> dict[OtherLongType, MyLongType]:
     ...
     ```
 
@@ -1206,8 +1383,8 @@ if __name__ == '__main__':
 
     ```python
     def my_method(self,
-                **kw_args: Optional[MyLongType]
-                ) -> Dict[OtherLongType, MyLongType]:
+              other_arg: MyLongType | None,
+             ) -> dict[OtherLongType, MyLongType]:
     ...
     ```
 
@@ -1217,10 +1394,11 @@ if __name__ == '__main__':
   ```python
   def my_method(
       self,
-      first_var: Tuple[List[MyLongType1],
-                      List[MyLongType2]],
-      second_var: List[Dict[
-          MyLongType3, MyLongType4]]) -> None:
+      first_var: tuple[list[MyLongType1],
+                      list[MyLongType2]],
+      second_var: list[dict[
+          MyLongType3, MyLongType4]],
+  ) -> None:
   ...
   ```
 
@@ -1251,23 +1429,34 @@ if __name__ == '__main__':
 
 #### 3.19.3 전방선언
 
-- 아직 정의되지 않은 동일한 모듈의 클래스 이름을 사용해야 하는 경우(예, 클래스 선언 내에 클래스가 필요한 경우 또는 아래에 정의된 클래스를 사용하는 경우) `from __future__ import annotations`를 사용하세요.
-- 간단한 경우에는 주석을 사용하거나 클래스 이름에 문자열을 사용하세요.
+- 아직 정의되지 않은 클래스 이름(예를 들어, 클래스 선언 내부에서 클래스 이름이 필요하거나 코드에서 나중에 정의된 클래스를 사용할 경우)을 사용해야 할 경우, `from __future__ import annotations`를 사용하거나 클래스 이름을 문자열로 사용하세요.
 
-```python
-from __future__ import annotations
+  - 올바른 예
 
-class MyClass:
+    ```python
+    from __future__ import annotations
 
-  def __init__(self, stack: Sequence[MyClass]) -> None:
-```
+    class MyClass:
+      def __init__(self, stack: Sequence[MyClass], item: OtherClass) -> None:
+
+    class OtherClass:
+      ...
+    ```
+
+    ```python
+    class MyClass:
+      def __init__(self, stack: Sequence['MyClass'], item: 'OtherClass') -> None:
+
+    class OtherClass:
+      ...
+    ```
 
 <a id="s3.19.4-default-values"></a>
 
 #### 3.19.4 기본 값
 
 - PEP-008에 따라 유형 주석과 기본값이 모두 있는 인수의 경우 "=" \_ only" 주위에 공백을 사용하십시오.
-- [PEP-008](https://www.python.org/dev/peps/pep-0008/#other-recommendations)에 따라 Type 주석과 기본 값이 모두 있는 인수의 경우 `=` _only_ 주위에 공백을 사용하세요,
+- [PEP-008](https://peps.python.org/pep-0008/#other-recommendations)에 따라 Type 주석과 기본 값이 모두 있는 인수의 경우 `=` _only_ 주위에 공백을 사용하세요,
 
 - 올바른 예
 
@@ -1287,19 +1476,20 @@ class MyClass:
 
 #### 3.19.5 NoneType
 
-- 파이썬형에서 노네타입(NoneType)은 퍼스트클래스형이며, 타이핑을 위해 노네타입(NoneType)은 노네타입(NoneType)의 별칭이다. 논쟁이 '없음'이 될 수 있다면 선언해야 한다! 유니온(Union)은 사용할 수 있지만, 다른 유형이 하나만 있는 경우에는 선택사항(Option)을 사용하십시오.
+- 파이썬형에서 노네타입(NoneType)은 퍼스트클래스형이며, 타이핑을 위해 노네타입(NoneType)은 노네타입(NoneType)의 별칭이다.
+- 인자가 `None`이 될 수 있는 경우, 이를 선언해야 합니다!
+- 새로운 Python 3.10+ 코드에서는 `|` 유니온 타입 표현식을 사용하는 것이 권장되며, 이전에는 `Optional`과 `Union` 구문을 사용할 수 있습니다.
 
-- 파이썬 타입 시스템에서 `NoneType`은 "first class" Type 이며 작성을 위해 `None`은 `NoneType`의 alias(별칭)입니다. 인자는 `None`이 될 수 있다면 선언을 해야합니다! `Union`을 사용할 수 있지만 다른 Type이 하나만 있는 경우 `Optional`를 사용하세요.
-
-- 암시적 `Optional` 대신 명시적 `Optional` 사용해야 합니다. PEP 484 이전 버전에서는 `a: Optional[str] = None` 대신에 `a: str = None` 를 선호했지만 지금은 그렇지 않습니다.
+- 암시적인 대신 명시적인 `X | None`을 사용하세요.
+- 이전 버전의 PEP 484에서는 `a: str = None`을 `a: str | None = None`으로 해석할 수 있었지만, 이제는 이것이 선호되는 동작이 아닙니다.
 
 - 올바른 예
 
   ```python
-  def func(a: Optional[str], b: Optional[str] = None) -> str:
-  ...
-  def multiple_nullable_union(a: Union[None, str, int]) -> str:
-  ...
+  def modern_or_union(a: str | int | None, b: str | None = None) -> str:
+    ...
+  def union_optional(a: Union[str, int, None], b: Optional[str] = None) -> str:
+    ...
   ```
 
 - 부적절한 예
@@ -1320,14 +1510,13 @@ class MyClass:
 
 - 어려운 Type을 별칭으로 선언할 수 있습니다. 별칭은 CapWorded여야 합니다. 별칭이 이 모듈에서만 사용하는 경우에는 \_Private여야 합니다.
 
-- 예를 들어 Type과 함께 모듈의 이름이 너무 긴 경우
-
-  ```python
-  _ShortName = module_with_long_name.TypeWithLongName
-  ComplexMap = Mapping[str, List[Tuple[int, int]]]
-  ```
+- TypeAlias 주석은 버전 3.10 이상에서만 지원된다는 점에 유의하세요.
 
-- 다른 예로는 복잡한 중첩 유형과 함수의 복수 반환 변수(튜플)가 있습니다.
+```python
+from typing import TypeAlias
+_LossAndGradient: TypeAlias = tuple[tf.Tensor, tf.Tensor]
+ComplexTFMap: TypeAlias = Mapping[str, _LossAndGradient]
+```
 
 <a id="s3.19.7-ignoring-types"></a>
 <a id="s3.19.7-ignore"></a>
@@ -1347,11 +1536,21 @@ class MyClass:
 
 #### 3.19.8 내부 변수 작성
 
-- 내부 변수가 유추하기 어렵거나 불가능한 타입을 가지고 있는 경우, 다음과 같이 별도의 주석으로 설명할 수 있습니다.
+<a id="annotated-assignments"></a>
 
-```python
-a = SomeUndecoratedFunction()  # type: Foo
-```
+- [_Annotated Assignments_](#annotated-assignments): 내부 변수의 타입을 추론하기 어렵거나 불가능한 경우, 주석이 달린 할당으로 타입을 명시하세요. 변수 이름과 값 사이에 콜론과 타입을 사용합니다 (기본값이 있는 함수 인수와 동일한 방식으로).
+
+  ```python
+  a: Foo = SomeUndecoratedFunction()
+  ```
+
+<a id="type-comments"></a>
+
+- [_Type Comments_](#type-comments): 코드베이스에 여전히 남아 있을 수 있지만 (Python 3.6 이전에는 필요했음), 더 이상 `# type: <type name>` 주석을 줄 끝에 추가하지 마세요.
+
+  ```python
+  a = SomeUndecoratedFunction()  # type: Foo
+  ```
 
 <a id="s3.19.9-tuples-vs-lists"></a>
 <a id="s3.19.9-tuples"></a>
@@ -1363,30 +1562,38 @@ a = SomeUndecoratedFunction()  # type: Foo
 - 리스트는 함수의 반환 타입으로 일반적으로 사용된다.
 
 ```python
-a = [1, 2, 3]  # type: List[int]
-b = (1, 2, 3)  # type: Tuple[int, ...]
-c = (1, "2", 3.5)  # type: Tuple[int, str, float]
+a: list[int] = [1, 2, 3]
+b: tuple[int, ...] = (1, 2, 3)
+c: tuple[int, str, float] = (1, "2", 3.5)
 ```
 
 <a id="s3.19.10-typevars"></a>
 <a id="s3.19.10-type-var"></a>
+<a id="typevars"></a>
 
-#### 3.19.10 TypeVar
+#### 3.19.10 Type variables
 
 - 파이썬형 시스템은 일반성을 가지고 있다. 공장 기능인 TypeVar는 흔히 사용하는 방법입니다.
 
-- 파이선 Type에는 [generics](https://www.python.org/dev/peps/pep-0484/#generics)를 가지고 있습니다.
-- factory function `TypeVar`는 흔히 사용하는 방법입니다.
+- 파이선 Type에는 [generics](https://peps.python.org/pep-0484/#generics)를 가지고 있습니다.
+- `TypeVar`와 `ParamSpec`과 같은 타입 변수는 제너릭을 사용하는 일반적인 방법입니다.
 
   ```python
-  from typing import List, TypeVar
-  T = TypeVar("T")
+  from collections.abc import Callable
+  from typing import ParamSpec, TypeVar
+  _P = ParamSpec("_P")
+  _T = TypeVar("_T")
   ...
-  def next(l: List[T]) -> T:
-  return l.pop()
+  def next(l: list[_T]) -> _T:
+    return l.pop()
+  def print_when_called(f: Callable[_P, _T]) -> Callable[_P, _T]:
+    def inner(*args: _P.args, **kwargs: _P.kwargs) -> _T:
+      print("Function was called")
+      return f(*args, **kwargs)
+    return inner
   ```
 
-- TypeVar는 부자연스러울 수도 있습니다.
+- `TypeVar`는 부자연스러울 수도 있습니다.
 
   ```python
   AddableType = TypeVar("AddableType", int, float, str)
@@ -1394,7 +1601,7 @@ c = (1, "2", 3.5)  # type: Tuple[int, str, float]
   return a + b
   ```
 
-- `typing` 모듈의 흔히 미리 정의된 Type 변수는 `AnyStr`입니다. `bytes`, `unicode`일 수 있고 모두 같은 Type이어야 하는 여러 주석에 사용합니다.
+- `typing` 모듈의 흔히 미리 정의된 Type 변수는 `AnyStr`입니다. `bytes`, `str`일 수 있고 모두 같은 Type이어야 하는 여러 주석에 사용합니다.
 
   ```python
   from typing import AnyStr
@@ -1404,48 +1611,46 @@ c = (1, "2", 3.5)  # type: Tuple[int, str, float]
   raise ValueError()
   ```
 
-<a id="s3.19.11-string-types"></a>
-<a id="s3.19.11-strings"></a>
+- 타입 변수는 설명적인 이름을 가져야 합니다. 단, 다음 모든 기준을 충족하는 경우에는 예외입니다.
 
-#### 3.19.11 문자열 Type
+  - 외부에서 보이지 않는 경우
+  - 제약 조건이 없는 경우
 
-- String 주석에 대한 적절한 Type은 코드의 용도에 따라 달라집니다.
+  - 올바른 예
 
-- `str`을 사용하는 것을 선호하지만 `Text`도 허용됩니다. 둘 중 하나를 일관성 있게 사용하세요.
-- 바이너리 데이터를 다루는 코드의 경우 `bytes`를 사용하세요.
-- 텍스트 데이터(Python 2에서는 `str` 또는 `unicode`, Python3에서는 `str`)를 처리하는 Python 2 호환 코드의 경우 `Text`를 사용하세요.
+    ```python
+      _T = TypeVar("_T")
+      _P = ParamSpec("_P")
+      AddableType = TypeVar("AddableType", int, float, str)
+      AnyFunction = TypeVar("AnyFunction", bound=Callable)
+    ```
 
-```python
-def deals_with_text_data_in_py3(x: str) -> str:
-  ...
-def deals_with_binary_data(x: bytes) -> bytes:
-  ...
-def py2_compatible_text_data_processor(x: Text) -> Text:
-  ...
-```
+  - 부적절한 예
 
-- 일부 흔하지 않은 Python2 호환성 사례에서는 `Text` 대신 `str`이 의미가 있을 수 있으며 일반적으로 Python2와 Python3 간에 반환 유형이 동일하지 않을 때 호환성을 돕기 위해 사용됩니다.
-- Python3에는 `unicode`가 없으므로 절대 사용하지 마세요.
-- 이러한 불일치가 존재하는 이유는 `str`이 Python3와 Python2에서 다른 의미를 갖기 때문입니다.
+    ```python
+      T = TypeVar("T")
+      P = ParamSpec("P")
+      _T = TypeVar("_T", int, float, str)
+      _F = TypeVar("_F", bound=Callable)
+    ```
 
-- 부적절한 예
+<a id="s3.19.11-string-types"></a>
+<a id="s3.19.11-strings"></a>
+<a id="31911-string-types"></a>
+<a id="typing-strings"></a>
 
-```python
-def py2_code(x: str) -> unicode:
-  ...
-```
+#### 3.19.11 문자열 Type
 
-If the type can be either bytes or text, use `Union`, with the appropriate text
-type.
+> 새로운 코드에서는 `typing.Text`를 사용하지 마세요. 이는 Python 2/3 호환성을 위한 것입니다.
 
-```python
-from typing import Text, Union
-...
-def py3_only(x: Union[bytes, str]) -> Union[bytes, str]:
-  ...
-def py2_compatible(x: Union[bytes, Text]) -> Union[bytes, Text]:
-  ...
-```
+- 문자열/텍스트 데이터에는 `str`을 사용하세요. 이진 데이터와 관련된 코드에서는 `bytes`를 사용하세요.
+
+  ```python
+  def deals_with_text_data(x: str) -> str:
+    ...
+  def deals_with_binary_data(x: bytes) -> bytes:
+    ...
+  ```
 
 - 함수의 모든 string Type이 항상 동일한 경우(예, 반환 Type이 위의 코드에서 인자 Type과 동일한 경우) [AnyStr](#s3.19.10-type-var)를 사용하세요.
 
@@ -1456,19 +1661,31 @@ def py2_compatible(x: Union[bytes, Text]) -> Union[bytes, Text]:
 
 #### 3.19.12 Typing 추가
 
-- `typing` 모듈의 클래스는 항상 클래스 자체를 가져와야 합니다. `typing` 모듈에서 한 줄에 여러개의 특정 클래스를 가져올 수 있습니다.
+- `typing` 또는 `collections.abc` 모듈에서 정적 분석 및 타입 검사를 지원하기 위해 사용하는 심볼(타입, 함수, 상수 등)은 항상 심볼 자체를 임포트하세요.
+- 이렇게 하면 일반적인 주석이 더 간결해지고, 전 세계적으로 사용되는 타입 주석 관행에 맞출 수 있습니다.
+- `typing` 및 `collections.abc` 모듈에서 여러 개의 특정 심볼을 한 줄에서 명시적으로 임포트할 수 있습니다.
 
   ```python
-  from typing import Any, Dict, Optional
+  from collections.abc import Mapping, Sequence
+  from typing import Any, Generic, cast, TYPE_CHECKING
   ```
 
-- `typing`에서 가져오는 이러한 방식이 로컬 네임스페이스에 항목을 추가한다는 점에서, `typing`의 모든 이름은 키워드와 유사하게 취급되어야 하며, typing이든 아니든 Python 코드에 정의되어서는 안됩니다.
-- 모듈에 있는 Type과 기존 이름이 충돌하는 경우 `import x as y`를 사용해서 가져와야 합니다.
+- 이 방식으로 임포트하면 로컬 네임스페이스에 항목이 추가되므로, `typing` 또는 `collections.abc`의 이름은 키워드와 유사하게 취급되어야 하며, Python 코드에서 정의되지 않아야 합니다. 타입 여부와 관계없이 말입니다.
+- 모듈 내에서 타입과 기존 이름 간에 충돌이 있는 경우, `import x as y`를 사용하여 임포트하세요.
 
   ```python
   from typing import Any as AnyType
   ```
 
+- 가능한 경우, 주석으로 내장 타입을 사용하는 것이 좋습니다.
+- Prefer to use built-in types as annotations where available.
+- Python은 [PEP-585](https://peps.python.org/pep-0585/)를 통해 매개형 컨테이너 타입을 사용한 타입 주석을 지원하며, 이는 Python 3.9에서 도입되었습니다.
+
+  ```python
+  def generate_foo_scores(foo: set[str]) -> list[float]:
+    ...
+  ```
+
 <a id="typing-conditional-imports"></a>
 <a id="s3.19.13-conditional-imports"></a>
 
@@ -1509,7 +1726,7 @@ def f(x: "sketch.Sketch"): ...
   - 하지만 기술적으로 Circular 종속성을 유지하는 것은 가능하지만, 다양한 빌드 시스템은 다른 모듈에 의존해야 하기 때문에 그렇게 하도록 허락하지 않을 것입니다.
 
 - Circular 종속을 생성하는 모듈을 `Any`로 교체합니다.
-  - 의미있는 이름으로 [alias](#s3.19.6-aliases)를 지정하고 모듈의 실제 Type 이름을 사용하세요 (어떤 것의 어떤 속성인 Any).
+  - 의미있는 이름으로 [alias](#s3.19.6-aliases)를 지정하고 모듈의 실제 Type 이름을 사용하세요 (`Any`의 모든 속성은 `Any`입니다.).
   - Alias의 정의는 마지막으로 import와 한 줄로 분리합니다.
 
 ```python
@@ -1526,33 +1743,37 @@ def my_method(self, var: "some_mod.SomeType") -> None:
 
 #### 3.19.15 일반
 
-- 주석을 달때, 일반 Type를 지정하기를 선호하며 그렇지 [않을 때에는 `Any`로 가정합니다](https://www.python.org/dev/peps/pep-0484/#the-any-type).
+- 주석을 달때, 일반 Type를 지정하기를 선호하며 그렇지 [않을 때에는 `Any`로 가정합니다](https://peps.python.org/pep-0484/#the-any-type).
 
-```python
-def get_names(employee_ids: List[int]) -> Dict[int, Any]:
-  ...
-```
+  - 올바른 예
 
-```python
-# 두 개의 함수 모두 get_names(employee_ids: List[Any]) -> Dict[Any, Any]
-def get_names(employee_ids: list) -> Dict:
-  ...
+    ```python
+    def get_names(employee_ids: Sequence[int]) -> Mapping[int, str]:
+      ...
+    ```
 
-def get_names(employee_ids: List) -> Dict:
-  ...
-```
+  - 부적절한 예
+
+    ```python
+    # 이는 get_names(employee_ids: Sequence[Any]) -> Mapping[Any, Any]로 해석됩니다.
+    def get_names(employee_ids: Sequence) -> Mapping:
+    ```
 
 - 파라미터의 적합한 Type이 `Any`일 때, 명시적으로 표현되며, 많은 경우에 [`TypeVar`](#s3.19.10-type-var)가 더 적합할 수 있음을 기억해야합니다.
 
-```python
-def get_names(employee_ids: List[Any]) -> Dict[Any, str]:
-  """직원의 아이디를 이름과 연결하여 반환합니다."""
-```
+  - 부적절한 예
 
-```python
-T = TypeVar('T')
-def get_names(employee_ids: List[T]) -> Dict[T, str]:
-  """직원의 아이디를 이름과 연결하여 반환합니다."""
-```
+    ```python
+    def get_names(employee_ids: Sequence[Any]) -> Mapping[Any, str]:
+      """직원의 아이디를 이름과 연결하여 반환합니다."""
+    ```
+
+  - 올바른 예
+
+    ```python
+    _T = TypeVar('_T')
+    def get_names(employee_ids: Sequence[_T]) -> Mapping[_T, str]:
+      """직원의 아이디를 이름과 연결하여 반환합니다."""
+    ```
 
 ---
diff --git "a/Google Python Style Guide/4. \353\247\272\354\235\214\353\247\220/4.1 \353\247\272\354\235\214\353\247\220.md" "b/Google Python Style Guide/4. \353\247\272\354\235\214\353\247\220/4.1 \353\247\272\354\235\214\353\247\220.md"
index 0413a7e..cb35dce 100644
--- "a/Google Python Style Guide/4. \353\247\272\354\235\214\353\247\220/4.1 \353\247\272\354\235\214\353\247\220.md"	
+++ "b/Google Python Style Guide/4. \353\247\272\354\235\214\353\247\220/4.1 \353\247\272\354\235\214\353\247\220.md"	
@@ -1,7 +1,12 @@
 <h3> 일관성을 유지하세요 </h3>
 
 - 당신이 코드를 수정한다면 몇 분을 투자해서 코드를 살펴보고 스타일을 파악하세요.
-- 만약 모든 산술 연산자에 공백을 넣었다면 당신도 그렇게 해야합니다. 만약 주석이 hash marks(`#`)으로 만든 박스 안에 들어있다면 당신의 주석도 그렇게 해야합니다.
+- 그들이 인덱스 변수 이름에 `_idx` 접미사를 사용하는 경우, 당신도 그렇게 해야 합니다. 만약 주석이 hash marks(`#`)으로 만든 박스 안에 들어있다면 당신의 주석도 그렇게 해야합니다.
+
 - 스타일 가이드라인의 요점은 코딩에서 공통된 어투를 갖는 것입니다. 그렇게 된다면 사람들은 당신의 코딩 형식보다는 당신의 코드에 집중할 수 있습니다
 - 우리는 여기서 사람들이 어휘를 알 수 있는 세계적인 코딩 스타일 규칙을 제공하지만 고유의 스타일도 중요합니다.
-- 파일에 코드를 추가했을 때 이 코드가 다른 코드와 비교하여 크게 달라 보이면 코드를 읽는 사람의 입장에서는 리듬이 깨집니다. 이 부분을 주의하세요.
+- 파일에 코드를 추가했을 때 이 코드가 다른 코드와 비교하여 크게 달라 보이면 코드를 읽는 사람의 입장에서는 리듬이 깨집니다.
+
+- 그러나 일관성에는 한계가 있습니다.
+- 일관성은 주로 지역적으로 적용되며, 전역 스타일에서 명시되지 않은 선택에 더 강하게 적용됩니다.
+- 일관성을 구식 스타일을 고수하는 정당화의 근거로 삼기보다는 새로운 스타일의 장점이나 코드베이스가 시간이 지남에 따라 새로운 스타일로 수렴하는 경향을 고려하는 것이 좋습니다.
diff --git "a/Google Python Style Guide/4. \353\247\272\354\235\214\353\247\220/ReadMe.md" "b/Google Python Style Guide/4. \353\247\272\354\235\214\353\247\220/ReadMe.md"
index c694fe0..cd576e7 100644
--- "a/Google Python Style Guide/4. \353\247\272\354\235\214\353\247\220/ReadMe.md"	
+++ "b/Google Python Style Guide/4. \353\247\272\354\235\214\353\247\220/ReadMe.md"	
@@ -1,9 +1,14 @@
 <h3> 일관성을 유지하세요 </h3>
 
 - 당신이 코드를 수정한다면 몇 분을 투자해서 코드를 살펴보고 스타일을 파악하세요.
-- 만약 모든 산술 연산자에 공백을 넣었다면 당신도 그렇게 해야합니다. 만약 주석이 hash marks(`#`)으로 만든 박스 안에 들어있다면 당신의 주석도 그렇게 해야합니다.
+- 그들이 인덱스 변수 이름에 `_idx` 접미사를 사용하는 경우, 당신도 그렇게 해야 합니다. 만약 주석이 hash marks(`#`)으로 만든 박스 안에 들어있다면 당신의 주석도 그렇게 해야합니다.
+
 - 스타일 가이드라인의 요점은 코딩에서 공통된 어투를 갖는 것입니다. 그렇게 된다면 사람들은 당신의 코딩 형식보다는 당신의 코드에 집중할 수 있습니다
 - 우리는 여기서 사람들이 어휘를 알 수 있는 세계적인 코딩 스타일 규칙을 제공하지만 고유의 스타일도 중요합니다.
-- 파일에 코드를 추가했을 때 이 코드가 다른 코드와 비교하여 크게 달라 보이면 코드를 읽는 사람의 입장에서는 리듬이 깨집니다. 이 부분을 주의하세요.
+- 파일에 코드를 추가했을 때 이 코드가 다른 코드와 비교하여 크게 달라 보이면 코드를 읽는 사람의 입장에서는 리듬이 깨집니다.
+
+- 그러나 일관성에는 한계가 있습니다.
+- 일관성은 주로 지역적으로 적용되며, 전역 스타일에서 명시되지 않은 선택에 더 강하게 적용됩니다.
+- 일관성을 구식 스타일을 고수하는 정당화의 근거로 삼기보다는 새로운 스타일의 장점이나 코드베이스가 시간이 지남에 따라 새로운 스타일로 수렴하는 경향을 고려하는 것이 좋습니다.
 
 ---
diff --git a/Original.md b/Original.md
index 09df969..74d3fab 100644
--- a/Original.md
+++ b/Original.md
@@ -17,7 +17,7 @@ See README.md for details.
     *   [2.2 Imports](#s2.2-imports)
     *   [2.3 Packages](#s2.3-packages)
     *   [2.4 Exceptions](#s2.4-exceptions)
-    *   [2.5 Global variables](#s2.5-global-variables)
+    *   [2.5 Mutable Global State](#s2.5-global-variables)
     *   [2.6 Nested/Local/Inner Classes and Functions](#s2.6-nested)
     *   [2.7 Comprehensions & Generator Expressions](#s2.7-comprehensions)
     *   [2.8 Default Iterators and Operators](#s2.8-default-iterators-and-operators)
@@ -45,7 +45,9 @@ See README.md for details.
     *   [3.8 Comments and Docstrings](#s3.8-comments-and-docstrings)
         +   [3.8.1 Docstrings](#s3.8.1-comments-in-doc-strings)
         +   [3.8.2 Modules](#s3.8.2-comments-in-modules)
+        +   [3.8.2.1 Test modules](#s3.8.2.1-test-modules)
         +   [3.8.3 Functions and Methods](#s3.8.3-functions-and-methods)
+        +   [3.8.3.1 Overridden Methods](#s3.8.3.1-overridden-methods)
         +   [3.8.4 Classes](#s3.8.4-comments-in-classes)
         +   [3.8.5 Block and Inline Comments](#s3.8.5-block-and-inline-comments)
         +   [3.8.6 Punctuation, Spelling, and Grammar](#s3.8.6-punctuation-spelling-and-grammar)
@@ -74,7 +76,7 @@ See README.md for details.
         +   [3.19.7 Ignoring Types](#s3.19.7-ignoring-types)
         +   [3.19.8 Typing Variables](#s3.19.8-typing-variables)
         +   [3.19.9 Tuples vs Lists](#s3.19.9-tuples-vs-lists)
-        +   [3.19.10 TypeVars](#s3.19.10-typevars)
+        +   [3.19.10 Type variables](#s3.19.10-typevars)
         +   [3.19.11 String types](#s3.19.11-string-types)
         +   [3.19.12 Imports For Typing](#s3.19.12-imports-for-typing)
         +   [3.19.13 Conditional Imports](#s3.19.13-conditional-imports)
@@ -96,7 +98,7 @@ of *dos and don'ts* for Python programs.
 
 To help you format code correctly, we've created a [settings file for Vim](google_python_style.vim). For Emacs, the default settings should be fine.
 
-Many teams use the [yapf](https://github.com/google/yapf/)
+Many teams use the [Black](https://github.com/psf/black) or [Pyink](https://github.com/google/pyink)
 auto-formatter to avoid arguing over formatting.
 
 
@@ -160,7 +162,8 @@ Suppress warnings if they are inappropriate so that other issues are not hidden.
 To suppress warnings, you can set a line-level comment:
 
 ```python
-dict = 'something awful'  # Bad Idea... pylint: disable=redefined-builtin
+def do_PUT(self):  # WSGI name, so pylint: disable=invalid-name
+  ...
 ```
 
 `pylint`
@@ -184,7 +187,7 @@ pylint --list-msgs
 To get more information on a particular message, use:
 
 ```shell
-pylint --help-msg=C6409
+pylint --help-msg=invalid-name
 ```
 
 Prefer `pylint: disable` to the deprecated older form `pylint: disable-msg`.
@@ -194,7 +197,7 @@ beginning of the function. Always include a comment explaining why you are
 deleting it. "Unused." is sufficient. For example:
 
 ```python
-def viking_cafe_order(spam: str, beans: str, eggs: Optional[str] = None) -> str:
+def viking_cafe_order(spam: str, beans: str, eggs: str | None = None) -> str:
     del beans, eggs  # Unused by vikings.
     return spam + spam + spam
 ```
@@ -211,13 +214,8 @@ that the arguments are actually unused.
 <a id="imports"></a>
 ### 2.2 Imports 
 
-Use `import` statements for packages and modules only, not for individual
-classes or functions. Classes imported from the
-[typing module](#typing-imports),
-[typing_extensions module](https://github.com/python/typing/tree/master/typing_extensions),
-and redirects from the
-[six.moves module](https://six.readthedocs.io/#module-six.moves)
-are exempt from this rule.
+Use `import` statements for packages and modules only, not for individual types,
+classes, or functions.
 
 <a id="s2.2.1-definition"></a>
 <a id="221-definition"></a>
@@ -254,10 +252,16 @@ Module names can still collide. Some module names are inconveniently long.
 *   Use `import x` for importing packages and modules.
 *   Use `from x import y` where `x` is the package prefix and `y` is the module
     name with no prefix.
-*   Use `from x import y as z` if two modules named `y` are to be imported or if
-    `y` is an inconveniently long name.
-*   Use `import y as z` only when `z` is a standard abbreviation (e.g., `np` for
-    `numpy`).
+*   Use `from x import y as z` in any of the following circumstances:
+    -   Two modules named `y` are to be imported.
+    -   `y` conflicts with a top-level name defined in the current module.
+    -   `y` conflicts with a common parameter name that is part of the public
+        API (e.g., `features`).
+    -   `y` is an inconveniently long name.
+    -   `y` is too generic in the context of your code (e.g., `from
+        storage.file_system import options as fs_options`).
+*   Use `import y as z` only when `z` is a standard abbreviation (e.g., `import
+    numpy as np`).
 
 For example the module `sound.effects.echo` may be imported as follows:
 
@@ -271,6 +275,19 @@ Do not use relative names in imports. Even if the module is in the same package,
 use the full package name. This helps prevent unintentionally importing a
 package twice.
 
+<a id="imports-exemptions"></a>
+##### 2.2.4.1 Exemptions 
+
+Exemptions from this rule:
+
+*   Symbols from the following modules are used to support static analysis and
+    type checking:
+    *   [`typing` module](#typing-imports)
+    *   [`collections.abc` module](#typing-imports)
+    *   [`typing_extensions` module](https://github.com/python/typing_extensions/blob/main/README.md)
+*   Redirects from the
+    [six.moves module](https://six.readthedocs.io/#module-six.moves).
+
 <a id="s2.3-packages"></a>
 <a id="23-packages"></a>
 
@@ -313,7 +330,7 @@ Yes:
   import absl.flags
   from doctor.who import jodie
 
-  FLAGS = absl.flags.FLAGS
+  _FOO = absl.flags.DEFINE_string(...)
 ```
 
 ```python
@@ -322,7 +339,7 @@ Yes:
   from absl import flags
   from doctor.who import jodie
 
-  FLAGS = flags.FLAGS
+  _FOO = flags.DEFINE_string(...)
 ```
 
 *(assume this file lives in `doctor/who/` where `jodie.py` also exists)*
@@ -337,7 +354,7 @@ No:
 
 The directory the main binary is located in should not be assumed to be in
 `sys.path` despite that happening in some environments. This being the case,
-code should assume that `import jodie` refers to a third party or top level
+code should assume that `import jodie` refers to a third-party or top-level
 package named `jodie`, not a local `jodie.py`.
 
 
@@ -388,11 +405,15 @@ Exceptions must follow certain conditions:
 
 -   Make use of built-in exception classes when it makes sense. For example,
     raise a `ValueError` to indicate a programming mistake like a violated
-    precondition (such as if you were passed a negative number but required a
-    positive one). Do not use `assert` statements for validating argument values
-    of a public API. `assert` is used to ensure internal correctness, not to
-    enforce correct usage nor to indicate that some unexpected event occurred.
-    If an exception is desired in the latter cases, use a raise statement. For
+    precondition, such as may happen when validating function arguments.
+
+-   Do not use `assert` statements in place of conditionals or validating
+    preconditions. They must not be critical to the application logic. A litmus
+    test would be that the `assert` could be removed without breaking the code.
+    `assert` conditionals are
+    [not guaranteed](https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement)
+    to be evaluated. For [pytest](https://pytest.org) based tests, `assert` is
+    okay and expected to verify expectations. For
     example:
 
     
@@ -416,9 +437,10 @@ Exceptions must follow certain conditions:
           # guarantee this specific behavioral reaction to API misuse.
           raise ValueError(f'Min. port must be at least 1024, not {minimum}.')
         port = self._find_next_open_port(minimum)
-        if not port:
+        if port is None:
           raise ConnectionError(
               f'Could not connect to service on port {minimum} or higher.')
+        # The code does not depend on the result of this assert.
         assert port >= minimum, (
             f'Unexpected port {port} when minimum was {minimum}.')
         return port
@@ -436,8 +458,10 @@ Exceptions must follow certain conditions:
           The new minimum port.
         """
         assert minimum >= 1024, 'Minimum port must be at least 1024.'
+        # The following code depends on the previous assert.
         port = self._find_next_open_port(minimum)
         assert port is not None
+        # The type checking of the return statement relies on the assert.
         return port
     ```
 
@@ -470,11 +494,13 @@ Exceptions must follow certain conditions:
 
 <a id="s2.5-global-variables"></a>
 <a id="25-global-variables"></a>
+<a id="s2.5-global-state"></a>
+<a id="25-global-state"></a>
 
 <a id="global-variables"></a>
-### 2.5 Global variables 
+### 2.5 Mutable Global State 
 
-Avoid global variables.
+Avoid mutable global state.
 
 <a id="s2.5.1-definition"></a>
 <a id="251-definition"></a>
@@ -482,7 +508,8 @@ Avoid global variables.
 <a id="global-variables-definition"></a>
 #### 2.5.1 Definition 
 
-Variables that are declared at the module level or as class attributes.
+Module-level values or class attributes that can get mutated during program
+execution.
 
 <a id="s2.5.2-pros"></a>
 <a id="252-pros"></a>
@@ -498,8 +525,14 @@ Occasionally useful.
 <a id="global-variables-cons"></a>
 #### 2.5.3 Cons 
 
-Has the potential to change module behavior during the import, because
-assignments to global variables are done when the module is first imported.
+*   Breaks encapsulation: Such design can make it hard to achieve valid
+    objectives. For example, if global state is used to manage a database
+    connection, then connecting to two different databases at the same time
+    (such as for computing differences during a migration) becomes difficult.
+    Similar problems easily arise with global registries.
+
+*   Has the potential to change module behavior during the import, because
+    assignments to global variables are done when the module is first imported.
 
 <a id="s2.5.4-decision"></a>
 <a id="254-decision"></a>
@@ -507,15 +540,20 @@ assignments to global variables are done when the module is first imported.
 <a id="global-variables-decision"></a>
 #### 2.5.4 Decision 
 
-Avoid global variables.
+Avoid mutable global state.
 
-While they are technically variables, module-level constants are permitted and
-encouraged. For example: `_MAX_HOLY_HANDGRENADE_COUNT = 3`. Constants must be
-named using all caps with underscores. See [Naming](#s3.16-naming) below.
+In those rare cases where using global state is warranted, mutable global
+entities should be declared at the module level or as a class attribute and made
+internal by prepending an `_` to the name. If necessary, external access to
+mutable global state must be done through public functions or class methods. See
+[Naming](#s3.16-naming) below. Please explain the design reasons why mutable
+global state is being used in a comment or a doc linked to from a comment.
 
-If needed, globals should be declared at the module level and made internal to
-the module by prepending an `_` to the name. External access must be done
-through public module-level functions. See [Naming](#s3.16-naming) below.
+Module-level constants are permitted and encouraged. For example:
+`_MAX_HOLY_HANDGRENADE_COUNT = 3` for an internal use constant or
+`SIR_LANCELOTS_FAVORITE_COLOR = "blue"` for a public API constant. Constants
+must be named using all caps with underscores. See [Naming](#s3.16-naming)
+below.
 
 <a id="s2.6-nested"></a>
 <a id="26-nested"></a>
@@ -544,8 +582,8 @@ variables defined in enclosing scopes.
 
 Allows definition of utility classes and functions that are only used inside of
 a very limited scope. Very
-[ADT](http://www.google.com/url?sa=D&q=http://en.wikipedia.org/wiki/Abstract_data_type)-y.
-Commonly used for implementing decorators.
+[ADT](https://en.wikipedia.org/wiki/Abstract_data_type)-y. Commonly used for
+implementing decorators.
 
 <a id="s2.6.3-cons"></a>
 <a id="263-cons"></a>
@@ -612,20 +650,18 @@ Complicated comprehensions or generator expressions can be hard to read.
 <a id="comprehensions-decision"></a>
 #### 2.7.4 Decision 
 
-Okay to use for simple cases. Each portion must fit on one line: mapping
-expression, `for` clause, filter expression. Multiple `for` clauses or filter
-expressions are not permitted. Use loops instead when things get more
-complicated.
+Comprehensions are allowed, however multiple `for` clauses or filter expressions
+are not permitted. Optimize for readability, not conciseness.
 
 ```python
 Yes:
   result = [mapping_expr for value in iterable if filter_expr]
 
-  result = [{'key': value} for value in iterable
-            if a_long_filter_expression(value)]
-
-  result = [complicated_transform(x)
-            for x in iterable if predicate(x)]
+  result = [
+      is_valid(metric={'key': value})
+      for value in interesting_iterable
+      if a_longer_filter_expression(value)
+  ]
 
   descriptive_name = [
       transform({'key': key, 'value': value}, color='black')
@@ -635,36 +671,33 @@ Yes:
 
   result = []
   for x in range(10):
-      for y in range(5):
-          if x * y > 10:
-              result.append((x, y))
-
-  return {x: complicated_transform(x)
-          for x in long_generator_function(parameter)
-          if x is not None}
+    for y in range(5):
+      if x * y > 10:
+        result.append((x, y))
+
+  return {
+      x: complicated_transform(x)
+      for x in long_generator_function(parameter)
+      if x is not None
+  }
 
-  squares_generator = (x**2 for x in range(10))
+  return (x**2 for x in range(10))
 
   unique_names = {user.name for user in users if user is not None}
-
-  eat(jelly_bean for jelly_bean in jelly_beans
-      if jelly_bean.color == 'black')
 ```
 
 ```python
 No:
-  result = [complicated_transform(
-                x, some_argument=x+1)
-            for x in iterable if predicate(x)]
-
   result = [(x, y) for x in range(10) for y in range(5) if x * y > 10]
 
-  return ((x, y, z)
-          for x in range(5)
-          for y in range(5)
-          if x != y
-          for z in range(5)
-          if y != z)
+  return (
+      (x, y, z)
+      for x in range(5)
+      for y in range(5)
+      if x != y
+      for z in range(5)
+      if y != z
+  )
 ```
 
 <a id="s2.8-default-iterators-and-operators"></a>
@@ -700,8 +733,8 @@ operators is generic. It can be used with any type that supports the operation.
 <a id="default-iterators-operators-cons"></a>
 #### 2.8.3 Cons 
 
-You can't tell the type of objects by reading the method names (e.g. `has_key()`
-means a dictionary). This is also an advantage.
+You can't tell the type of objects by reading the method names (unless the
+variable has type annotations). This is also an advantage.
 
 <a id="s2.8.4-decision"></a>
 <a id="284-decision"></a>
@@ -716,18 +749,14 @@ container while iterating over it.
 
 ```python
 Yes:  for key in adict: ...
-      if key not in adict: ...
       if obj in alist: ...
       for line in afile: ...
       for k, v in adict.items(): ...
-      for k, v in six.iteritems(adict): ...
 ```
 
 ```python
 No:   for key in adict.keys(): ...
-      if not adict.has_key(key): ...
       for line in afile.readlines(): ...
-      for k, v in dict.iteritems(): ...
 ```
 
 <a id="s2.9-generators"></a>
@@ -742,7 +771,7 @@ Use generators as needed.
 <a id="291-definition"></a>
 
 <a id="generators-definition"></a>
-#### 2.9 Definition 
+#### 2.9.1 Definition 
 
 A generator function returns an iterator that yields a value each time it
 executes a yield statement. After it yields a value, the runtime state of the
@@ -764,7 +793,8 @@ creates an entire list of values at once.
 <a id="generators-cons"></a>
 #### 2.9.3 Cons 
 
-None.
+Local variables in the generator will not be garbage collected until the
+generator is either consumed to exhaustion or itself garbage collected.
 
 <a id="s2.9.4-decision"></a>
 <a id="294-decision"></a>
@@ -775,6 +805,11 @@ None.
 Fine. Use "Yields:" rather than "Returns:" in the docstring for generator
 functions.
 
+If the generator manages an expensive resource, make sure to force the clean up.
+
+A good way to do the clean up is by wrapping the generator with a context
+manager [PEP-0533](https://peps.python.org/pep-0533/).
+
 <a id="s2.10-lambda-functions"></a>
 <a id="210-lambda-functions"></a>
 
@@ -816,8 +851,8 @@ function may only contain an expression.
 <a id="lambdas-decision"></a>
 #### 2.10.4 Decision 
 
-Okay to use them for one-liners. If the code inside the lambda function is
-longer than 60-80 chars, it's probably better to define it as a regular
+Lambdas are allowed. If the code inside the lambda function spans multiple lines
+or is longer than 60-80 chars, it might be better to define it as a regular
 [nested function](#lexical-scoping).
 
 For common operations like multiplication, use the functions from the `operator`
@@ -947,21 +982,24 @@ definition.
 Yes: def foo(a, b=None):
          if b is None:
              b = []
-Yes: def foo(a, b: Optional[Sequence] = None):
+Yes: def foo(a, b: Sequence | None = None):
          if b is None:
              b = []
-Yes: def foo(a, b: Sequence = ()):  # Empty tuple OK since tuples are immutable
+Yes: def foo(a, b: Sequence = ()):  # Empty tuple OK since tuples are immutable.
          ...
 ```
 
 ```python
+from absl import flags
+_FOO = flags.DEFINE_string(...)
+
 No:  def foo(a, b=[]):
          ...
-No:  def foo(a, b=time.time()):  # The time the module was loaded???
+No:  def foo(a, b=time.time()):  # Is `b` supposed to represent when this module was loaded?
          ...
-No:  def foo(a, b=FLAGS.my_thing):  # sys.argv has not yet been parsed...
+No:  def foo(a, b=_FOO.value):  # sys.argv has not yet been parsed...
          ...
-No:  def foo(a, b: Mapping = {}):  # Could still get passed to unchecked code
+No:  def foo(a, b: Mapping = {}):  # Could still get passed to unchecked code.
          ...
 ```
 
@@ -1036,7 +1074,7 @@ implement computations a subclass may ever want to override and extend.
 <a id="truefalse-evaluations"></a>
 ### 2.14 True/False Evaluations 
 
-Use the "implicit" false if at all possible.
+Use the "implicit" false if at all possible (with a few caveats).
 
 <a id="s2.14.1-definition"></a>
 <a id="2141-definition"></a>
@@ -1168,8 +1206,8 @@ experienced Lisp and Scheme (and Haskell and ML and ...) programmers.
 <a id="lexical-scoping-cons"></a>
 #### 2.16.3 Cons 
 
-Can lead to confusing bugs. Such as this example based on
-[PEP-0227](http://www.google.com/url?sa=D&q=http://www.python.org/dev/peps/pep-0227/):
+Can lead to confusing bugs, such as this example based on
+[PEP-0227](https://peps.python.org/pep-0227/):
 
 ```python
 i = 4
@@ -1271,13 +1309,13 @@ decorator runs (at import time, perhaps from `pydoc` or other tools). A
 decorator that is called with valid parameters should (as much as possible) be
 guaranteed to succeed in all cases.
 
-Decorators are a special case of "top level code" - see [main](#s3.17-main) for
+Decorators are a special case of "top-level code" - see [main](#s3.17-main) for
 more discussion.
 
 Never use `staticmethod` unless forced to in order to integrate with an API
-defined in an existing library. Write a module level function instead.
+defined in an existing library. Write a module-level function instead.
 
-Use `classmethod` only when writing a named constructor or a class-specific
+Use `classmethod` only when writing a named constructor, or a class-specific
 routine that modifies necessary global state such as a process-wide cache.
 
 <a id="s2.18-threading"></a>
@@ -1294,8 +1332,8 @@ or `__eq__` are implemented as Python methods) and their atomicity should not be
 relied upon. Neither should you rely on atomic variable assignment (since this
 in turn depends on dictionaries).
 
-Use the Queue module's `Queue` data type as the preferred way to communicate
-data between threads. Otherwise, use the threading module and its locking
+Use the `queue` module's `Queue` data type as the preferred way to communicate
+data between threads. Otherwise, use the `threading` module and its locking
 primitives. Prefer condition variables and `threading.Condition` instead of
 using lower-level locks.
 
@@ -1410,14 +1448,6 @@ In code that may execute on versions as old as 3.5 rather than >= 3.7, import:
 from __future__ import generator_stop
 ```
 
-For legacy code with the burden of continuing to support 2.7, import:
-
-```python
-from __future__ import absolute_import
-from __future__ import division
-from __future__ import print_function
-```
-
 For more information read the
 [Python future statement definitions](https://docs.python.org/3/library/__future__.html)
 documentation.
@@ -1428,19 +1458,7 @@ feature a specific future import enables in your code today, keeping it in place
 in the file prevents later modifications of the code from inadvertently
 depending on the older behavior.
 
-Use other `from __future__` import statements as you see fit. We did not include
-`unicode_literals` in our recommendations for 2.7 as it was not a clear win due
-to implicit default codec conversion consequences it introduced in many places
-within 2.7. Most dual-version 2-and-3 code was better off with explicit use of
-`b''` and `u''` bytes and unicode string literals where necessary.
-
-##### The six, future, and past libraries
-
-When your project still needs to support use under both Python 2 and 3, use the
-[six](https://pypi.org/project/six/),
-[future](https://pypi.org/project/future/), and
-[past](https://pypi.org/project/past/) libraries as you see fit. They exist to
-make your code cleaner and life easier.
+Use other `from __future__` import statements as you see fit.
 
 <a id="s2.21-type-annotated-code"></a>
 <a id="s2.21-typed-code"></a>
@@ -1450,13 +1468,12 @@ make your code cleaner and life easier.
 <a id="typed-code"></a>
 ### 2.21 Type Annotated Code 
 
-You can annotate Python 3 code with type hints according to
-[PEP-484](https://www.python.org/dev/peps/pep-0484/), and type-check the code at
-build time with a type checking tool like [pytype](https://github.com/google/pytype).
-
+You can annotate Python code with type hints according to
+[PEP-484](https://peps.python.org/pep-0484/), and type-check the code at build
+time with a type checking tool like [pytype](https://github.com/google/pytype).
 
 Type annotations can be in the source or in a
-[stub pyi file](https://www.python.org/dev/peps/pep-0484/#stub-files). Whenever
+[stub pyi file](https://peps.python.org/pep-0484/#stub-files). Whenever
 possible, annotations should be in the source. Use pyi files for third-party or
 extension modules.
 
@@ -1471,22 +1488,16 @@ Type annotations (or "type hints") are for function or method arguments and
 return values:
 
 ```python
-def func(a: int) -> List[int]:
+def func(a: int) -> list[int]:
 ```
 
 You can also declare the type of a variable using similar
-[PEP-526](https://www.python.org/dev/peps/pep-0526/) syntax:
+[PEP-526](https://peps.python.org/pep-0526/) syntax:
 
 ```python
 a: SomeType = some_func()
 ```
 
-Or by using a type comment in code that must support legacy Python versions.
-
-```python
-a = some_func()  # type: SomeType
-```
-
 <a id="s2.21.2-pros"></a>
 <a id="2212-pros"></a>
 
@@ -1552,23 +1563,53 @@ Explicit exceptions to the 80 character limit:
 
 -   Long import statements.
 -   URLs, pathnames, or long flags in comments.
--   Long string module level constants not containing whitespace that would be
+-   Long string module-level constants not containing whitespace that would be
     inconvenient to split across lines such as URLs or pathnames.
     -   Pylint disable comments. (e.g.: `# pylint: disable=invalid-name`)
 
-Do not use backslash line continuation except for `with` statements requiring
-three or more context managers.
+Do not use a backslash for
+[explicit line continuation](https://docs.python.org/3/reference/lexical_analysis.html#explicit-line-joining).
 
-Make use of Python's
+Instead, make use of Python's
 [implicit line joining inside parentheses, brackets and braces](http://docs.python.org/reference/lexical_analysis.html#implicit-line-joining).
 If necessary, you can add an extra pair of parentheses around an expression.
 
+Note that this rule doesn't prohibit backslash-escaped newlines within strings
+(see [below](#strings)).
+
 ```python
 Yes: foo_bar(self, width, height, color='black', design=None, x='foo',
              emphasis=None, highlight=0)
+```
 
-     if (width == 0 and height == 0 and
+```python
+
+Yes: if (width == 0 and height == 0 and
          color == 'red' and emphasis == 'strong'):
+
+     (bridge_questions.clarification_on
+      .average_airspeed_of.unladen_swallow) = 'African or European?'
+
+     with (
+         very_long_first_expression_function() as spam,
+         very_long_second_expression_function() as beans,
+         third_thing() as eggs,
+     ):
+       place_order(eggs, beans, spam, beans)
+```
+
+```python
+
+No:  if width == 0 and height == 0 and \
+         color == 'red' and emphasis == 'strong':
+
+     bridge_questions.clarification_on \
+         .average_airspeed_of.unladen_swallow = 'African or European?'
+
+     with very_long_first_expression_function() as spam, \
+           very_long_second_expression_function() as beans, \
+           third_thing() as eggs:
+       place_order(eggs, beans, spam, beans)
 ```
 
 When a literal string won't fit on a single line, use parentheses for implicit
@@ -1579,47 +1620,55 @@ x = ('This will build a very long long '
      'long long long long long long string')
 ```
 
-Within comments, put long URLs on their own line if necessary.
+Prefer to break lines at the highest possible syntactic level. If you must break
+a line twice, break it at the same syntactic level both times.
 
 ```python
-Yes:  # See details at
-      # http://www.example.com/us/developer/documentation/api/content/v2.0/csv_file_name_extension_full_specification.html
+Yes: bridgekeeper.answer(
+         name="Arthur", quest=questlib.find(owner="Arthur", perilous=True))
+
+     answer = (a_long_line().of_chained_methods()
+               .that_eventually_provides().an_answer())
+
+     if (
+         config is None
+         or 'editor.language' not in config
+         or config['editor.language'].use_spaces is False
+     ):
+       use_tabs()
 ```
 
 ```python
-No:  # See details at
-     # http://www.example.com/us/developer/documentation/api/content/\
-     # v2.0/csv_file_name_extension_full_specification.html
-```
+No: bridgekeeper.answer(name="Arthur", quest=questlib.find(
+        owner="Arthur", perilous=True))
 
-It is permissible to use backslash continuation when defining a `with` statement
-whose expressions span three or more lines. For two lines of expressions, use a
-nested `with` statement:
+    answer = a_long_line().of_chained_methods().that_eventually_provides(
+        ).an_answer()
+
+    if (config is None or 'editor.language' not in config or config[
+        'editor.language'].use_spaces is False):
+      use_tabs()
 
-```python
-Yes:  with very_long_first_expression_function() as spam, \
-           very_long_second_expression_function() as beans, \
-           third_thing() as eggs:
-          place_order(eggs, beans, spam, beans)
 ```
 
+Within comments, put long URLs on their own line if necessary.
+
 ```python
-No:  with VeryLongFirstExpressionFunction() as spam, \
-          VeryLongSecondExpressionFunction() as beans:
-       PlaceOrder(beans, spam)
+Yes:  # See details at
+      # http://www.example.com/us/developer/documentation/api/content/v2.0/csv_file_name_extension_full_specification.html
 ```
 
 ```python
-Yes:  with very_long_first_expression_function() as spam:
-          with very_long_second_expression_function() as beans:
-              place_order(beans, spam)
+No:  # See details at
+     # http://www.example.com/us/developer/documentation/api/content/\
+     # v2.0/csv_file_name_extension_full_specification.html
 ```
 
 Make note of the indentation of the elements in the line continuation examples
 above; see the [indentation](#s3.4-indentation) section for explanation.
 
 In all other cases where a line exceeds 80 characters, and the
-[yapf](https://github.com/google/yapf/)
+[Black](https://github.com/psf/black) or [Pyink](https://github.com/google/pyink)
 auto-formatter does not help bring the line below the limit, the line is allowed
 to exceed this maximum. Authors are encouraged to manually break the line up per
 the notes above when it is sensible.
@@ -1669,27 +1718,27 @@ No:  if (x):
 
 Indent your code blocks with *4 spaces*.
 
-Never use tabs or mix tabs and spaces. In cases of implied line continuation,
-you should align wrapped elements either vertically, as per the examples in the
-[line length](#s3.2-line-length) section; or using a hanging indent of 4 spaces,
-in which case there should be nothing after the open parenthesis or bracket on
-the first line.
+Never use tabs. Implied line continuation should align wrapped elements
+vertically (see [line length examples](#s3.2-line-length)), or use a hanging
+4-space indent. Closing (round, square or curly) brackets can be placed at the
+end of the expression, or on separate lines, but then should be indented the
+same as the line with the corresponding opening bracket.
 
 ```python
-Yes:   # Aligned with opening delimiter
+Yes:   # Aligned with opening delimiter.
        foo = long_function_name(var_one, var_two,
                                 var_three, var_four)
        meal = (spam,
                beans)
 
-       # Aligned with opening delimiter in a dictionary
+       # Aligned with opening delimiter in a dictionary.
        foo = {
            'long_dictionary_key': value1 +
                                   value2,
            ...
        }
 
-       # 4-space hanging indent; nothing on first line
+       # 4-space hanging indent; nothing on first line.
        foo = long_function_name(
            var_one, var_two, var_three,
            var_four)
@@ -1697,7 +1746,18 @@ Yes:   # Aligned with opening delimiter
            spam,
            beans)
 
-       # 4-space hanging indent in a dictionary
+       # 4-space hanging indent; nothing on first line,
+       # closing parenthesis on a new line.
+       foo = long_function_name(
+           var_one, var_two, var_three,
+           var_four
+       )
+       meal = (
+           spam,
+           beans,
+       )
+
+       # 4-space hanging indent in a dictionary.
        foo = {
            'long_dictionary_key':
                long_dictionary_value,
@@ -1706,18 +1766,18 @@ Yes:   # Aligned with opening delimiter
 ```
 
 ```python
-No:    # Stuff on first line forbidden
+No:    # Stuff on first line forbidden.
        foo = long_function_name(var_one, var_two,
            var_three, var_four)
        meal = (spam,
            beans)
 
-       # 2-space hanging indent forbidden
+       # 2-space hanging indent forbidden.
        foo = long_function_name(
          var_one, var_two, var_three,
          var_four)
 
-       # No hanging indent in a dictionary
+       # No hanging indent in a dictionary.
        foo = {
            'long_dictionary_key':
            long_dictionary_value,
@@ -1739,13 +1799,15 @@ No:    # Stuff on first line forbidden
 
 Trailing commas in sequences of items are recommended only when the closing
 container token `]`, `)`, or `}` does not appear on the same line as the final
-element. The presence of a trailing comma is also used as a hint to our Python
-code auto-formatter [YAPF](https://pypi.org/project/yapf/) to direct it to auto-format the container
-of items to one item per line when the `,` after the final element is present.
+element, as well as for tuples with a single element. The presence of a trailing
+comma is also used as a hint to our Python code auto-formatter
+[Black](https://github.com/psf/black) or [Pyink](https://github.com/google/pyink)
+to direct it to auto-format the container of items to one item per line when the
+`,` after the final element is present.
 
 ```python
 Yes:   golomb3 = [0, 1, 3]
-Yes:   golomb4 = [
+       golomb4 = [
            0,
            1,
            4,
@@ -1758,8 +1820,7 @@ No:    golomb4 = [
            0,
            1,
            4,
-           6
-       ]
+           6,]
 ```
 
 <a id="s3.5-blank-lines"></a>
@@ -1769,9 +1830,9 @@ No:    golomb4 = [
 ### 3.5 Blank Lines 
 
 Two blank lines between top-level definitions, be they function or class
-definitions. One blank line between method definitions and between the `class`
-line and the first method. No blank line following a `def` line. Use single
-blank lines as you judge appropriate within functions or methods.
+definitions. One blank line between method definitions and between the docstring
+of a `class` and the first method. No blank line following a `def` line. Use
+single blank lines as you judge appropriate within functions or methods.
 
 Blank lines need not be anchored to the definition. For example, related
 comments immediately preceding function, class, and method definitions can make
@@ -1895,7 +1956,7 @@ No:
 Most `.py` files do not need to start with a `#!` line. Start the main file of a
 program with
 `#!/usr/bin/env python3` (to support virtualenvs) or `#!/usr/bin/python3` per
-[PEP-394](https://www.python.org/dev/peps/pep-0394/).
+[PEP-394](https://peps.python.org/pep-0394/).
 
 This line is used by the kernel to find the Python interpreter, but is ignored by Python when importing modules. It is only necessary on a file intended to be executed directly.
 
@@ -1920,15 +1981,14 @@ Python uses *docstrings* to document code. A docstring is a string that is the
 first statement in a package, module, class or function. These strings can be
 extracted automatically through the `__doc__` member of the object and are used
 by `pydoc`.
-(Try running `pydoc` on your module to see how it looks.) Always use the three
-double-quote `"""` format for docstrings (per
-[PEP 257](https://www.google.com/url?sa=D&q=http://www.python.org/dev/peps/pep-0257/)).
-A docstring should be organized as a summary line (one physical line not
-exceeding 80 characters) terminated by a period, question mark, or exclamation
-point. When writing more (encouraged), this must be followed by a blank line,
-followed by the rest of the docstring starting at the same cursor position as
-the first quote of the first line. There are more formatting guidelines for
-docstrings below.
+(Try running `pydoc` on your module to see how it looks.) Always use the
+three-double-quote `"""` format for docstrings (per
+[PEP 257](https://peps.python.org/pep-0257/)). A docstring should be organized
+as a summary line (one physical line not exceeding 80 characters) terminated by
+a period, question mark, or exclamation point. When writing more (encouraged),
+this must be followed by a blank line, followed by the rest of the docstring
+starting at the same cursor position as the first quote of the first line. There
+are more formatting guidelines for docstrings below.
 
 <a id="s3.8.2-comments-in-modules"></a>
 <a id="382-modules"></a>
@@ -1937,19 +1997,19 @@ docstrings below.
 <a id="module-docs"></a>
 #### 3.8.2 Modules 
 
-Every file should contain license boilerplate. Choose the appropriate boilerplate for the license used by the project (for example, Apache 2.0, BSD, LGPL, GPL)
+Every file should contain license boilerplate. Choose the appropriate boilerplate for the license used by the project (for example, Apache 2.0, BSD, LGPL, GPL).
 
 Files should start with a docstring describing the contents and usage of the
 module.
 ```python
-"""A one line summary of the module or program, terminated by a period.
+"""A one-line summary of the module or program, terminated by a period.
 
 Leave one blank line.  The rest of this docstring should contain an
 overall description of the module or program.  Optionally, it may also
 contain a brief description of exported classes and functions and/or usage
 examples.
 
-  Typical usage example:
+Typical usage example:
 
   foo = ClassFoo()
   bar = foo.FunctionBar()
@@ -1957,6 +2017,32 @@ examples.
 ```
 
 
+<a id="s3.8.2.1-test-modules"></a>
+
+<a id="test-docs"></a>
+##### 3.8.2.1 Test modules 
+
+Module-level docstrings for test files are not required. They should be included
+only when there is additional information that can be provided.
+
+Examples include some specifics on how the test should be run, an explanation of
+an unusual setup pattern, dependency on the external environment, and so on.
+
+```python
+"""This blaze test uses golden files.
+
+You can update those files by running
+`blaze run //foo/bar:foo_test -- --update_golden_files` from the `google3`
+directory.
+"""
+```
+
+Docstrings that do not provide any new information should not be used.
+
+```python
+"""Tests for foo.bar."""
+```
+
 <a id="s3.8.3-functions-and-methods"></a>
 <a id="383-functions-and-methods"></a>
 <a id="functions-and-methods"></a>
@@ -1964,13 +2050,14 @@ examples.
 <a id="function-docs"></a>
 #### 3.8.3 Functions and Methods 
 
-In this section, "function" means a method, function, or generator.
+In this section, "function" means a method, function, generator, or property.
 
-A function must have a docstring, unless it meets all of the following criteria:
+A docstring is mandatory for every function that has one or more of the
+following properties:
 
--   not externally visible
--   very short
--   obvious
+-   being part of the public API
+-   nontrivial size
+-   non-obvious logic
 
 A docstring should give enough information to write a call to the function
 without reading the function's code. The docstring should describe the
@@ -1982,22 +2069,13 @@ details of a function's implementation that are not relevant to the caller are
 better expressed as comments alongside the code than within the function's
 docstring.
 
-The docstring should be descriptive-style (`"""Fetches rows from a
-Bigtable."""`) rather than imperative-style (`"""Fetch rows from a
-Bigtable."""`). The docstring for a `@property` data descriptor should use the
-same style as the docstring for an attribute or a
+The docstring may be descriptive-style (`"""Fetches rows from a Bigtable."""`)
+or imperative-style (`"""Fetch rows from a Bigtable."""`), but the style should
+be consistent within a file. The docstring for a `@property` data descriptor
+should use the same style as the docstring for an attribute or a
 <a href="#doc-function-args">function argument</a> (`"""The Bigtable path."""`,
 rather than `"""Returns the Bigtable path."""`).
 
-A method that overrides a method from a base class may have a simple docstring
-sending the reader to its overridden method's docstring, such as `"""See base
-class."""`. The rationale is that there is no need to repeat in many places
-documentation that is already present in the base method's docstring. However,
-if the overriding method's behavior is substantially different from the
-overridden method, or details need to be provided (e.g., documenting additional
-side effects), a docstring with at least those differences is required on the
-overriding method.
-
 Certain aspects of a function should be documented in special sections, listed
 below. Each section begins with a heading line, which ends with a colon. All
 sections other than the heading should maintain a hanging indent of two or four
@@ -2018,18 +2096,21 @@ aptly described using a one-line docstring.
 
 <a id="doc-function-returns"></a>
 [*Returns:* (or *Yields:* for generators)](#doc-function-returns)
-:   Describe the type and semantics of the return value. If the function only
-    returns None, this section is not required. It may also be omitted if the
-    docstring starts with Returns or Yields (e.g. `"""Returns row from Bigtable
-    as a tuple of strings."""`) and the opening sentence is sufficient to
-    describe the return value. Do not imitate 'NumPy style'
-    ([example](http://numpy.org/doc/stable/reference/generated/numpy.linalg.qr.html)),
-    which frequently documents a tuple return value as if it were multiple
+:   Describe the semantics of the return value, including any type information
+    that the type annotation does not provide. If the function only returns
+    None, this section is not required. It may also be omitted if the docstring
+    starts with "Return", "Returns", "Yield", or "Yields" (e.g. `"""Returns row
+    from Bigtable as a tuple of strings."""`) *and* the opening sentence is
+    sufficient to describe the return value. Do not imitate older 'NumPy style'
+    ([example](https://numpy.org/doc/1.24/reference/generated/numpy.linalg.qr.html)),
+    which frequently documented a tuple return value as if it were multiple
     return values with individual names (never mentioning the tuple). Instead,
-    describe such a return value as: "Returns a tuple (mat_a, mat_b), where
+    describe such a return value as: "Returns: A tuple (mat_a, mat_b), where
     mat_a is ..., and ...". The auxiliary names in the docstring need not
     necessarily correspond to any internal names used in the function body (as
-    those are not part of the API).
+    those are not part of the API). If the function uses `yield` (is a
+    generator), the `Yields:` section should document the object returned by
+    `next()`, instead of the generator object itself that the call evaluates to.
 
 <a id="doc-function-raises"></a>
 [*Raises:*](#doc-function-raises)
@@ -2041,10 +2122,11 @@ aptly described using a one-line docstring.
     part of the API).
 
 ```python
-def fetch_smalltable_rows(table_handle: smalltable.Table,
-                          keys: Sequence[Union[bytes, str]],
-                          require_all_keys: bool = False,
-) -> Mapping[bytes, Tuple[str, ...]]:
+def fetch_smalltable_rows(
+    table_handle: smalltable.Table,
+    keys: Sequence[bytes | str],
+    require_all_keys: bool = False,
+) -> Mapping[bytes, tuple[str, ...]]:
     """Fetches rows from a Smalltable.
 
     Retrieves rows pertaining to the given keys from the Table instance
@@ -2078,10 +2160,11 @@ def fetch_smalltable_rows(table_handle: smalltable.Table,
 Similarly, this variation on `Args:` with a line break is also allowed:
 
 ```python
-def fetch_smalltable_rows(table_handle: smalltable.Table,
-                          keys: Sequence[Union[bytes, str]],
-                          require_all_keys: bool = False,
-) -> Mapping[bytes, Tuple[str, ...]]:
+def fetch_smalltable_rows(
+    table_handle: smalltable.Table,
+    keys: Sequence[bytes | str],
+    require_all_keys: bool = False,
+) -> Mapping[bytes, tuple[str, ...]]:
     """Fetches rows from a Smalltable.
 
     Retrieves rows pertaining to the given keys from the Table instance
@@ -2114,6 +2197,47 @@ def fetch_smalltable_rows(table_handle: smalltable.Table,
     """
 ```
 
+<a id="s3.8.3.1-overridden-methods"></a>
+
+<a id="overridden-method-docs"></a>
+##### 3.8.3.1 Overridden Methods 
+
+A method that overrides a method from a base class does not need a docstring if
+it is explicitly decorated with
+[`@override`](https://typing-extensions.readthedocs.io/en/latest/#override)
+(from `typing_extensions` or `typing` modules), unless the overriding method's
+behavior materially refines the base method's contract, or details need to be
+provided (e.g., documenting additional side effects), in which case a docstring
+with at least those differences is required on the overriding method.
+
+```python
+from typing_extensions import override
+
+class Parent:
+  def do_something(self):
+    """Parent method, includes docstring."""
+
+# Child class, method annotated with override.
+class Child(Parent):
+  @override
+  def do_something(self):
+    pass
+```
+
+```python
+# Child class, but without @override decorator, a docstring is required.
+class Child(Parent):
+  def do_something(self):
+    pass
+
+# Docstring is trivial, @override is sufficient to indicate that docs can be
+# found in the base class.
+class Child(Parent):
+  @override
+  def do_something(self):
+    """See base class."""
+```
+
 <a id="s3.8.4-comments-in-classes"></a>
 <a id="384-classes"></a>
 <a id="comments-in-classes"></a>
@@ -2122,16 +2246,16 @@ def fetch_smalltable_rows(table_handle: smalltable.Table,
 #### 3.8.4 Classes 
 
 Classes should have a docstring below the class definition describing the class.
-If your class has public attributes, they should be documented here in an
-`Attributes` section and follow the same formatting as a
+Public attributes, excluding [properties](#properties), should be documented
+here in an `Attributes` section and follow the same formatting as a
 [function's `Args`](#doc-function-args) section.
 
 ```python
 class SampleClass:
     """Summary of class here.
 
-    Longer class information....
-    Longer class information....
+    Longer class information...
+    Longer class information...
 
     Attributes:
         likes_spam: A boolean indicating if we like SPAM or not.
@@ -2139,12 +2263,47 @@ class SampleClass:
     """
 
     def __init__(self, likes_spam: bool = False):
-        """Inits SampleClass with blah."""
+        """Initializes the instance based on spam preference.
+
+        Args:
+          likes_spam: Defines if instance exhibits this preference.
+        """
         self.likes_spam = likes_spam
         self.eggs = 0
 
-    def public_method(self):
-        """Performs operation blah."""
+    @property
+    def butter_sticks(self) -> int:
+        """The number of butter sticks we have."""
+```
+
+All class docstrings should start with a one-line summary that describes what
+the class instance represents. This implies that subclasses of `Exception`
+should also describe what the exception represents, and not the context in which
+it might occur. The class docstring should not repeat unnecessary information,
+such as that the class is a class.
+
+```python
+# Yes:
+class CheeseShopAddress:
+  """The address of a cheese shop.
+
+  ...
+  """
+
+class OutOfCheeseError(Exception):
+  """No more cheese is available."""
+```
+
+```python
+# No:
+class CheeseShopAddress:
+  """Class that describes the address of a cheese shop.
+
+  ...
+  """
+
+class OutOfCheeseError(Exception):
+  """Raised when no more cheese is available."""
 ```
 
 <a id="s3.8.5-block-and-inline-comments"></a>
@@ -2215,23 +2374,21 @@ punctuation, spelling, and grammar help with that goal.
 Use an
 [f-string](https://docs.python.org/3/reference/lexical_analysis.html#f-strings),
 the `%` operator, or the `format` method for formatting strings, even when the
-parameters are all strings. Use your best judgment to decide between `+` and `%`
-(or `format`) though. Do not use `%` or the `format` method for pure
-concatenation.
+parameters are all strings. Use your best judgment to decide between string
+formatting options. A single join with `+` is okay but do not format with `+`.
 
 ```python
-Yes: x = a + b
+Yes: x = f'name: {name}; score: {n}'
      x = '%s, %s!' % (imperative, expletive)
      x = '{}, {}'.format(first, second)
      x = 'name: %s; score: %d' % (name, n)
+     x = 'name: %(name)s; score: %(score)d' % {'name':name, 'score':n}
      x = 'name: {}; score: {}'.format(name, n)
-     x = f'name: {name}; score: {n}'
+     x = a + b
 ```
 
 ```python
-No: x = '%s%s' % (a, b)  # use + in this case
-    x = '{}{}'.format(a, b)  # use + in this case
-    x = first + ', ' + second
+No: x = first + ', ' + second
     x = 'name: ' + name + '; score: ' + str(n)
 ```
 
@@ -2242,7 +2399,7 @@ be optimized on CPython, that is an implementation detail. The conditions under
 which an optimization applies are not easy to predict and may change. Instead,
 add each substring to a list and `''.join` the list after the loop terminates,
 or write each substring to an `io.StringIO` buffer. These techniques
-consistently have amortized-linear run time complexity.
+consistently have amortized-linear run-time complexity.
 
 ```python
 Yes: items = ['<table>']
@@ -2321,6 +2478,11 @@ Don't do this.
       will collapse common leading spaces in each line.""")
 ```
 
+Note that using a backslash here does not violate the prohibition against
+[explicit line continuation](#line-length); in this case, the backslash is
+[escaping a newline](https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals)
+in a string literal.
+
 <a id="s3.10.1-logging"></a>
 <a id="3101-logging"></a>
 <a id="logging"></a>
@@ -2386,7 +2548,7 @@ messages shown to the user) should follow three guidelines:
 ```python
   Yes:
   if not 0 <= p <= 1:
-    raise ValueError(f'Not a probability: {p!r}')
+    raise ValueError(f'Not a probability: {p=}')
 
   try:
     os.rmdir(workdir)
@@ -2398,7 +2560,7 @@ messages shown to the user) should follow three guidelines:
 ```python
   No:
   if p < 0 or p > 1:  # PROBLEM: also false for float('nan')!
-    raise ValueError(f'Not a probability: {p!r}')
+    raise ValueError(f'Not a probability: {p=}')
 
   try:
     os.rmdir(workdir)
@@ -2497,25 +2659,36 @@ documentation must explain clearly how resource lifetime is managed.
 Use `TODO` comments for code that is temporary, a short-term solution, or
 good-enough but not perfect.
 
-A `TODO` comment begins with the string `TODO` in all caps and a parenthesized
-name, e-mail address, or other identifier
-of the person or issue with the best context about the problem. This is followed
-by an explanation of what there is to do.
-
+A `TODO` comment begins with the word `TODO` in all caps, a following colon, and
+a link to a resource that contains the context, ideally a bug reference. A bug
+reference is preferable because bugs are tracked and have follow-up comments.
+Follow this piece of context with an explanatory string introduced with a hyphen
+`-`. 
 The purpose is to have a consistent `TODO` format that can be searched to find
-out how to get more details. A `TODO` is not a commitment that the person
-referenced will fix the problem. Thus when you create a
-`TODO`, it is almost always your name
-that is given.
+out how to get more details. 
 
 ```python
-# TODO(kl@gmail.com): Use a "*" here for string repetition.
-# TODO(Zeke) Change this to use relations.
+# TODO: crbug.com/192795 - Investigate cpufreq optimizations.
+```
+
+Old style, formerly recommended, but discouraged for use in new code:
+
+
+```python
+# TODO(crbug.com/192795): Investigate cpufreq optimizations.
+# TODO(yourusername): Use a "\*" here for concatenation operator.
+```
+
+Avoid adding TODOs that refer to an individual or team as the context:
+
+```python
+# TODO: @yourusername - File an issue and use a '*' for repetition.
 ```
 
 If your `TODO` is of the form "At a future date do something" make sure that you
 either include a very specific date ("Fix by November 2009") or a very specific
-event ("Remove this code when all clients can handle XML responses.").
+event ("Remove this code when all clients can handle XML responses.") that
+future code maintainers will comprehend. Issues are ideal for tracking this.
 
 <a id="s3.13-imports-formatting"></a>
 <a id="313-imports-formatting"></a>
@@ -2524,14 +2697,15 @@ event ("Remove this code when all clients can handle XML responses.").
 ### 3.13 Imports formatting 
 
 Imports should be on separate lines; there are
-[exceptions for `typing` imports](#typing-imports).
+[exceptions for `typing` and `collections.abc` imports](#typing-imports).
 
 E.g.:
 
 ```python
-Yes: import os
+Yes: from collections.abc import Mapping, Sequence
+     import os
      import sys
-     from typing import Mapping, Sequence
+     from typing import Any, NewType
 ```
 
 ```python
@@ -2546,9 +2720,7 @@ grouped from most generic to least generic:
 1.  Python future import statements. For example:
 
     ```python
-    from __future__ import absolute_import
-    from __future__ import division
-    from __future__ import print_function
+    from __future__ import annotations
     ```
 
     See [above](#from-future-imports) for more information about those.
@@ -2576,7 +2748,7 @@ grouped from most generic to least generic:
     ```
 
 5.  **Deprecated:** application-specific imports that are part of the same
-    top level
+    top-level
     sub-package as this file. For example:
 
     
@@ -2692,10 +2864,11 @@ change in complexity.
 
 `module_name`, `package_name`, `ClassName`, `method_name`, `ExceptionName`,
 `function_name`, `GLOBAL_CONSTANT_NAME`, `global_var_name`, `instance_var_name`,
-`function_parameter_name`, `local_var_name`.
+`function_parameter_name`, `local_var_name`, `query_proper_noun_for_thing`,
+`send_acronym_via_https`.
 
 
-Function names, variable names, and filenames should be descriptive; eschew
+Function names, variable names, and filenames should be descriptive; avoid
 abbreviation. In particular, do not use abbreviations that are ambiguous or
 unfamiliar to readers outside your project, and do not abbreviate by deleting
 letters within a word.
@@ -2713,6 +2886,8 @@ Always use a `.py` filename extension. Never use dashes.
     -   counters or iterators (e.g. `i`, `j`, `k`, `v`, et al.)
     -   `e` as an exception identifier in `try/except` statements.
     -   `f` as a file handle in `with` statements
+    -   private [type variables](#typing-type-var) with no constraints (e.g.
+        `_T = TypeVar("_T")`, `_P = ParamSpec("_P")`)
 
     Please be mindful not to abuse single-character naming. Generally speaking,
     descriptiveness should be proportional to the name's scope of visibility.
@@ -2738,7 +2913,9 @@ Always use a `.py` filename extension. Never use dashes.
     class.
 
 -   Prepending a single underscore (`_`) has some support for protecting module
-    variables and functions (linters will flag protected member access).
+    variables and functions (linters will flag protected member access). Note
+    that it is okay for unit tests to access protected constants from the
+    modules under test.
 
 -   Prepending a double underscore (`__` aka "dunder") to an instance variable
     or method effectively makes the variable or method private to its class
@@ -2755,11 +2932,11 @@ Always use a `.py` filename extension. Never use dashes.
     a class. ("wait -- did I write `import StringIO` or `from StringIO import
     StringIO`?")
 
--   Underscores may appear in *unittest* method names starting with `test` to
-    separate logical components of the name, even if those components use
-    CapWords. One possible pattern is `test<MethodUnderTest>_<state>`; for
-    example `testPop_EmptyStack` is okay. There is no One Correct Way to name
-    test methods.
+-   New *unit test* files follow PEP 8 compliant lower\_with\_under method
+    names, for example, `test_<method_under_test>_<state>`. For consistency(\*)
+    with legacy modules that follow CapWords function names, underscores may
+    appear in method names starting with `test` to separate logical components
+    of the name. One possible pattern is `test<MethodUnderTest>_<state>`.
 
 <a id="s3.16.3-file-naming"></a>
 <a id="3163-file-naming"></a>
@@ -2944,13 +3121,31 @@ the function into smaller and more manageable pieces.
 <a id="typing-general"></a>
 #### 3.19.1 General Rules 
 
-*   Familiarize yourself with
-    [PEP-484](https://www.python.org/dev/peps/pep-0484/).
-*   In methods, only annotate `self`, or `cls` if it is necessary for proper
-    type information. e.g., `@classmethod def create(cls: Type[T]) -> T: return
-    cls()`
+*   Familiarize yourself with [PEP-484](https://peps.python.org/pep-0484/).
+
+*   Annotating `self` or `cls` is generally not necessary.
+    [`Self`](https://docs.python.org/3/library/typing.html#typing.Self) can be
+    used if it is necessary for proper type information, e.g.
+
+    ```python
+    from typing import Self
+
+    class BaseClass:
+      @classmethod
+      def create(cls) -> Self:
+        ...
+
+      def difference(self, other: Self) -> float:
+        ...
+    ```
+
+*   Similarly, don't feel compelled to annotate the return value of `__init__`
+    (where `None` is the only valid option).
+
 *   If any other variable or a returned type should not be expressed, use `Any`.
+
 *   You are not required to annotate all the functions in a module.
+
     -   At least annotate your public APIs.
     -   Use judgment to get to a good balance between safety and clarity on the
         one hand, and flexibility on the other.
@@ -2970,12 +3165,16 @@ the function into smaller and more manageable pieces.
 Try to follow the existing [indentation](#indentation) rules.
 
 After annotating, many function signatures will become "one parameter per line".
+To ensure the return type is also given its own line, a comma can be placed
+after the last parameter.
 
 ```python
-def my_method(self,
-              first_var: int,
-              second_var: Foo,
-              third_var: Optional[Bar]) -> int:
+def my_method(
+    self,
+    first_var: int,
+    second_var: Foo,
+    third_var: Bar | None,
+) -> int:
   ...
 ```
 
@@ -2989,23 +3188,27 @@ def my_method(self, first_var: int) -> int:
 ```
 
 If the combination of the function name, the last parameter, and the return type
-is too long, indent by 4 in a new line.
+is too long, indent by 4 in a new line. When using line breaks, prefer putting
+each parameter and the return type on their own lines and aligning the closing
+parenthesis with the `def`:
 
 ```python
+Yes:
 def my_method(
-    self, first_var: int) -> Tuple[MyLongType1, MyLongType1]:
+    self,
+    other_arg: MyLongType | None,
+) -> tuple[MyLongType1, MyLongType1]:
   ...
 ```
 
-When the return type does not fit on the same line as the last parameter, the
-preferred way is to indent the parameters by 4 on a new line and align the
-closing parenthesis with the `def`.
+Optionally, the return type may be put on the same line as the last parameter:
 
 ```python
-Yes:
+Okay:
 def my_method(
-    self, other_arg: Optional[MyLongType]
-) -> Dict[OtherLongType, MyLongType]:
+    self,
+    first_var: int,
+    second_var: int) -> dict[OtherLongType, MyLongType]:
   ...
 ```
 
@@ -3016,8 +3219,8 @@ opening one, but this is less readable.
 ```python
 No:
 def my_method(self,
-              other_arg: Optional[MyLongType]
-             ) -> Dict[OtherLongType, MyLongType]:
+              other_arg: MyLongType | None,
+             ) -> dict[OtherLongType, MyLongType]:
   ...
 ```
 
@@ -3027,10 +3230,11 @@ too long to be on a single line (try to keep sub-types unbroken).
 ```python
 def my_method(
     self,
-    first_var: Tuple[List[MyLongType1],
-                     List[MyLongType2]],
-    second_var: List[Dict[
-        MyLongType3, MyLongType4]]) -> None:
+    first_var: tuple[list[MyLongType1],
+                     list[MyLongType2]],
+    second_var: list[dict[
+        MyLongType3, MyLongType4]],
+) -> None:
   ...
 ```
 
@@ -3062,17 +3266,29 @@ def my_function(
 <a id="forward-declarations"></a>
 #### 3.19.3 Forward Declarations 
 
-If you need to use a class name from the same module that is not yet defined --
-for example, if you need the class inside the class declaration, or if you use a
-class that is defined below -- either use `from __future__ import annotations`
-for simple cases or use a string for the class name.
+If you need to use a class name (from the same module) that is not yet
+defined -- for example, if you need the class name inside the declaration of
+that class, or if you use a class that is defined later in the code -- either
+use `from __future__ import annotations` or use a string for the class name.
 
 ```python
+Yes:
 from __future__ import annotations
 
 class MyClass:
+  def __init__(self, stack: Sequence[MyClass], item: OtherClass) -> None:
+
+class OtherClass:
+  ...
+```
+
+```python
+Yes:
+class MyClass:
+  def __init__(self, stack: Sequence['MyClass'], item: 'OtherClass') -> None:
 
-  def __init__(self, stack: Sequence[MyClass]) -> None:
+class OtherClass:
+  ...
 ```
 
 <a id="s3.19.4-default-values"></a>
@@ -3081,8 +3297,7 @@ class MyClass:
 <a id="typing-default-values"></a>
 #### 3.19.4 Default Values 
 
-As per
-[PEP-008](https://www.python.org/dev/peps/pep-0008/#other-recommendations), use
+As per [PEP-008](https://peps.python.org/pep-0008/#other-recommendations), use
 spaces around the `=` *only* for arguments that have both a type annotation and
 a default value.
 
@@ -3107,18 +3322,18 @@ def func(a:int=0) -> int:
 
 In the Python type system, `NoneType` is a "first class" type, and for typing
 purposes, `None` is an alias for `NoneType`. If an argument can be `None`, it
-has to be declared! You can use `Union`, but if there is only one other type,
-use `Optional`.
+has to be declared! You can use `|` union type expressions (recommended in new
+Python 3.10+ code), or the older `Optional` and `Union` syntaxes.
 
-Use explicit `Optional` instead of implicit `Optional`. Earlier versions of PEP
-484 allowed `a: str = None` to be interpreted as `a: Optional[str] = None`, but
-that is no longer the preferred behavior.
+Use explicit `X | None` instead of implicit. Earlier versions of PEP 484 allowed
+`a: str = None` to be interpreted as `a: str | None = None`, but that is no
+longer the preferred behavior.
 
 ```python
 Yes:
-def func(a: Optional[str], b: Optional[str] = None) -> str:
+def modern_or_union(a: str | int | None, b: str | None = None) -> str:
   ...
-def multiple_nullable_union(a: Union[None, str, int]) -> str:
+def union_optional(a: Union[str, int, None], b: Optional[str] = None) -> str:
   ...
 ```
 
@@ -3141,16 +3356,14 @@ def implicit_optional(a: str = None) -> str:
 You can declare aliases of complex types. The name of an alias should be
 CapWorded. If the alias is used only in this module, it should be \_Private.
 
-For example, if the name of the module together with the name of the type is too
-long:
+Note that the `: TypeAlias` annotation is only supported in versions 3.10+.
 
 ```python
-_ShortName = module_with_long_name.TypeWithLongName
-ComplexMap = Mapping[str, List[Tuple[int, int]]]
-```
+from typing import TypeAlias
 
-Other examples are complex nested types and multiple return variables from a
-function (as a tuple).
+_LossAndGradient: TypeAlias = tuple[tf.Tensor, tf.Tensor]
+ComplexTFMap: TypeAlias = Mapping[str, _LossAndGradient]
+```
 
 <a id="s3.19.7-ignoring-types"></a>
 <a id="s3.19.7-ignore"></a>
@@ -3175,25 +3388,26 @@ ignore`.
 <a id="typing-variables"></a>
 #### 3.19.8 Typing Variables 
 
-If an internal variable has a type that is hard or impossible to infer, you can
-specify its type in a couple ways.
-
-<a id="type-comments"></a>
-[*Type Comments:*](#type-comments)
-:   Use a `# type:` comment on the end of the line
-
-```python
-a = SomeUndecoratedFunction()  # type: Foo
-```
-
 <a id="annotated-assignments"></a>
 [*Annotated Assignments*](#annotated-assignments)
-:   Use a colon and type between the variable name and value, as with function
-    arguments.
+:   If an internal variable has a type that is hard or impossible to infer,
+    specify its type with an annotated assignment - use a colon and type between
+    the variable name and value (the same as is done with function arguments
+    that have a default value):
 
-```python
-a: Foo = SomeUndecoratedFunction()
-```
+    ```python
+    a: Foo = SomeUndecoratedFunction()
+    ```
+
+<a id="type-comments"></a>
+[*Type Comments*](#type-comments)
+:   Though you may see them remaining in the codebase (they were necessary
+    before Python 3.6), do not add any more uses of a `# type: <type name>`
+    comment on the end of the line:
+
+    ```python
+    a = SomeUndecoratedFunction()  # type: Foo
+    ```
 
 <a id="s3.19.9-tuples-vs-lists"></a>
 <a id="s3.19.9-tuples"></a>
@@ -3207,9 +3421,9 @@ have a single repeated type or a set number of elements with different types.
 The latter is commonly used as the return type from a function.
 
 ```python
-a = [1, 2, 3]  # type: List[int]
-b = (1, 2, 3)  # type: Tuple[int, ...]
-c = (1, "2", 3.5)  # type: Tuple[int, str, float]
+a: list[int] = [1, 2, 3]
+b: tuple[int, ...] = (1, 2, 3)
+c: tuple[int, str, float] = (1, "2", 3.5)
 ```
 
 <a id="s3.19.10-typevars"></a>
@@ -3218,23 +3432,31 @@ c = (1, "2", 3.5)  # type: Tuple[int, str, float]
 <a id="typing-type-var"></a>
 
 <a id="typevars"></a>
-#### 3.19.10 TypeVars 
+#### 3.19.10 Type variables 
 
 The Python type system has
-[generics](https://www.python.org/dev/peps/pep-0484/#generics). The factory
-function `TypeVar` is a common way to use them.
+[generics](https://peps.python.org/pep-0484/#generics). A type variable, such as
+`TypeVar` and `ParamSpec`, is a common way to use them.
 
 Example:
 
 ```python
-from typing import List, TypeVar
-T = TypeVar("T")
+from collections.abc import Callable
+from typing import ParamSpec, TypeVar
+_P = ParamSpec("_P")
+_T = TypeVar("_T")
 ...
-def next(l: List[T]) -> T:
+def next(l: list[_T]) -> _T:
   return l.pop()
+
+def print_when_called(f: Callable[_P, _T]) -> Callable[_P, _T]:
+  def inner(*args: _P.args, **kwargs: _P.kwargs) -> _T:
+    print("Function was called")
+    return f(*args, **kwargs)
+  return inner
 ```
 
-A TypeVar can be constrained:
+A `TypeVar` can be constrained:
 
 ```python
 AddableType = TypeVar("AddableType", int, float, str)
@@ -3243,8 +3465,7 @@ def add(a: AddableType, b: AddableType) -> AddableType:
 ```
 
 A common predefined type variable in the `typing` module is `AnyStr`. Use it for
-multiple annotations that can be `bytes` or `unicode` and must all be the same
-type.
+multiple annotations that can be `bytes` or `str` and must all be the same type.
 
 ```python
 from typing import AnyStr
@@ -3254,52 +3475,44 @@ def check_length(x: AnyStr) -> AnyStr:
   raise ValueError()
 ```
 
-<a id="s3.19.11-string-types"></a>
-<a id="s3.19.11-strings"></a>
-<a id="31911-string-types"></a>
-
-<a id="typing-strings"></a>
-#### 3.19.11 String types 
+A type variable must have a descriptive name, unless it meets all of the
+following criteria:
 
-The proper type for annotating strings depends on what versions of Python the
-code is intended for.
+*   not externally visible
+*   not constrained
 
-Prefer to use `str`, though `Text` is also acceptable. Be consistent in using
-one or the other. For code that deals with binary data, use `bytes`. For Python
-2 compatible code that processes text data (`str` or `unicode` in Python 2,
-`str` in Python 3), use `Text`.
+```python
+Yes:
+  _T = TypeVar("_T")
+  _P = ParamSpec("_P")
+  AddableType = TypeVar("AddableType", int, float, str)
+  AnyFunction = TypeVar("AnyFunction", bound=Callable)
+```
 
 ```python
-def deals_with_text_data_in_py3(x: str) -> str:
-  ...
-def deals_with_binary_data(x: bytes) -> bytes:
-  ...
-def py2_compatible_text_data_processor(x: Text) -> Text:
-  ...
+No:
+  T = TypeVar("T")
+  P = ParamSpec("P")
+  _T = TypeVar("_T", int, float, str)
+  _F = TypeVar("_F", bound=Callable)
 ```
 
-In some uncommon Python 2 compatibility cases, `str` may make sense instead of
-`Text`, typically to aid compatibility when the return types aren't the same
-between Python 2 and Python 3. Never use `unicode` as it doesn't exist in Python
-3. The reason this discrepancy exists is because `str` means something different
-in Python 2 than in Python 3.
+<a id="s3.19.11-string-types"></a>
+<a id="s3.19.11-strings"></a>
+<a id="31911-string-types"></a>
 
-No:
+<a id="typing-strings"></a>
+#### 3.19.11 String types 
 
-```python
-def py2_code(x: str) -> unicode:
-  ...
-```
+> Do not use `typing.Text` in new code. It's only for Python 2/3 compatibility.
 
-If the type can be either bytes or text, use `Union`, with the appropriate text
-type.
+Use `str` for string/text data. For code that deals with binary data, use
+`bytes`.
 
 ```python
-from typing import Text, Union
-...
-def py3_only(x: Union[bytes, str]) -> Union[bytes, str]:
+def deals_with_text_data(x: str) -> str:
   ...
-def py2_compatible(x: Union[bytes, Text]) -> Union[bytes, Text]:
+def deals_with_binary_data(x: bytes) -> bytes:
   ...
 ```
 
@@ -3314,24 +3527,36 @@ return type is the same as the argument type in the code above, use
 <a id="typing-imports"></a>
 #### 3.19.12 Imports For Typing 
 
-For classes from the `typing` module, always import the class itself. You are
-explicitly allowed to import multiple specific classes on one line from the
-`typing` module. Ex:
+For symbols (including types, functions, and constants) from the `typing` or
+`collections.abc` modules used to support static analysis and type checking,
+always import the symbol itself. This keeps common annotations more concise and
+matches typing practices used around the world. You are explicitly allowed to
+import multiple specific symbols on one line from the `typing` and
+`collections.abc` modules. For example:
 
 ```python
-from typing import Any, Dict, Optional
+from collections.abc import Mapping, Sequence
+from typing import Any, Generic, cast, TYPE_CHECKING
 ```
 
-Given that this way of importing from `typing` adds items to the local
-namespace, any names in `typing` should be treated similarly to keywords, and
-not be defined in your Python code, typed or not. If there is a collision
-between a type and an existing name in a module, import it using `import x as
-y`.
+Given that this way of importing adds items to the local namespace, names in
+`typing` or `collections.abc` should be treated similarly to keywords, and not
+be defined in your Python code, typed or not. If there is a collision between a
+type and an existing name in a module, import it using `import x as y`.
 
 ```python
 from typing import Any as AnyType
 ```
 
+Prefer to use built-in types as annotations where available. Python supports
+type annotations using parametric container types via
+[PEP-585](https://peps.python.org/pep-0585/), introduced in Python 3.9.
+
+```python
+def generate_foo_scores(foo: set[str]) -> list[float]:
+  ...
+```
+
 <a id="s3.19.13-conditional-imports"></a>
 <a id="31913-conditional-imports"></a>
 
@@ -3340,7 +3565,7 @@ from typing import Any as AnyType
 
 Use conditional imports only in exceptional cases where the additional imports
 needed for type checking must be avoided at runtime. This pattern is
-discouraged; alternatives such as refactoring the code to allow top level
+discouraged; alternatives such as refactoring the code to allow top-level
 imports should be preferred.
 
 Imports that are needed only for type annotations can be placed within an `if
@@ -3376,8 +3601,8 @@ because each module has to depend on the other.
 
 Replace modules that create circular dependency imports with `Any`. Set an
 [alias](#typing-aliases) with a meaningful name, and use the real type name from
-this module (any attribute of Any is Any). Alias definitions should be separated
-from the last import by one line.
+this module (any attribute of `Any` is `Any`). Alias definitions should be
+separated from the last import by one line.
 
 ```python
 from typing import Any
@@ -3397,19 +3622,18 @@ def my_method(self, var: "some_mod.SomeType") -> None:
 #### 3.19.15 Generics 
 
 When annotating, prefer to specify type parameters for generic types; otherwise,
-[the generics' parameters will be assumed to be `Any`](https://www.python.org/dev/peps/pep-0484/#the-any-type).
+[the generics' parameters will be assumed to be `Any`](https://peps.python.org/pep-0484/#the-any-type).
 
 ```python
-def get_names(employee_ids: List[int]) -> Dict[int, Any]:
+# Yes:
+def get_names(employee_ids: Sequence[int]) -> Mapping[int, str]:
   ...
 ```
 
 ```python
-# These are both interpreted as get_names(employee_ids: List[Any]) -> Dict[Any, Any]
-def get_names(employee_ids: list) -> Dict:
-  ...
-
-def get_names(employee_ids: List) -> Dict:
+# No:
+# This is interpreted as get_names(employee_ids: Sequence[Any]) -> Mapping[Any, Any]
+def get_names(employee_ids: Sequence) -> Mapping:
   ...
 ```
 
@@ -3418,13 +3642,15 @@ remember that in many cases [`TypeVar`](#typing-type-var) might be more
 appropriate:
 
 ```python
-def get_names(employee_ids: List[Any]) -> Dict[Any, str]:
+# No:
+def get_names(employee_ids: Sequence[Any]) -> Mapping[Any, str]:
   """Returns a mapping from employee ID to employee name for given IDs."""
 ```
 
 ```python
-T = TypeVar('T')
-def get_names(employee_ids: List[T]) -> Dict[T, str]:
+# Yes:
+_T = TypeVar('_T')
+def get_names(employee_ids: Sequence[_T]) -> Mapping[_T, str]:
   """Returns a mapping from employee ID to employee name for given IDs."""
 ```
 
@@ -3437,14 +3663,20 @@ def get_names(employee_ids: List[T]) -> Dict[T, str]:
 *BE CONSISTENT*.
 
 If you're editing code, take a few minutes to look at the code around you and
-determine its style. If they use spaces around all their arithmetic operators,
-you should too. If their comments have little boxes of hash marks around them,
-make your comments have little boxes of hash marks around them too.
+determine its style. If they use `_idx` suffixes in index variable names, you
+should too. If their comments have little boxes of hash marks around them, make
+your comments have little boxes of hash marks around them too.
 
 The point of having style guidelines is to have a common vocabulary of coding so
 people can concentrate on what you're saying rather than on how you're saying
 it. We present global style rules here so people know the vocabulary, but local
 style is also important. If code you add to a file looks drastically different
 from the existing code around it, it throws readers out of their rhythm when
-they go to read it. Avoid this.
+they go to read it.
+
+However, there are limits to consistency. It applies more heavily locally and on
+choices unspecified by the global style. Consistency should not generally be
+used as a justification to do things in an old style without considering the
+benefits of the new style, or the tendency of the codebase to converge on newer
+styles over time.
 
diff --git a/script/build.py b/script/build.py
index 495402d..2632db2 100644
--- a/script/build.py
+++ b/script/build.py
@@ -8,8 +8,8 @@
 import os
 import re
 
-find_link = re.compile('\[(\w+)\]\(([\w\\\/\_\.\:]+)\)')
-find_nums = re.compile('([0-9]+)\.([0-9]*).*')
+find_link = re.compile('\\[(\\w+)\\]\\(([\\w\\\\/_.:]+)\\)')
+find_nums = re.compile('([0-9]+)\\.([0-9]*).*')
 
 readme = []
 tree = []