나무모에 미러 (일반/밝은 화면)
최근 수정 시각 : 2024-06-06 18:22:16

Python/구현체


파일:상위 문서 아이콘.svg   상위 문서: Python
1. 개요2. CPython3. Stackless Python4. GraalPy5. Pyston6. PyPy7. Jython8. IronPython9. Brython10. PyScript11. Transcrypt12. MicroPython13. RustPython14. Mojo15. codon16. Cython17. Numba18. Nuitka19. LPython

1. 개요

Python Implementations

Python은 Python 소프트웨어 재단에서 만들고 관리하는 언어로서 이를 각 운영체제에서 돌리기 위한 표준 런타임도 같은 단체에서 제작한다. 그러나 성능, 확장성 등 다양한 이유로 같은 Python 코드를 다른 방식으로 돌리기 위한 비표준 구현체들도 다양하게 개발되어 있다.

비표준 구현체들은 반복 계산, 특수한 환경에서는 유용할지 모르나 일반적인 용도로 사용하기에는 제약이 많다. 스스로 모든 코딩을 한다면 모르지만 다양한 패키지들을 불러들여 사용할 때에는 예상치 못한 오류를 잔뜩 마주하게 되기 때문이다. Python 패키지들은 CPython이라는 표준 구현체를 기준으로 제작되어 다른 구현체에서는 구조적으로 실행 자체가 불가능한 경우도 있다.

2. CPython

Python 소프트웨어 재단에서 만드는 표준 Python 구현체다.

보통 말하는 Python이 바로 이것이다. C로 구현되어 있다. 그냥 부를 땐 Python이라고 쓰고, 다른 구현체와 구분하여 언급할 때는 CPython이라고 표기한다. 공식 GitHub 리포지터리에서 소스 코드를 확인할 수 있다.

현재 Python의 창시자인 귀도와 Microsoft는 서로 협력해서[1] 기존의 CPython을 거의 5배 이상 빨라지게 만드는 것을 목표로 CPython을 최적화하는 작업을 진행 중이다. # 이른바 Faster CPython 프로젝트로, 위에서도 단점으로 지적되었던 Python 특유의 느린 실행 속도를 어떻게든 개선해보려는 것으로 보인다.[2] 이러한 노력의 결과로 파이썬은 조금씩 속도가 개선되고 있으며 파이썬 공식 문서에 따르면 파이썬 3.11은 3.10보다 속도가 10-60% 정도 빠르다고 한다.

3. Stackless Python

CPython에서 C 스택을 없앤 것이다.

Python의 표준 구현인 CPython은 이름 그대로 C로 만들어져 있는데, Python 프로그램의 함수 호출 스택(Call stack)을 구현할 때 그만 C의 호출 스택[3]에 그대로 얹어가도록 구현되고 말았다. 때문에 Python에서 얼마나 메모리를 많이 쓸 수 있느냐에 관계없이 C 호출 스택을 꽉 채우는 순간 그대로 스택 오버플로우 에러가 뜨게 되어버렸고[4], Python 프로그램의 호출 스택, 즉 프로그램의 실행 흐름을 CPython 스스로 제어할 수가 없게 되어 코루틴 등의 실행 흐름을 제어하는 언어 기능을 쓸 수 없게 되고 말았다.

Christian Tismer라는 개발자는 이 문제를 타파하려면 "CPython 소스코드를 수정해서[5] C 스택을 쓰는 부분을 전부 들어내고 새로 호출 스택을 짤 수밖에 없다"고 생각했고, 그것을 실제로 실행에 옮긴 것이 Stackless Python이다. 이름의 Stackless는 그래서 사실 C 호출 스택이 없다는 의미. Stackless Python은 스택 오버플로우 에러가 덜 난다는 사소한 장점[6] 외에도, 스스로 제어할 수 있는 자체적인 호출 스택을 갖고 있기 때문에 마이크로쓰레드[7]코루틴 같은 기능들을 쓸 수 있게 됐고, 덕분에 쓰레드도 고자고 코루틴도 안 되는 CPython에 비해 동시성 처리에서 훨씬 강력한 이득을 낼 수 있게 됐다. CPython도 3.4 버전 이후로 코루틴을 지원한다. 아래 멀티쓰레딩 섹션 참조.

다만, 앞서 말했듯이 CPython을 개조한 것이기 때문에, Python의 버전이 올라갈 때마다 개조한 코드가 이상 없이 동작하는지 항상 확인해야 하고, 이 기능이 운영체제나 하드웨어에도 영향을 받는 까닭에 심하면 각각의 운영체제나 CPU별로 개발을 따로 해야 하는 피곤한 작업을 Python이 망할 때까지 해야 하는 지겨운 길을 걷게 되는 것이었다. 그래서 실제로 한동안 Stackless Python의 개발이 잠시 중단된 일도 있었을 정도.

그런 와중에 PyPy 리드 개발자 Armin Rigo가 "C 호출 스택도 어차피 메모리에 있잖아? 그러면 그걸 'memcpy()'로 통째로 복사하고 덮어씌우면 호출 스택을 저장하고 복구하는 거 아냐?"라는 실로 마개조스러운 아이디어를 내놓는데, Christian Tismer가 여기에 매우 깊은 감명을 받고 Armin Rigo와 함께 구현한 결과 greenlet이라고 하는 import만 하면 코루틴을 쓸 수 있는 모듈을 만들어내기에 이른다. 같은 걸 구현하려고 언어 인터프리터 자체를 뜯어고치는 수고에 비하면 놀랄 만큼의 노력 절약이 아닐 수 없다. 다만 이 짓을 제대로 구현한 Stackless Python에 비하면 아무래도 성능이 딸리기 때문에 정말 절실하게 성능이 필요한 EVE 온라인과 같은 경우엔 Stackless Python을 쓴다.

하지만... Armin Rigo와 Christian Tismer는 지금 둘 다 PyPy를 만들고 있고, PyPy는 자체 스택을 쓸 수 있는 Stackless 모드의 JIT 컴파일러를 만들어낼 수 있다.

4. GraalPy

파일:상세 내용 아이콘.svg   자세한 내용은 GraalVM 문서
번 문단을
GraalPy 부분을
참고하십시오.

5. Pyston

C++로 구현된 Python 런타임이다.

2021년 기준으로는 리눅스에서만 사용 가능하다.

Pyston은 LLVM 컴파일러를 사용한다. Pyston은 JIT(just-in-time) 컴파일러를 내장하여 반복되는 소스 코드를 빠르게 실행할 수 있다.

2014년 4월 프로젝트가 시작되었으며, Python 2.7 호환, x86 64비트 플랫폼을 목표로 개발 중에 있다. Dropbox Tech Blog - Introducing Pyston: an upcoming, JIT-based Python implementation (April 3, 2014)

우분투에서만 테스트되고 있다. 그러다가 2017년 1월 31일부로 Dropbox에서 공식적으로 스폰싱을 종료했다. Pyston 0.6.1 released, and future plans (January 31, 2017) 메인테이너가 Dropbox 직원인데 더 이상 참여를 못 하는 사실상 프로젝트 중단이다. 직후 프로젝트 리더였던 Kevin Modzelewski는 퇴사하였다.

성능은 상당히 훌륭한 편이었으나, CPython과의 호환성을 오랫동안 맞추지 못했고, 프로젝트가 시작됐을 때와 다르게 Dropbox의 코드가 Go랑 Python3로 많이 이전된 것이 원인으로 보인다(즉, 굳이 투자하면서 개발을 지속할 이유가 없는 상황). 또한 곧 Python2 버전이 공식적으로 지원이 중단될 예정이라서 완전하게 돌아가게 되는 시점(이조차 아무도 알 수 없었다)에서 이 프로젝트의 의미가 많이 퇴색될 수밖에 없다.

홈페이지

6. PyPy

Python으로 만들어진 Python 런타임. 직관적으로는 느릴 것 같지만, JIT 컴파일을 사용하기 때문에 보통 Python보다 대부분의 경우에서 빠르다.
파일:상세 내용 아이콘.svg   자세한 내용은 PyPy 문서
번 문단을
부분을
참고하십시오.

7. Jython

Jython은 Java로 구현되어 JVM 위에서 실행된다.

# CPython이 C언어와 결합성, 접착성이 좋은 것처럼 Jython은 Java와 결합성이 대단히 좋으며, 실제로 Java 진영의 메이저 업체인 Oracle, IBM 등에서도 자사 제품에 Jython을 내장하여 스크립팅 기능을 제공하고 있을 정도다.

Jython은 JVM 위에서 실행되며, Python Module이 제공하는 API는 물론이고, JDK가 제공하는 모든 API를 그대로 사용할 수 있다. 오히려 pycrpyto와 같이 C언어로 구현된 CPython 모듈은 Jython에서 사용할 수 없다. 그러나 일단 Java Class라면, 설령 JNI로 되어있어서 C로 작성된 동적 모듈(*.dll, *.so 등)을 사용한다고 해도 Jython에서 사용하는데 아무런 제약이 없다. 또한 JVM 위에서 실행된다는 점 때문에 CPython의 GIL이 이식 되지 않았으며, CPython이 멀티쓰레드에서 보이는 단점이 Jython에는 존재하지 않는다. threading, threadsafety 등의 Python에서 제공하는 멀티쓰레드(락, 동기화 관련) 기능이 마음에 들지 않으면 java.util.concurrent에서 제공하는 Java API를 사용하면 된다!

가상머신에서 동작하는 구현체이다. 이렇게 시작부터 CLR 위에서 동작하는 Python 구현체를 도입하는 경우는 매우 드물다. 그래서 기존에 Java에서 개발되어 운영되던 프로그램이나 시스템이 존재하고, 이 환경 하에서 Python의 간결하고 편리한 기능과 높은 생산성을 도입하고자 할 때에만 사용된다.

CPython에 비하면 실행 속도가 매우 느리다. 따라서 주요 기능을 수행하는 데에는 문제가 있지만, 보조 기능에서 사용하면 번거로운 작업들을 매우 손쉽게 Python 스크립트로 Java의 자원을 그대로 끌어다 써서 할 수 있기 때문에 개발 공수와 편리함에서 큰 장점이 있다.

8. IronPython

Microsoft .NET Framework의 가상 머신인 CLR상에서 구현되고 이 위에서 동작하는 Python이다.

정확히 말하면 이들 동적 언어를 CLR 위에서 구현하기 위한 DLR이라는 프레임워크 기반이다. 제작자 Jim Hugunin#Jython의 제작자이며, NumPy의 전신인 Numeric 라이브러리의 제작자이기도 하다. 따라서 당연히 .NET Framework 환경에서 제작된 DLL과 결합성이 매우 좋다. Jython과 마찬가지로 병렬 프로그래밍 환경에서 GIL 때문에 고민할 필요가 없다.

자매품으로는 C#로 작성된 모듈을 마치 Python 모듈처럼 임포트해서 쓸 수 있는 Python for .NET이 있으며 이 경우에는 CPython 위에서 돌아간다.

9. Brython

웹 브라우저에서 Python을 사용할 수 있게 해 준다.

JavaScript로 구현되었고, JavaScript를 대신하여 웹 브라우저에서 스크립트 형태로 Python을 실행할 것을 목적으로 하는 'Brython'이 있다. Python3를 구현했으며, 다음과 같이 script 태그의 type을 text/python으로 지정하여 실행할 수 있다.

#!syntax python
<!DOCTYPE html>
<html>
<head>
  <title>Brython</title>
  <script src="brython.js"></script>
</head>
<body onload="brython()">
  <input id="zone"><button id="mybutton">click!</button>

  <script type="text/python">
    from browser import document, alert

    def echo(ev):
        alert(document['zone'].value)

    document['mybutton'].bind('click', echo)
  </script>
</body>
</html>

10. PyScript

Python 코드를 브라우저에서 실행할 수 있도록 만들어주는 프레임워크.

파일:상세 내용 아이콘.svg   자세한 내용은 PyScript 문서
번 문단을
부분을
참고하십시오.

11. Transcrypt

홈페이지

타입스크립트와 비슷한 방식으로 Python 코드를 자바스크립트로 컴파일해서 일반적인 자바스크립트와 혼합하여 사용할 수 있게 해준다. (Ex. Python + jQuery)

12. MicroPython

홈페이지
공홈에서 제공하는 웹 에뮬레이터

Python3의 기능을 임베디드 보드에 최적화하여 구현한 프로그래밍 언어이다. Windows OS와 Windows Embeded OS와의 관계를 생각하면 이해하기 쉽다. 국내에서는 주로 마이크로비트보드에서 사용할 목적으로 많이 사용된다. 카시오 FX-9860 GIII에 탑재되어 있기도 하다.

다만 퍼포먼스적인 문제가 심각하게 있는데 아두이노 등의 다른 프레임워크와 비교할 경우 눈에 띄게 느리고 마이너한 모습을 보여준다.[8]

경쟁 플랫폼으로는 아두이노, .NET NANO 등이 있다.

13. RustPython

홈페이지

프로그래밍 언어 Rust를 사용하여 구현된 인터프리터이다. CPython의 많은 표준 라이브러리가 구현되어 있고, 아직 미비하지만 JIT 컴파일 또한 제공한다.
다만 아직 개발 초기 단계이기 때문에 지원하지 않는 기능이 꽤 있으며, 성능상의 이점 또한 적은 편이다.

14. Mojo

파일:상세 내용 아이콘.svg   자세한 내용은 Mojo(프로그래밍 언어) 문서
번 문단을
부분을
참고하십시오.
Mojo - a new programming language for all AI developers

2023년 초부터 LLVM과 Swift를 만든 것으로 유명한 크리스 래트너(Chris Lattner)라는 개발자가 Mojo라는 새로운 언어를 만드는 작업에 착수했다. 파이썬의 쉬운 문법과 C의 고성능을 동시에 달성하기 위한 프로젝트이기 때문에 다양한 프로그래머로부터 많은 기대를 받고 있다. 그 뿐만 아니라 GPU를 언어 자체적으로 지원하기 때문에 AI나 그래픽 등의 분야에서 중점적으로 사용될 것이라고 밝히고 있다.

15. codon

파이썬의 네이티브 코드로의 AOT(Ahead of Time) 컴파일을 지원하는 컴파일러이다.GithubDocs

16. Cython

파일:상세 내용 아이콘.svg   자세한 내용은 Cython 문서
번 문단을
부분을
참고하십시오.

17. Numba

파일:상세 내용 아이콘.svg   자세한 내용은 Numba 문서
번 문단을
부분을
참고하십시오.

18. Nuitka

파일:상세 내용 아이콘.svg   자세한 내용은 Nuitka 문서
번 문단을
부분을
참고하십시오.

19. LPython

파일:상세 내용 아이콘.svg   자세한 내용은 LPython 문서
번 문단을
부분을
참고하십시오.

[1] 사실 단순 협력 수준도 아닌 현재 귀도는 MS직윈이다. 2020년 부근에 입사한것으로 추정되며 그의 트위터 프로필에도 MS에 근무중인 엔지니어라고 명시되어 있다.[2] 왜 MS가 나서서 이렇게 투자하나 의문인 사함들이 있을수 있는데 정황상 .NET의 DLR(Dynamic Language Runtime)환경에서 돌아가는 파이썬이 Cpython 베이스라 그랬을 가능성이 높다.[3] C 시간에 스택 영역 힙 영역 할 때 나오는 그 스택이다.[4] C 레벨에서 만들어주는 스택이라 "C로 짜여진 프로그램"인 CPython은 손을 댈 수가 없다. 원칙적으로는 말이지[5] CPython은 GPL 호환의 독자 라이선스를 가진 오픈소스 프로젝트다.[6] 메모리의 용량이 유한한 이상 스택 오버플로우 에러가 안 날 수는 없다.[7] OS가 직접 관리하는 쓰레드가 아닌, 유저 프로세스 차원에서 직접 돌리는 쓰레드. 그린 쓰레드(green thread)라고도 하는데 Ruby 1.8까지 지원하는 쓰레드가 바로 이것이다.[8] 보드가 다른 걸 감안해도 사용 보드인 라즈베리파이 Pico가 훨씬 클럭이 높다는 걸 감안하면 눈에 띄게 느린 게 맞다.

파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는
문서의 r1868
, 6번 문단
에서 가져왔습니다. 이전 역사 보러 가기
파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는 다른 문서에서 가져왔습니다.
[ 펼치기 · 접기 ]
문서의 r1868 (이전 역사)
문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

문서의 r (이전 역사)

분류