협업

About_work·2023년 2월 25일

python 기초

목록 보기

25/65

82. 커뮤니티에서 만든 모듈을, 어디서 찾을 수 있는지 알아두라.

요약
- 파이썬 패키지 인덱스(PyPI)에는 파이썬 커뮤니티가 개발하고 유지하는 풍부한 공통 패키지가 들어있다.
- pip은 PyPI에 있는 패키지를 설치하고, 사용할 떄 쓸 수 있는 명령줄 도구다.
- PyPI 모듈 대다수는 자유 소프트웨어이거나, 오픈 소스 소프트웨어다.
본문
- pip: Pip Installs Packages 의 약자다.
- python3 -m pip install ~~: 패키지가, 시스템에 설치된 파이썬 버전에 맞게 설치되도록 보장할 수 있다.

83. 가상 환경을 사용해, 의존 관계를 격리하고 반복 생성할 수 있게 하라.

요약
- 가상 환경을 사용하면, 한 컴퓨터 안에서 pip을 사용해 패키지의 여러 버전을 충돌 없이 설치할 수 있다.
- 만들기: python -m venv
- 활성화: source bin/activate
- 비활성화: deactivate
- 어떤 환경 안의 모든 의존 관계를 dump: python -m pip freeze
- 환경 재생성: python3 -m pip install -r requirements.txt
본문
- 기본 pip: 새로운 패키지를, 모든 파이썬 Interpretor가 볼 수 있는 global 위치에 저장
- 문제가 되는 경우: 설치한 패키지가 다른 패키지에 의존하는 경우.
- 특성 패키지의 의존 패키지를 어떻게 볼 수 있는가? python3 -m pip show numpy
- venv는 가상 환경을 제공한다. python -m venv로 접근 가능
- venv
  - 특정 파이썬 버전 설치 가능
- python3 명령어
  - $which python3
    - /usr/local/bin/python3
  - $python3 --version
    - Python 3.8.0
- CLI 에서 venv 사용하기
  - 전역적으로 설치된 패키지는 무시된다.
  - $python3 -m venv myproject
  - $cd myproject
  - $ls
    - bin
      - activate (스크립트임)
      - python3
    - include
    - lib
    - pyvenv.cfg
  - (myproject)$ which python3
    - /tmp/myproject/bin/python3
  - (myproject)$ ls -l /tmp/myproject/bin/python3
    - ... -> /usr/local/bin/python3.8
- 환경 복사 생성하기
  - python3 -m pip freeze > requirements.txt 명령을 사용해, requirements.txt에 환경 정보를 저장 가능하다.
  - 이걸 재활용하는 방법
    - 새로운 환경을 activate한 뒤
    - $ python3 -m pip install -r /tmp/myproject/requirements.txt
    - 하지만 이 txt에는 파이썬 버전은 들어가지 않으므로, 파이썬 버전을 별도로 관리해야 한다.

84. 모든 함수, 클래스, 모듈에 docstring을 작성하라.

https://velog.io/@jk01019/docstring-in-python

85. 패키지를 사용해, 모듈을 체계화하고 안정적인 API를 제공하라.

요약

파이썬 패키지는 다른 모듈을 포함하는 모듈이다.
패키지를 사용하면, 서로 분리돼 충돌이 일어나지 않는, 유일한 절대 모듈 경로를 사용하는 이름공간으로 코드를 나눌 수 있다.
다른 소스 파일이 들어 있는 디렉터리에 __init__.py를 추가하면 간단한 패키지를 만들 수 있다.
소스 파일들은 디렉터리로 인해 생긴 패키지의 자식 모듈이 된다.
패키지 디렉터리에는 다른 패키지가 들어갈 수도 있다.
모듈 외부에서 볼 수 있게 허용할 이름을 __all__ special attribute에 지정해, 공개 API를 제공할 수 있다.
아래와 같은 방법으로 패키지 내부에서만 사용할 수 있는 이름을 감출 수 있다.
- 패키지의 __init__.py 파일에 외부에 공개할 이름만 import 하거나,
- 패키지 내부에서만 사용할 이름 앞에 _를 붙임으로써,
단일 코드베이스나, 단일 팀 안에서 협업을 진행한다면, 아마도 __all__로 API를 명시할 필요가 없을 것이다.

본문

__init__.py 가 있는 디렉토리에선, 이 디렉터리에 있는 다른 모듈은 __init__.py가 있는 디렉터리를 기준으로 relative 경로를 통해 import해서 사용할 수 있다.

main.py
mypackage/__init__.py
mypackage/models.py
mypackage/utils.py

# main.py
from mypackage import utils

패키지 왜 쓰는데?
- 이름 공간
  - 모듈을 별도의 namespace로 분리하는 것
  - 다른 패키지에 같은 모듈 이름을 생성할 수 있다.
- 안정적인 API
  - 엄격하고 안정적인 API를 외부 사용자에게 제공할 수 있다.
  - 외부 사람들에게 안정적인 기능을 제공하려면, 외부 사용자로부터 내부 코드 조직을 감춰야 한다.
  - 그렇게 해야 외부 사용자의 코드를 깨지 않으면서 여러분 패키지의 내부 모듈을 리펙토링하고 개선할 수 있다.
  - 패키지나 모듈의 __all__ special attribute를 통해, API 소비자에게 노출할 표면적 이름을 제한할 수 있다.
  - 대전제: wildcard import를 하지마라.
  - 아래 예제 중요!!
  - from foo import * 을 실행한 소비자 코드는
    - foo.__all__에 있는 attribute만 import 할 수 있고,
    - foo.__all__가 없으면, 공개 attribute(_가 없는)만 import 된다.

mypackage/__init__.py
 
__all__ = []

 
from .utils import *
__all__ += utils.__all__

# mypackage/utils.py

__all__ = ['simulate_collision']

def _dot_product(a, b):
   ...
def simulate_collision(a, b):
   ...

86. 배포 환경을 설정하기 위해, 모듈 영역의 코드를 사용하라.

요약

고유한 가정과 설정이 있는 다양한 배포 환경에서 프로그램을 실행해야 하는 경우가 많다.
모듈 영역에서 일반적인 python 문을 사용하면, 각 배포 환경에 맞게 모듈의 내용을 조정할 수 있다.
모듈 내용은 모든 외부 조건에 따라 달라질 수 있는 결과물이다. 외부 조건에는 sys나 os 모듈을 사용해 알아낸 host introspection 정보가 포함된다

본문

배포 환경
- production 환경
- 개발 환경

# dev_main.py
TESTING = True
import db_connection
db = db_connection.Database()

# prod_main.py
TESTING = False
import db_connection
db = db_connection.Database()

# db_connection.py
import  __main__

class TestingDataBase:
	...
class RealDataBase:
	...
if __main__.TESTING:
	Database = TestingDataBase
else:
	Database = RealDataBase

if 문을 모듈 수준(함수나 메서드 내부의 깊은 수준이 아니라)에서 사용하면, 모듈 안에서 이름이 정의되는 방식을 결정할 수 있따.
그리고 배포 환경이 복잡해지면,
- TESTING 같은 설정을 코드와 구분하기 위해, 전용 설정 파일로 옮겨야 한다.
- 그리고 TESTING 처럼 쓰지 않고, configparser 내장 모듈 같은 도구를 사용하면, production 설정을 코드로부터 분리해 유지 보수할 수 있다.
sys를 활용하여, 윈도우와 우분투 등의 환경에 맞게 실행하도록 할 수 있다.

import sys
class Win32DataBase:
	...
class PosixDataBase:
	...
if sys.platform.startswith('win32'):
	Database = Win32DataBase
else:
	Database = PosixDataBase

비슷한 방식으로, os.environ에서 얻은 환경 변수를 모듈 정의에 참조할 수도 있다.

87. 호출자를 API로부터 보호하기 위해, 최상위 Exception을 정의하라.

요약

모듈에서 사용할 최상위 예외를 정의하면, API 사용자들이 자신을 API로부터 보호할 수 있다.
최상위 예외를 잡아내면, API를 소비하는 코드의 버그를 쉽게 찾을 수 있다.
파이썬 내장 Exception 기반 클래스를 잡아내면, API 구현의 버그를 쉽게 찾을 수 있다.
중간 단계의 최상위 예외를 사용하면, 미래에 새로운 타입의 예외를 추가할 때, API를 사용하는 코드가 깨지는 일을 방지할 수 있다.

본문

모듈 API에서는, 모듈 내에 정의한 함수 또는 클래스만큼이나 발생시킬 예외도 중요하다.
파이썬에는 내장 예외 타입이 존재하지만, API의 경우 새로운 예외 계층 구조를 정의하는 편이 훨씬 강력하다.
아래와 같이 예외 계층 구조를 만들 수 있다.

# my_module.py
class Error(Exception):
	"""이 모듈에서 발생할 모든 예외의 상위 클래스."""
class InvalidDensityError(Error):
	"""밀도 값이 잘못된 경우"""
class InvalidVolumeError(Error):
	"""부피 값이 잘못된 경우"""
    
def determine_weight(volume, density):
	if density < 0:
    	raise InvalidDensityError('밀도는 0보다 커야 합니다')
    if volume < 0:
    	raise InvalidVolumeError('부피는 0보다 커야 합니다')

이처럼 모듈 안에 최상위 예외가 있으면, 아래와 같은 방법으로 발생한 모든 오류를 더 쉽게 잡아낼 수 있다.
- 아래 내용 에 예외의 전체 stack trace를 출력하기 때문에 쉽게 디버깅을 할 수 있다.
- try/except 문을 사용하면, 우리 모듈에서 발생한 예외가, 모듈을 호출하는 코드로부터 아주 멀리 전달돼 프로그램이 꺠지는 상황을 방지할 수 있다.

try:
	weight = my_module.determine_weight(1, -1)
except my_module.Error:
	logging.exception('예상치 못한 오류')

>>>
ERROR:root:예상치 못한 오류
~~~~~내용~~~~

최상위 예외의 3가지 효과
- 최상위 예외가 있으면, API를 호출하는 사용자가 API를 잘못 사용한 경우를 더 쉽게 이해할 수 있다.
- API 모듈 코드의 버그를 발견할 때 도움이 된다.
  - API 코드는 의도적으로 API 내에서 정의한 예외 계층에 속하는 예외만 발생시킬 수 있다.
  - 만약 사용자가 API 사용 중 다른 타입의 예외가 발생한다면, 그 예외는 우리가 의도하지 않은 것이므로, API 코드에 버그가 있다는 뜻이다.

try:
	weight = my_module.determine_weight(1, -1)
except my_module.InvalidDensityError:
	weight = 0
except my_module.Error:
	logging.exception('호출 코드에 버그가 있음')
except Exception:
	logging.exception('API 코드에 버그가 있음.')

>>>
ERROR:root:예상치 못한 오류
~~~~~내용~~~~

- 미래의 API를 보호해 준다.
  - 시간이 지남에 따라 API를 확장해 특정 상황에서 더 구체적인 예외를 제공하고 싶을 때가 있다.
  - 그에 따라 API가 바뀌더라도, 기존의 API를 호출하는 코드에는 문제가 없다.
  - 이처럼, 최상위 예외 바로 아래에 폭넓은 예외 상황을 표현하는 다양한 오류를 제공하면, 미래의 코드 변경에 대한 보호를 더 강화할 수 있다.
  - 중간 단계의 최상위 예외를 사용하면, 미래에 새로운 타입의 예외를 추가할 때, API를 사용하는 코드가 깨지는 일을 방지할 수 있다.
  - 모든 API 호출 코드가 구체적인 Exception 하위 클래스 예외를 일일이 처리하는 것보다, 이런 식의 예외 계층 구조를 채택하는 편이 훨씬 낫다.

# my_module.py

class NegativeDensityError(InvalidDensityError):
	"""밀도가 음수인 경우."""
def determine_weight(volume, density):
	if density < 0:
    	raise NegativeDensityError('밀도는 0보다 커야 합니다')

# my_module.py

class Error(Exception):
	"""이 모듈에서 발생할 모든 예외의 상위 클래스."""
class DensityError(Error):
	"""밀도 값이 잘못된 경우의 상위 클래스"""
class VolumeError(Error):
	"""부피 값이 잘못된 경우의 상위 클래스"""

88. 순환 의존성을 깨는 방법을 알아두라.

요약

두 모듈이 import 시점에 서로를 호출하면 순환 의존 관계가 생긴다. 순환 의존 관계가 있으면 프로그램이 시작되다가 오류가 발생하면서 중단될 수 있따.
순환 의존 관계를 꺠는 가장 좋은 방법은, 상호 의존 관계를 의존 관계 트리의 맨 아래에 위치한 별도의 모듈로 refactoring 하는 것이다.
동적 import는 refactoring과 복잡도 증가를 최소화하면서, 모듈 간의 순환 의존 관계를 깨는 가장 단순한 해법이다.

본문

문제 상황

# dialog.py

import app

class Dialog:
	def __init__(self, save_dir):
    	self.save_dir = save_dir

save_dialog = Dialog(app.prefs.get('save_dir'))

def show():
	...

# app.py
import dialog

class Prefs:
	def get(self, name):
    	...
prefs = Prefs()
dialog.show()

app.py를 실행하면, 순환 참조 에러가 발생한다.
- app의 5단계가 끝나지 않았는데, dialog의 5단계를 실행하는 도중에 에러가 터졌다.
파이썬에서, 모듈이 import 되면 파이썬이 실제로 어떤 일을 하는지를 아래에 나타내었다.
- sys.path에서 모듈 위치를 검색한다.
- 모듈의 코드를 로딩하고, 컴파일되는지 확인한다.
- 임포트할 모듈에 상응하는, 빈 모듈 객체를 만든다.
- 모듈을 sys.modules에 넣는다. (import 문을 이용해 모듈 load 가능)
- 모듈 객체에 있는 코드를 실행해서, 모듈의 내용을 정의한다. (모듈 attribute 정의)
순환 참조를 해결하는 방법 1: 임포트, 설정, 실행
- dialog/ app 모두 임포트 시, 동작을 수행하지 않게 정의하자.
- import 후, 각 모듈을 설정하는 configure() 을 구현하자.
- 단점
  - 객체를 정의하는 부분과, 객체를 설정하는 부분이 분리되기 때문에, 코드를 더 읽기 어려워진다.
  - 명시적인 configure 단계를 분리할 수 없을 때도 있다.

# dialog.py

import app

class Dialog:
	def __init__(self, save_dir):
    	self.save_dir = save_dir

def configure():
	save_dialog = Dialog(app.prefs.get('save_dir'))

def show():
	...

# app.py
import dialog

class Prefs:
	def get(self, name):
    	...
def configure():
	prefs = Prefs()

# main.py
import app
import dialog
app.configure()
dialog.configure()

dialog.show()

순환 참조를 해결하는 방법 1: 동적 import
- 하지만 함수 호출시 ,매번 import를 돌 수 있으므로, 주의해야한다.
- 하지만, 프로그램 전체를 바꿔서 순환 참조를 해결해야 하는 어려운 경우에는, 이 동적 import를 고려해보라.

# dialog.py


class Dialog:
	def __init__(self, save_dir):
    	self.save_dir = save_dir

save_dialog = Dialog()

def show():
	import app # 동적 import
	save_dialog.save_dir = app.prefs.get('save_dir')
	...

# app.py
import dialog

class Prefs:
	def get(self, name):
    	...
prefs = Prefs()
dialog.show()

89. refactoring과 마이그레이션 방법을 알려주기 위해, warning을 사용하라.

요약

warnings 모듈을 사용하면, 여러분의 API를 호출하는 사용자들에게, 앞으로 사용 금지될 사용법에 대해 알려줄 수 있다.
- 경고 메시지는 API 사용자들이 (API 변경으로 인해) 자신의 코드가 꺠지기 전에 코드를 변경하도록 권장한다.
-w error 명령줄 인자를 파이썬 interpretor에 넘기면, 경고를 오류로 높일 수 있다.
- 의존 관계에서 잠재적인 회귀 오류가 있는지 잡아내고 싶은 자동화 테스트에서 이런 기능이 특히 유용하다.
프로덕션 환경에서는 경고를 logging 모듈로 복제해, 실행 시점에 기존 오류 보고 시스템이 경고를 잡아내게 할 수 있다.
downstream 의존 관계에서, 알맞은 때 경고가 발동되도록 코드가 생성하는 경고에 대해 테스트를 작성하면 유용하다.

본문

필요할 때 다시 공부하자!

90. typing과 정적 분석을 통해 버그를 없애라.

https://velog.io/@jk01019/typing-과-정적-분석

About_work

새로운 것이 들어오면 이미 있는 것과 충돌을 시도하라.

이전 포스트

테스트와 디버깅

다음 포스트

협업

python 기초

82. 커뮤니티에서 만든 모듈을, 어디서 찾을 수 있는지 알아두라.

83. 가상 환경을 사용해, 의존 관계를 격리하고 반복 생성할 수 있게 하라.

84. 모든 함수, 클래스, 모듈에 docstring을 작성하라.

85. 패키지를 사용해, 모듈을 체계화하고 안정적인 API를 제공하라.

요약

본문

86. 배포 환경을 설정하기 위해, 모듈 영역의 코드를 사용하라.

요약

본문

87. 호출자를 API로부터 보호하기 위해, 최상위 Exception을 정의하라.

요약

본문

88. 순환 의존성을 깨는 방법을 알아두라.

요약

본문

89. refactoring과 마이그레이션 방법을 알려주기 위해, warning을 사용하라.

요약

본문

90. typing과 정적 분석을 통해 버그를 없애라.

테스트와 디버깅

Remote Procedure Call(RPC)

0개의 댓글