확장 모듈 정의
**************

A C extension for CPython is a shared library (for example, a ".so"
file on Linux, ".pyd" DLL on Windows), which is loadable into the
Python process (for example, it is compiled with compatible compiler
settings), and which exports an *export hook* function (or an old-
style initialization function).

기본적으로 임포트 가능하려면(즉,
"importlib.machinery.ExtensionFileLoader"에 의해), 공유 라이브러리는
"sys.path" 에 있어야 하고, 모듈 이름에
"importlib.machinery.EXTENSION_SUFFIXES" 에 나열된 확장자를 붙인 이름
이어야 합니다.

참고:

  확장 모듈을 빌드, 패키징 및 배포하는 작업은 제삼자 도구를 사용하는
  것이 가장 좋으며, 이 문서의 범위를 벗어납니다. 적합한 도구 중 하나는
  Setuptools로, 문서는
  https://setuptools.pypa.io/en/latest/setuptools.html 에서 찾을 수 있
  습니다.


Extension export hook
=====================

Added in version 3.15: Support for the "PyModExport_*<name>*" export
hook was added in Python 3.15. The older way of defining modules is
still available: consult either the PyInit function section or earlier
versions of this documentation if you plan to support earlier Python
versions.

The export hook must be an exported function with the following
signature:

PySlot *PyModExport_modulename(void)

For modules with ASCII-only names, the export hook must be named
"PyModExport_*<name>*", with "<name>" replaced by the module's name.

For non-ASCII module names, the export hook must instead be named
"PyModExportU_*<name>*" (note the "U"), with "<name>" encoded using
Python's *punycode* encoding with hyphens replaced by underscores. In
Python:

   def hook_name(name):
       try:
           suffix = b'_' + name.encode('ascii')
       except UnicodeEncodeError:
           suffix = b'U_' + name.encode('punycode').replace(b'-', b'_')
       return b'PyModExport' + suffix

The export hook returns an array of "PySlot" entries, terminated by an
entry with a slot ID of "0". These slots describe how the module
should be created and initialized.

This array must remain valid and constant until interpreter shutdown.
Typically, it should use "static" storage. Prefer using the
"Py_mod_create" and "Py_mod_exec" slots for any dynamic behavior.

The export hook may return "NULL" with an exception set to signal
failure.

It is recommended to define the export hook function using a helper
macro:

PyMODEXPORT_FUNC
    * This macro is available when compiling for the 안정 ABI 버전
   3.15 이후로.*

   Declare an extension module export hook. This macro:

   * specifies the PySlot* return type,

   * 플랫폼에 필요한 특수 링크 선언을 추가하며,

   * C++의 경우 함수를 "extern "C"" 로 선언합니다.

예를 들어, "spam" 이라는 모듈은 다음과 같이 정의됩니다:

   PyABIInfo_VAR(abi_info);

   static PySlot spam_slots[] = {
       PySlot_STATIC_DATA(Py_mod_abi, &abi_info),
       PySlot_STATIC_DATA(Py_mod_name, "spam"),
       PySlot_FUNC(Py_mod_init, spam_init_function),
       ...
       PySlot_END
   };

   PyMODEXPORT_FUNC
   PyModExport_spam(void)
   {
       return spam_slots;
   }

The export hook is typically the only non-"static" item defined in the
module's C source.

The hook should be kept short. If it does more than "return" a static
array, several caveats apply:

* If you need to use any Python C API, it is recommended to call
  "PyABIInfo_Check()" first to raise an exception, rather than crash,
  in common cases of ABI mismatch.

* Code in the export hook must never rely on the *GIL*: *free-threaded
  builds* of Python can only check the "Py_mod_gil" slot (or the lack
  of it) after the hook returns,

* Similarly, the hook may be called in any subinterpreter, since the
  "Py_mod_multiple_interpreters" slot (or lack of it) is only checked
  after the hook returns.

For example:

   PyMODEXPORT_FUNC
   PyModExport_modulename(void)
   {
      if (PyABIInfo_Check(&abi_info, "modulename") < 0) {
         /* ABI mismatch. It's not safe to examine the raised exception. */
         return NULL;
      }

      /* use Python API (as little as possible); don't rely on GIL */

      return modulename_slots;
   }

참고:

  It is possible to export multiple modules from a single shared
  library by defining multiple export hooks. However, importing  them
  requires a custom importer or suitably named copies/links of the
  extension file, because Python's import machinery only finds the
  function corresponding to the filename. See the Multiple modules in
  one library section in **PEP 489** for details.


다단계 초기화
=============

The process of creating an extension module follows several phases:

* Python finds and calls the export hook to get information on how to
  create the module.

* Before any substantial code is executed, Python can determine which
  capabilities the module supports, and it can adjust the environment
  or refuse loading an incompatible extension. Slots like
  "Py_mod_abi", "Py_mod_gil" and "Py_mod_multiple_interpreters"
  influence this step.

* By default, Python itself then creates the module object -- that is,
  it does the equivalent of calling "__new__()" when creating an
  object. This step can be overridden using the "Py_mod_create" slot.

* Python sets initial module attributes like "__package__" and
  "__loader__", and inserts the module object into "sys.modules".

* Afterwards, the module object is initialized in an extension-
  specific way -- the equivalent of "__init__()" when creating an
  object, or of executing top-level code in a Python-language module.
  The behavior is specified using the "Py_mod_exec" slot.

This is called *multi-phase initialization* to distinguish it from the
legacy (but still supported) single-phase initialization, where an
initialization function returns a fully constructed module.

버전 3.5에서 변경: 다단계 초기화 지원이 추가되었습니다 (**PEP 489**).


다중 모듈 인스턴스
==================

By default, extension modules are not singletons. For example, if the
"sys.modules" entry is removed and the module is re-imported, a new
module object is created and, typically, populated with fresh method
and type objects. The old module is subject to normal garbage
collection. This mirrors the behavior of pure-Python modules.

추가 모듈 인스턴스는 서브 인터프리터 에서 또는 파이썬 런타임 재초기화
("Py_Finalize()" 와 "Py_Initialize()") 후에 생성될 수 있습니다. 이 경
우 모듈 인스턴스 간에 파이썬 객체를 공유하면 크래시나 정의되지 않은 동
작이 발생할 가능성이 있습니다.

이러한 문제를 피하려면 확장 모듈의 각 인스턴스가 *격리*되어야 합니다:
한 인스턴스의 변경이 다른 인스턴스에 묵시적으로 영향을 주어서는 안 되
며, 파이썬 객체에 대한 참조를 포함하여 모듈이 소유한 모든 상태는 특정
모듈 인스턴스에 한정되어야 합니다. 자세한 내용과 실용적인 안내는
Isolating Extension Modules를 참조하십시오.

이러한 문제를 피하는 더 간단한 방법은 반복 초기화 시 에러 발생시키기입
니다.

모든 모듈은 서브 인터프리터를 지원하거나, 그렇지 않으면 지원하지 않음
을 명시적으로 알려야 합니다. 이는 위에서 설명한 것처럼 격리 또는 반복
초기화 차단을 통해 보통 달성됩니다. 모듈은
"Py_mod_multiple_interpreters" 슬롯을 사용하여 메인 인터프리터로만 제
한될 수도 있습니다.


"PyInit" function
=================

Soft deprecated since version 3.15: This functionality will not get
new features, but there are no plans to remove it.

Instead of "PyModExport_modulename()", an extension module can define
an older-style *initialization function* with the signature:

PyObject *PyInit_modulename(void)

Its name should be "PyInit_*<name>*", with "<name>" replaced by the
name of the module. For non-ASCII module names, use "PyInitU_*<name>*"
instead, with "<name>" encoded in the same way as for the export hook
(that is, using Punycode with underscores).

If a module exports both "PyInit_*<name>*" and "PyModExport_*<name>*",
the "PyInit_*<name>*" function is ignored.

Like with "PyMODEXPORT_FUNC", it is recommended to define the
initialization function using a helper macro:

PyMODINIT_FUNC

   확장 모듈 초기화 함수를 선언합니다. 이 매크로는:

   * PyObject* 반환 형을 지정하고,

   * 플랫폼에 필요한 특수 링크 선언을 추가하며,

   * C++의 경우 함수를 "extern "C"" 로 선언합니다.

Normally, the initialization function ("PyInit_modulename") returns a
"PyModuleDef" instance with non-"NULL" "m_slots". This allows Python
to use multi-phase initialization.

Before it is returned, the "PyModuleDef" instance must be initialized
using the following function:

PyObject *PyModuleDef_Init(PyModuleDef *def)
    * Part of the 안정 ABI 버전 3.5 이후로.*

   모듈 정의기 형과 참조 횟수를 정확하게 보고하는 제대로 초기화된 파이
   썬 객체임을 보장해야 합니다.

   에러가 발생하면 "NULL" 을, 그렇지 않으면 "PyObject*" 로 캐스팅된
   *def*를 반환합니다.

   Calling this function is required before returning a "PyModuleDef"
   from a module initialization function. It should not be used in
   other contexts.

   파이썬은 "PyModuleDef" 구조체가 정적으로 할당된다고 가정합니다. 이
   함수는 새 참조 또는 빌린 참조를 반환할 수 있으며, 이 참조는 해제해
   서는 안 됩니다.

   Added in version 3.5.

예를 들어, "spam" 이라는 모듈은 다음과 같이 정의됩니다:

   static struct PyModuleDef spam_module = {
       .m_base = PyModuleDef_HEAD_INIT,
       .m_name = "spam",
       ...
   };

   PyMODINIT_FUNC
   PyInit_spam(void)
   {
       return PyModuleDef_Init(&spam_module);
   }


레거시 단일 단계 초기화
-----------------------

Soft deprecated since version 3.15: 단일 단계 초기화는 확장 모듈을 초
기화하는 레거시 메커니즘으로, 알려진 단점과 설계상 결함이 있습니다. 확
장 모듈 작성자는 대신 다단계 초기화를 사용하도록 권장됩니다.However,
there are no plans to remove support for it.

In single-phase initialization, the old-style initialization function
("PyInit_modulename") should create, populate and return a module
object. This is typically done using "PyModule_Create()" and functions
like "PyModule_AddObjectRef()".

단일 단계 초기화는 다음과 같은 점에서 기본 단계와 다릅니다:

* 단일 단계 모듈은 "싱글톤"이거나 오히려 "싱글톤"을 *포함* 합니다.

  모듈이 처음 초기화될 때, 파이썬은 모듈의 "__dict__" 내용(즉, 일반적
  으로 모듈의 함수와 형)을 저장합니다.

  이후 임포트에서는 파이썬이 초기화 함수를 다시 호출하지 않습니다. 대
  신 새 "__dict__" 를 가진 새 모듈 객체를 생성하고 저장된 내용을 복사
  합니다. 예를 들어, 함수 "sum" 과 예외 클래스 "error" 를 정의하는 단
  일 단계 모듈 "_testsinglephase" [1] 가 있다고 가정하면:

     >>> import sys
     >>> import _testsinglephase as one
     >>> del sys.modules['_testsinglephase']
     >>> import _testsinglephase as two
     >>> one is two
     False
     >>> one.__dict__ is two.__dict__
     False
     >>> one.sum is two.sum
     True
     >>> one.error is two.error
     True

  정확한 동작은 CPython 구현 세부 사항으로 간주해야 합니다.

* "PyInit_modulename"이 *spec* 인자를 받지 않는다는 사실을 우회하기 위
  해, 임포트 장치의 일부 상태가 저장되어 "PyInit_modulename" 호출 중에
  생성되는 첫 번째 적합한 모듈에 적용됩니다. 구체적으로, 서브 모듈이
  임포트될 때 이 메커니즘은 부모 패키지 이름을 모듈 이름 앞에 붙입니다
  .

  단일 단계 "PyInit_modulename" 함수는 다른 모듈 객체가 생성되기 전에
  가능한 한 빨리 "자신의" 모듈 객체를 생성해야 합니다.

* ASCII가 아닌 모듈 이름("PyInitU_modulename")은 지원되지 않습니다.

* 단일 단계 모듈은 "PyState_FindModule()" 같은 모듈 조회 함수를 지원합
  니다.

* The module's "PyModuleDef.m_slots" must be NULL.

[1] "_testsinglephase" 는 CPython의 자체 테스트 스위트에서 사용되는 내
    부 모듈로, 설치 환경에 따라 포함될 수도 있고 포함되지 않을 수도 있
    습니다.
