- 파이썬 구성 요소:
모듈 + 패키지 + 리소스
- 모듈: *.py
- 패키지: "동일한 목적" 을 위해 구성된 *.py를 모아둔 폴더/디렉토리
-그룹단위, 모듈집합- 리소스: 파이썬 외부에 존재하는 모든 자원
-Ex > 파일, 데이터베이스, 소켓(네트워크 기반) ...✅ 파이썬으로 구성한 s/w는 위 구성원들의 집합이다
⤷ (* 사용도구: s/w 구성시 vscode, 파이참 같은 IDE를 사용)
<< 참고 >>
* 코랩(or 주피터노트북)에서 사용하는 파일 : `*.ipynb`
* `노트 = ipython + notebook` 결합한 구조
⤷ Ex > 분석용, 학습용, 웹기반 작동"모듈 & 패키지" 만들기
<< 구조 (모듈) >>
/ L 현재노트(모듈을 사용하는 자) L a : a패키지 L __init__.py : 모듈 / a 패키지를 대변함 L b : b패키지 L __init__.py : 모듈 / b 패키지를 대변함 L mod.py : 모듈
Ex.01-A > 위의 구조를 바탕으로 디렉토리(패키지) & 파일(모듈) 생성
➕ ➕ ➕
📚 참고
- EX.02-A > [ 실습환경 만들기 ] - 파일별 기재할 내용
#(1) a/__init__.py
> PI = 3.14
#(2) a/b/__init__.py
> PI2 = 3.144
> def add(a, b):
return a + b
#(3) a/b/mod.py
> PI3 = 3.1456789
🔽🔽🔽모듈 가져오기
: 다른 사람이 만든 모듈/패키지를 가져와서 내가 작성하는 코드에 활용하고 싶을때 사용
<< 작성 조합 케이스 >>
- 1번 유형 : from ~ import ~
🔸 기본형: from 패키지.패키지.....모듈 import 변수, 함수, 클레스 or *(모든것) 🔸 from 패키지.패키지.....패키지 import 변수, 함수, 클레스 or *(모든것) 🔸 from 모듈|패키지 import 변수, 함수, 클레스 or *(모든것)
- 2번 유형 : import ~
.🔸 import 패키지.패키지.....모듈 [as 별칭] ⭠ 생략 가능 🔸 import 패키지.패키지.....패키지 [as 별칭] 🔸 import 모듈|패키지 [as 별칭]✅ 결론: 모듈 가져오기는
코드 어디서든 작성 가능(사용 제한X)⤷ But. 일반적으로 *.py 파일 맨 위(코드의 첫라인)에 작성
- EX.02-B > 1-1번 유형
- EX.02-C > 1-2번 유형
- EX.02-C > 1-3번 유형
- EX.02-D >2-1번 유형
- EX.02-E >2-1번 유형 +
as
- EX.02-F >2-2번 유형
- EX.02-G >2-3번 유형
파이썬의 전역변수 name
: __name__
- 사용방식 2가지
내가 작성한 모듈(*.py/엔트리 포인트) 실행에 사용
<<해석>>
__name__ => '__main__'
<<조건식-코드 작성>>
if __name__ == '__main__':
시작코드(메인코드, 메인함수) 실행
↪️ EX. 차후 웹, GUI, 자동화프로그램 ➜ 메인 실행코드는 반드시 위 의 표현으로 구현
남이 작성한 모듈(용도: 라이브러리)에서 사용 ( ex) cal.py )
<<해석>>
__name__ => '파일명'
<<조건식-코드 작성>>
if __name__ == '__main__':
테스트 코드 작성 (->why. 특정 코드 실행되면 안되기에)↪️ EX. 지원팀 관점에서 라이브러리, 유틸리티등을 만들어서 제공
✅결론: 실행하는 위치에 따라 전역변수 name의 해석이 달라진다.
- EX.01-A > 남이 작성한 모듈
- EX.02-A > 남이 작성한 모듈
🔽🔽🔽 - EX.01-A >- 코드 가져오기
예외처리
-
서비스 (Ex. 웹, PC어플리케이션, 앱... )
- 내부적으로
버그가 존재시,서비스 중단➜ 신뢰down
▶️ ∴ " Never 셧다운 발생 X "
- 내부적으로
-
셧다운 방지 - 2가지
LBYL[Look Before You Leap]
: 꼼꼼하게, 체크, 테스트
😾 조건문이 많다EAFP[It's Easier to Ask Forgiveness than Permission]
: 오류나면 수습하자
😻코드 간결 -> why. 터지면 그때 수습하기에
😻파이썬의 권장 스타일 = 간결, 심플 추구
✅결론: 사내방침에 따른다.
- 예외처리 (≒ LBYL 방식 (느낌적...) )
- case.01> 예외상황: catch
- case.02> 예외를 던지는 상황: raise
- EX.01-A > 오류 상황
🔽🔽🔽
- 해결방안
- 방식: LBYL & EAFP 택 1
- 예외 처리코드
⚡ try: ✔ 예외 상황이 발생된만한 의심스러운 코드 작성 ⤷ ex) I/O상황 => close(), 연산과정, 형변환... ⚡ except 오류객체명1: ➔ (#1번만 기술할땐, 오류의 최상위 객체 표기) ✔ Exception. 예외 ✔ 오류 처리 except 오류객체명2: 오류 처리 ... ... except 오류객체명n: 오류 처리 *else: ➔ (#생략 가능) ⤷ To. 오류가 없었다는 상황 인지 *finally: ➔ (#생략 가능) #최종 ⤷ 정상적으로 작동하던, 오류가 나던 `무조건 진입하는 코드`= When 뒷정리 작업 구현시❇
else:조건문, 반복문, 예외처리문모두 사용됨
💥 예외 오류 상황 캐치 (🔽기본코드)
- EX.01-B > EAFP
- EX.01-C > LBYL
예외 상황 던지는 방식
- 하위 코드에서 처리하지 않고, 상위 코드에서 모아서 처리한다.
오류- 하위코드, 수습- 상위코드
- 코드 복잡/오류가 많으면, 특정위치에서 예외처리를 일괄적으로 수행하는게 관리상 유리
EX.01-C > 
