Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
 

파이썬 - 소스 코드의 파일 경로를 지정한 모듈 로드

예를 들어, main.py 및 sub.py가 다음과 같이 있을 때,

$ pwd
/mnt/c/temp

$ cat main.py
print('main: loaded')

import sub
sub.sub_func()

$ cat sub.py
print('sub: loaded')

def sub_func():
    print('sub: sub_func called')

$ python main.py
main: loaded
sub: loaded
sub: sub_func called

다른 디렉터리에 있는 파이썬 소스 코드에서 저 sub.py를 실행하기 위해서는 SourceFileLoader 타입을 사용해 이렇게 작성할 수 있습니다.

$ pwd
/mnt/c/test

$ cat call_main.py
import os

print('call_main:', os.getcwd())

module_path = '/mnt/c/temp'
module_name = 'sub'

module_path = module_path + os.sep + module_name + '.py'

from importlib.machinery import SourceFileLoader
module = SourceFileLoader(module_name, module_path).load_module()  # sub.py 모듈 로드
print('call_main:', module.__name__)

module.__dict__['sub_func']()  # sub.py에 정의된 sub_func 함수 호출

$ python call_main.py
call_main: /mnt/c/test
sub: loaded
call_main: sub
sub: sub_func called

보통 다른 언어를 사용하던 개발자들, 특히 C# 개발자들이라면 SourceFileLoader.load_module() 메서드를 단순히 DLL 로드와 유사하다고 오해할 수 있는데, 위의 출력에서도 볼 수 있듯이 sub.py에 있는 코드 자체가 수행된다는 점에서 (로드가 아닌) Run이라는 점을 주의할 필요가 있습니다. (그래서 출력에 "sub: loaded"가 나타남)

게다가, 한 번 로드가 됐어도 다시 load_module 함수를 호출하면 재차 sub.py의 코드가 실행됩니다. 따라서 그런 부작용을 막고 싶다면 미리 sys.modules에서 조회하는 절차가 필요합니다.

$ cat call_main.py
import os
import sys


def is_loaded(module_name):
    return module_name in sys.modules


print('call_main:', os.getcwd())

module_path = '/mnt/c/temp'
module_name = 'sub'

module_path = module_path + os.sep + module_name + '.py'

from importlib.machinery import SourceFileLoader
module = SourceFileLoader(module_path, module_path).load_module()
print('call_main:', module.__name__)

module.__dict__['sub_func']()

# 만약 if 문 없이 실행하면 sub.py의 코드가 다시 실행됨
if not is_loaded(module_path):
    module = SourceFileLoader(module_path, module_path).load_module()




그렇다면, sub.py가 아닌 main.py를 로드하려면 어떻게 해야 할까요? 아쉽게도 이번에는 오류가 발생하는데요,

$ cat call_main.py
# ...[생략]...

print('call_main:', os.getcwd())

module_path = '/mnt/c/temp'
module_name = 'main'

# ...[생략]...

# main.py를 로드하므로 sub_func 검색/실행은 주석 처리
# module.__dict__['sub_func']()

$ python call_main.py
call_main: /mnt/c/test
main: loaded
Traceback (most recent call last):
  File "call_main.py", line 17, in <module>
    module = SourceFileLoader(module_path, module_path).load_module()
  File "<frozen importlib._bootstrap_external>", line 522, in _check_name_wrapper
  File "<frozen importlib._bootstrap_external>", line 1022, in load_module
  File "<frozen importlib._bootstrap_external>", line 847, in load_module
  File "<frozen importlib._bootstrap>", line 265, in _load_module_shim
  File "<frozen importlib._bootstrap>", line 702, in _load
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 843, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/mnt/c/temp/main.py", line 3, in <module>
    import sub
ModuleNotFoundError: No module named 'sub'

여기서도 또 주의해야 할 점이, main.py 자체를 로드하는데 실패한 것이 아니고, 그 내부의 코드를 실행하는 중에 오류가 발생했다는 점입니다. 위의 출력에 보면 분명히 main.py에 있던 "main: loaded" 메시지가 나오고 이후 "import sub"를 실행하는 시점에서 오류가 발생한 것입니다.

재미있는 건, 그렇다면 모듈이 로드된 것은 맞다고도 볼 수 있는데 sys.modules에는 main.py 모듈이 등록돼 있지 않습니다. 즉, 파이썬의 경우 (전통적인 의미의) 모듈 로딩과 그것의 실행이 모두 성공해야만 비로소 "loaded" 상태가 된다고 볼 수 있습니다.




그렇다면 위와 같은 경우에 sub.py까지 로드가 잘 되게 만들려면 어떻게 해야 할까요?

처음에는 cwd(current working directory)가 모듈 검색 경로에 포함될 거라 생각했는데요, 물론 call_main.py를 main.py와 함께 있는 디렉터리에서 실행하면 정상 동작을 하지만,

// call_main.py를 /mnt/c/temp 디렉터리에 복사

$ pwd
/mnt/c/temp

$ python call_main.py
call_main: /mnt/c/temp
main: loaded
sub: loaded
sub: sub_func called
call_main: /mnt/c/temp/main.py

단순히 main.py가 cwd와 같은 디렉터리라고 해서 실행되는 것도 아님을 아래의 실행 사례를 통해 확인할 수 있습니다.

// temp 디렉터리에서 ./test 디렉터리에 있는 call_main.py를 실행

$ pwd
/mnt/c/temp

$ python /mnt/c/test/call_main.py
call_main: /mnt/c/temp
main: loaded
Traceback (most recent call last):
  File "/mnt/c/test/call_main.py", line 18, in <module>
    module = SourceFileLoader(module_path, module_path).load_module()
  File "<frozen importlib._bootstrap_external>", line 522, in _check_name_wrapper
  File "<frozen importlib._bootstrap_external>", line 1022, in load_module
  File "<frozen importlib._bootstrap_external>", line 847, in load_module
  File "<frozen importlib._bootstrap>", line 265, in _load_module_shim
  File "<frozen importlib._bootstrap>", line 702, in _load
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 843, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/mnt/c/temp/main.py", line 3, in <module>
    import sub
ModuleNotFoundError: No module named 'sub'

이에 대한 정확한 기준은, 해당 경로가 sys.path에 포함돼 있는지입니다. 예를 들어, "python /mnt/c/test/call_main.py"라고 실행하면 sys.path는 기본적으로 이렇게 구성되는데,

[
    '/mnt/c/test', 
    '/home/kevin/miniconda3/envs/py38build/lib/python38.zip', 
    '/home/kevin/miniconda3/envs/py38build/lib/python3.8', 
    '/home/kevin/miniconda3/envs/py38build/lib/python3.8/lib-dynload', 
    '/home/kevin/miniconda3/envs/py38build/lib/python3.8/site-packages'
]

결국 최초 실행되는 call_main.py 파일을 포함한 경로(위의 경우 /mnt/c/test)가 sys.path에 포함되기 때문에 main.py는 sub.py를 찾을 수 없게 된 것입니다. 따라서 위의 코드를 어느 환경에서나 잘 동작하게 하려면 sys.path를 이런 식으로 조정해 주는 작업이 필요합니다.

module_path = '/mnt/c/temp'
module_name = 'main'

if not module_path in sys.path:
    sys.path.append(module_path)




참고로 SourceFileLoader.load_module 함수는 deprecated 되었으니,

Import arbitrary python source file. (Python 3.3+)
; https://stackoverflow.com/questions/19009932/import-arbitrary-python-source-file-python-3-3

대신 exec_module 함수를 사용하라고 권장하는군요. ^^ (그래도 테스트해보면 python 3.11까지도 잘 지원되고 있습니다.)

# module = SourceFileLoader(module_name, module_path).load_module()

loader = SourceFileLoader(module_name, module_path)
import types
mod = types.ModuleType(loader.name)
loader.exec_module(mod)




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 6/16/2025]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... [76]  77  78  79  80  81  82  83  84  85  86  87  88  89  90  ...
NoWriterDateCnt.TitleFile(s)
12067정성태11/27/201921042디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/201920576디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/201918450디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/201921900오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/201920839디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태11/21/201919949디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/201920131Windows: 167. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
12060정성태11/20/201922505디버깅 기술: 132. windbg/Visual Studio - HeapFree x64의 동작 분석
12059정성태11/20/201921682디버깅 기술: 131. windbg/Visual Studio - HeapFree x86의 동작 분석
12058정성태11/19/201922279디버깅 기술: 130. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례
12057정성태11/18/201917551오류 유형: 579. Visual Studio - Memory 창에서 유효한 주소 영역임에도 "Unable to evaluate the expression." 오류 출력
12056정성태11/18/201923786개발 환경 구성: 464. "Microsoft Visual Studio Installer Projects" 프로젝트로 EXE 서명 및 MSI 파일 서명 방법파일 다운로드1
12055정성태11/17/201917805개발 환경 구성: 463. Visual Studio의 Ctrl + Alt + M, 1 (Memory 1) 등의 단축키가 동작하지 않는 경우
12054정성태11/15/201919479.NET Framework: 869. C# - 일부러 GC Heap을 깨뜨려 GC 수행 시 비정상 종료시키는 예제
12053정성태11/15/201920624Windows: 166. 윈도우 10 - 명령행 창(cmd.exe) 속성에 (DotumChe, GulimChe, GungsuhChe 등의) 한글 폰트가 없는 경우
12052정성태11/15/201919387오류 유형: 578. Azure - 일정(schedule)에 등록한 runbook이 1년 후 실행이 안 되는 문제(Reason - The key used is expired.)
12051정성태11/14/201923679개발 환경 구성: 462. 시작하자마자 비정상 종료하는 프로세스의 메모리 덤프 - procdump [1]
12050정성태11/14/201921106Windows: 165. AcLayers의 API 후킹과 FaultTolerantHeap
12049정성태11/13/201921596.NET Framework: 868. (닷넷 프로세스를 대상으로) 디버거 방식이 아닌 CLR Profiler를 이용해 procdump.exe 기능 구현
12048정성태11/12/201921388Windows: 164. GUID 이름의 볼륨에 해당하는 파티션을 찾는 방법
12047정성태11/12/201923873Windows: 163. 안전하게 eject시킨 USB 장치를 물리적인 재연결 없이 다시 인식시키는 방법
12046정성태10/29/201918022오류 유형: 577. windbg - The call to LoadLibrary(...\sos.dll) failed, Win32 error 0n193
12045정성태10/27/201918435오류 유형: 576. mstest.exe 실행 시 "Visual Studio Enterprise is required to execute the test." 오류 - 두 번째 이야기
12044정성태10/27/201917597오류 유형: 575. mstest.exe - System.Resources.MissingSatelliteAssemblyException: The satellite assembly named "Microsoft.VisualStudio.ProductKeyDialog.resources.dll, ..."
12043정성태10/27/201919595오류 유형: 574. Windows 10 설치 시 오류 - 0xC1900101 - 0x4001E
12042정성태10/26/201918652오류 유형: 573. OneDrive 하위에 위치한 Documents, Desktop 폴더에 대한 권한 변경 시 "Unable to display current owner"
... [76]  77  78  79  80  81  82  83  84  85  86  87  88  89  90  ...