Python


Python 2.x

<syntaxhighlight lang="python" line="1">
print 'hello world!'
</syntaxhighlight>

Python 3.x [1]

<syntaxhighlight lang="python" line="1">
print('hello world!')
</syntaxhighlight>

{

TIOBE에서 선정한 프로그래밍 언어 월간 점유율 순위 (2017년 3월 기준)
자세한 내용은 이곳에서 확인할 수 있으며, 점유율을 정하는 기준은 다음과 같다.
1. Java2. C3. C++4. C\#5. Python
점유율 16.384%
작년 대비 4.14% 감소		점유율 7.742%
작년 대비 6.86% 감소		점유율 5.184%
작년 대비 1.54% 감소		점유율 4.409%
작년 대비 0.14% 증가		점유율 3.919%
작년 대비 0.34% 감소
Life is too short, You need Python. [2]

인생은 짧다, 그래서 파이썬이 필요하다.

1 개요

1991년에 발표된 프로그래밍 언어의 일종. 공식 홈페이지

창시자는 귀도 판 로썸(Guido van Rossum).[3]1989년 크리스마스 주에, 연구실이 닫혀있어서 심심한 김에 만들었다. 파이선 서문과 마이크로소프트웨어와 한 인터뷰를 보면 알겠지만 사실이다.(…) 공돌이들은 심심할 때 항상 걸작이 나온다.리눅스도 그렇고..

이름은 귀도가 즐겨 보던 영국의 6인조 코미디 그룹 몬티 파이선에서 따왔다고 한다. 많은 파이썬 교재들에서 변수 이름을 spam, eggs로 짓는 등 드립을 친다. 직접적 관계는 없지만 42도 필수요소.

문법이 매우 쉬워서 초보자들이 처음 프로그래밍을 배울때 추천되는 언어이다. 실제로도 미국 공과 대학교에서 컴퓨터 프로그래밍 입문 수업으로 파이썬을 많이 사용하기도 한다. 동시에 실사용률과 생산성도 높은 강력한 언어. 포덕이라면 스타팅 포켓몬을 생각해보자 이상해꽃 장크로다일 번치코 대짱이 초염몽 개굴닌자 역시 시작이 반이다 하지만 치코리타를 고른다면

혹시 파이썬에 관심이 있다면 [1] 이곳에 가보자. 초보자들을 위한 가이드가 있다. 심지어 한국어다!

2 언어 구현

보통 말하는 Python은 C언어로 구현되었으며, 다른 구현체와 구분하여 언급할 때에는 CPython이라고 표기한다. C#으로 구현된 닷넷프레임워크 위에서 동작하는 IronPython, CPython에서 C 스택을 없앤 Stackless Python, Java로 구현되어 JVM위에서 돌아가는 Jython, 파이썬 자체로 구현된 PyPy 등이 있으며 이 가운데 오리지날은 CPython이다. 또한, 현재[4] Dropbox에서 Pyston이란 LLVM과 JIT 기반 파이썬을 개발 중이다.DROPBOX TECH BLOG [5]

한편 중국에서는 Chinese Python이라는, 중국어 문법으로 한자를 쳐서 돌아가는 언어를 독자 개발했다. 오오 대륙의 기상 오오

Python으로 할 수 있는 것들을 모아놓은 곳도 있다!

2.1 Python 3.x

사용자가 늘다 보니 여러 단점들이 지적되었는데, 과감하게 하위 호환성을 포기하고 Python 3000 이라는 코드명으로 개발하기 시작하여 발표된 버젼이다. 내부적으로는 많이 변했다고 하는데 겉보기에는 별로 변한 것 같지 않다는 것이 함정. 그러나 소소한 부분에서 문법과 기본 라이브러리에 차이가 있어 호환이 되지 않는다. 2to3이라는 python2를 python3로 바꿔주는 컨버터가 있어서 전부 갈아 엎어야 하는 수고는 덜 수 있다.

Python을 실제로 사용하게 되면, 구현에 필요한 기능을 지원하는 여러 패키지를 받아서 설치해 사용하게 된다. Python 2.x vs Python 3.x 에서 선택은 주로 "내가 사용하기 원하는 패키지가 동작하는 환경"에 따라서 선택하게 된다.

Python 3.x부터는 C++, Java, 액션스크립트 등처럼 내부적으로 모든 문자열을 유니코드로 처리한다. 덕분에 변수나 함수 이름을 한글로 정할 수도 있게 되었다. 그러니까...


<syntaxhighlight lang="python" line="1">
이름 = "홍길동"
나이 = 17
보여줘 = print

보여줘('{} {}'.format(이름, 나이))
</syntaxhighlight>

이런 식으로. 하지만 프로그래머는 이렇게 안쓴다 한영키 누르기가 얼마나 귀찮은데

문제는 유니코드 문자열의 한 글자가 플랫폼 및 빌드 옵션에 따라 무조건 2바이트 또는 4바이트를 차지한다는 것. Python 2.x은 기본문자열이 바이너리문자열로 처리되기 때문에 한글자가 1바이트만 차지한다. 하지만 Python 3.x는 기본문자열이 항상 유니코드이고, UCS-4를 모두 지원하기 위해 문자 당 4바이트를 할당하는 "wide" 빌드의 Python 3.x는 100MB 길이의 아스키 문자열을 위해 400MB의 램을 사용한다. 따라서 문자열 처리에서 메모리가 낭비될 뿐만 아니라 처리시간도 늦어져 성능이 떨어지는 것은 당연지사. 2.x 코드를 3.x에서 돌렸는데 많이 느리다면 문자열과 관계된 문제일 가능성이 높다.

이런 문제를 해결하기 위해, Python 3.3 버전 이후부터는 문자열 객체에서 가장 많은 공간(바이트)을 차지하는 문자를 기준으로 각 문자가 차지할 공간을 정하도록 변경되었다. 따라서 문자열에 아스키 문자만 포함된다면 각 문자가 1바이트씩만 차지하므로 더 이상 이런 문제가 생기지 않는다. 이런 경우는 심지어 유니코드임에도 Python 2.x의 유니코드 문자열보다 적은 메모리 공간을 차지할 수도 있다! 또한 UCS-4를 모두 지원하는 "wide" 빌드와 UCS-2만 지원하는 "narrow" 빌드의 구분도 사라졌다. 하지만 크기가 변경될 때 그 만큼 속도가 느려지니 장단점이 있다.

2.7버전은 더이상 업데이트가 없는 미래가 없는 버전이다.[6] 문제는 지금 있는 거의 모든 자료는 2.7버전이라는 것..

2.2 Stackless Python

[2]

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

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

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

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

하지만... Armin Rigo와 Christian Tismer는 지금 둘 다 PyPy를 만들고 있고, PyPy는 자체 스택을 쓸 수 있는 Stackless 모드의 JIT 컴파일러를 만들어낼 수 있다. 본격 자기 프로젝트 능욕 Stackless는 안될거야 아마

2.3 Pyston

LLVM과 현대적인 JIT 기술을 사용해서 개발 중인 오픈 소스 파이썬 구현물
2014년 4월 프로젝트가 시작되었으며, Python 2.7 호환, x86 64비트 플랫폼을 목표로 개발 중에 있다. 우분투에서만 테스트되고 있다.

2.4 PyPy

본격 Python으로 직접 구현되는 Python. 언뜻 보면 CPython보다 느릴 것 같지만 실제로는 더 빠른 실행결과도 보여주는 흠좀무한 녀석이다. 어떠한 외계의 기술이 적용되어서 이것이 가능한지는 해당 항목을 참조하라.

2.5 C 언어 확장, Cython

Python의 속도를 높이고자 아예 C언어로 변환하여 컴파일하는 방법을 택한 패키지. 정적 타입 선언과 함께 C언어로 변환되어 컴파일된다는 점 때문에 ctypes 로 덧씌우는 것 없이 네이티브 코드(*.so, *.dll)를 직접 사용할 수 있다. 이것을 사용하면 적게는 열 배 정도에서 많게는 천 배 이상까지 속도 향상을 경험할 수 있다.

2.6 웹 브라우저에서 실행될 것을 목적으로 하는 Brython

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


<syntaxhighlight lang="python" line="1">
<!DOCTYPE html> Brython click! from browser import document, alert
def echo(ev):
alert(document['zone'].value)
document['mybutton'].bind('click', echo) </syntaxhighlight>

2.7 가상 머신에서 동작하는 구현체

2.7.1 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에는 존재하지 않는다. 대신 당연하지만 JVM이 가지는 제약을 그대로 가진다. 그런데 이건 지난 십 수년간 꾸준히 개선되어서 이제 많이 괜찮아졌잖아? threading, threadsafety등의 Python에서 제공하는 멀티스레드(락, 동기화 관련) 기능이 마음에 들지 않으면 java.util.concurrent 에서 제공하는 Java API를 사용하면 된다!!!

2.7.2 IronPython

Microsoft .net Framework의 가상머신인 CLR 상에서 구현되고 이 위에서 동작하는 Python 이다.[13] 따라서 당연히 .net Framework 환경에서 제작된 DLL과 결합성이 매우 좋다. Jython과 마찬가지로 병렬 프로그래밍 환경에서 GIL 때문에 고민할 필요가 없다.

2.7.3 Jython이나 IronPython은 왜 쓰는 걸까?

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

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

3 장점

3.1 높은 생산성

python.png
xkcd 353화 'Python'

인터프리터 언어이면서 우수한 자료형과 다양한 모듈 등을 제공해 개발기간이 매우 단축되는 것이 특징. 'C언어로 2년동안 완성하지 못한 프로젝트를 파이썬으로 한달만에 해냈다'는 극적인 경험담이 있을 정도다. C언어와의 접착성도 좋기 때문에, 일단 Python으로 빨리 구현하고, 남은 시간에 속도에 병목이 되는 부분을 C로 전환하는 전략을 내세우고 있다.[14] 맛들이면 다른 언어로 전환하기 힘든 부작용이 생긴다 카더라.

참고로 저 만화는 파이썬 내에 이스터 에그로 삽입되기도 했다. antigravity 모듈을 불러오면[15] 나온다.영상

3.2 반복 가능한 객체

파이썬의 가장 큰 특징 중 하나. 파이썬은 반복 가능한 객체(iterable)라는 강력한 기능을 제공한다. 이 객체는 집합, 문자열, 리스트, 튜플, 딕셔너리, 그리고 함수[16]까지도 반복이 가능하며, 이것을 for 구문에서 사용할 수 있게 해준다. 리스트와 튜플 등은 좀 편해지는 정도라 할 수 있지만, 함수의 값을 반복할 수 있다는 것은 큰 장점이다. 그 예로 n의 배수를 구하는 f(n) 함수가 있을 때,


<syntaxhighlight lang="python" line="1">
def f(n):
x = 1while 1:yield n*xx += 1

</syntaxhighlight>
와 같은 함수를 만드는 것도 가능하다. 함수를 호출하고 나서도 함수가 완전히 끝나기 전까지는 지역 변수가 남아있으며, 함수가 끝나야 지역변수가 삭제된다. 따라서 함수를 호출할 때마다 x의 값이 증가한다.

3.3 디자인 철학

Perl의 '하나 이상의 해결법이 존재한다' 와는 정반대로 '가장 아름다운 하나의 답이 존재한다'라는 명제를 모토로 하고 있다.[17] 이 모토 하에 다음과 같은 철학을 지니게 되었다. [18]

  • 아름다운 것이 추한 것보다 낫다.(Beautiful is better than ugly)
  • 명시적인 것이 암시적인 것보다 낫다. (Explicit is better than implicit)
  • 간결한 것이 복잡한 것보다 낫다. (Simple is better than complex)
  • 정교한 것이 난잡한 것보다 낫다. (Complex is better than complicated)

따라서 다른 언어들의 코딩 스타일은 각자의 취향에 맞게 발산진화 하는 반면[19], 파이썬은 위의 철학들을 만족시키는 하나의 스타일로 수렴진화하는 성향이 있다. 이런 성향은 다른언어에는 없는 파이썬스러움(pythonic)이라는 독특한 개념을 낳게 되었는데, 복잡하지 않으면서 의미가 명확하고, 심플한, 파이썬의 철학을 따르는 것들을 지칭하는 개념이다.

이런 철학 때문에 문법이 굉장히 엄격한 편이다. 예를 들자면, 다른 언어에서는 해도 되고 안 해도 되는 들여쓰기가 이 언어에서는 의무로 들여쓰기 자체로 하나의 코드 블럭이 된다. 코드 블럭을 명시적으로 표시하지 않아도 돼서 비주얼 적으로는 굉장히 깔끔한 반면[20], 자유도를 제약한다는 평도 있다. 다만 들여쓰기 하나로 괄호를 2개나 생략하기 때문에, 귀찮은 부분이 상당히 사라지기도 한다.


<syntaxhighlight lang="python" line="1">
def factorial(x):
if x == 0:return 1
else:return x * factorial(x - 1)

</syntaxhighlight>

3.4 만능 언어

인터넷상 Python으로 보급되는 패키지는 굉장히 다양하고 방대하게 제공된다[21]그러나 요즘 만능 아닌 언어 거의 없다. 당신이 하려는 것이 무엇이든, 무슨 언어를 써야 할지 모르겠으면 Python을 쓰면 된다. Python 으로 직접 만들었거나 또는 다른 프로그램의 Wrapper가 꼭 존재한다. 사실상 못하는 것이 없다. 웹 사이트 서버를 구현하려고 하면 Python Web Framework 를 쳐보자 (Django, Flask, Bottle 등). 기계학습 알고리즘을 쓰고 싶다면 python machine learning 이라 검색하자 (scikit-learn). 얼굴인식을 코드 몇 줄로 할 수도 있다 (OpenCV). 기본적으로 설치되는 모듈인 tkinter모듈을 이용하면 간단한 gui프로그래밍을 할 수 있다. 게임도 만들 수 있다 (PyGame). Python make girlfriend 도 된다 카더라 안돼 돌아가 비주얼 노벨도 만들 수 있다. 비주얼 노벨 전문툴 Ren'Py 참조. 그래도 괴수들은 렌파이로 카드게임도 만든다.

물론 그렇다고 Python만 쓰는 것이 답은 아니다. 실행 속도와 Python 자체의 한계로 당연히 C, C++ 같은 언어의 연산속도를 따라갈 수는 없으며, 사실 JavaScript나 LISP계열 언어 등 동적 언어들을 전체를 주욱 놓고 비교 해봐도 속도가 빠른 편은 아니다. 보통 인터프리터 언어의 속도 문제를 극복하기 위해서 인터프리터에 JIT 컴파일러를 넣는 추세지만 Python의 표준인 CPython에서는 구현이 되어있지 않다.[22] R 과 같이 특정분야에 특화된 언어와 비교하면 꼭 라이브러리가 더 다양하다고 볼 수도 없다. 이에 대해서 추가바람

그리고 동적 타입 언어(dynamically typed language)라는 점이 큰 프로젝트에서는 단점으로 작용하여 자료구조 설계나 디버깅이 어렵다는 지적도 있다. 다만 정적 타입 vs. 동적 언어 논쟁은 서로의 장단점이 있으며 일종의 종교논쟁으로 취급받는다. 일례로 OCaml같은 강력한 타입 인터페이스(Hindley-Milner)를 가진 경우, 모든 타입 에러(!)를 컴파일 타임에 잡아낼 수 있는 반면에, 모든 버그가 타입 에러는 아니기 때문에 여전히 테스트 및 디버깅 과정은 필요하며, 타입 시스템으로 인한 부담 때문에 빠른 구현에는 부담이 될 수 있다. 반면에 동적 언어는 빠른 구현의 이점이 있지만 타입 에러가 많이 나는 특징이 있다.[23] 그러나 커버리지가 높은 테스트 세트로 어느정도 커버할 수 있으며 최근의 추세와 부합하는 방식이기도 하다. 또한 Python 3.5부터는 Type Hints를 이용해서 변수가 가질 수 있는 타입을 지정할 수 있게되었다. 성능향상에 도움은 안되지만 가능한 오류를 쉽게 찾아낼 수 있으며 PyCharm과 같은 IDE 프로그램을 이용하면 향상된 code completion의 도움을 받을 수 있다.

특정 언어를 어떻게든 돌아가게 짜는 것은 노가다를 배우는 것이라면, 프로그램의 설계는 건축가가 거대한 빌딩을 설계하는 작업이라고 할 수 있다. 1 ~ 2층 정도의 작은 집은 오로지 노가다로 해결한다고 해도, 부르즈 할리파는 이런식으로 지을 수 없다. 적절한 자재, 하중을 지탱할 수 있는 구조, 외력 등을 고려해서 설계해야 한다. 이렇게 하기 위해서는 알고리즘과 자료구조, 아키텍쳐 등의 공학적 지식과 경험이 있어야 하며, 제대로 훈련된 프로그래머와 단순 코더가 짠 코드는 생산성, 탄탄함, 버그 발생률, 확장 가능성에서 큰 차이가 난다.

빠른 아이디어 구현이 생명인 연구소에서 각광을 받고 있고, 한국 밖에서는 당당한 주류 언어로 대우받고 있다. 인스타그램, 유튜브, reddit 등이 Python을 주로 쓰고 있다고 알려져 있으며, 외국의 구인 사이트에도 Python을 할 줄 아는 사람에 대한 수요가 많다. 컴퓨터 관련이 아닌 이공계 전반에서 많이 쓰이는 MATLAB은 오픈소스가 아니라는 점이 최근 추세와 맞지 않아 입지가 좁아지고 있다.[24] 게다가 패키지 설치를 참 더럽게 이상하게 만들어놨다. MatLab과 같은 목적의 파이썬 패키지인 NumPy는 모종의 계약을 통해 문법과 함수 등의 많은 부분에서 MatLab 함수와 호환되게 수정해 버렸고, 안그래도 꽤 쓰였던 NumPy는 더욱 사용자가 늘어나고 있다. Python의 경우는 지원 라이브러리의 대부분이 오픈소스이기 때문에 저장소에서 그냥 커맨드 라인 (pip install 패키지) 한 줄로 필요한 거의 모든 패키지를 설치해서 쓸 수 있다. 물론 PyQt 같은 예외도 분명히 존재한다.

대학교 프로그래밍 교육은, 예전에는 한국을 포함하여 대부분의 학교에서 C, C++ 나 Java 같은 실제 회사에서 많이 쓰는 언어 위주로 수업을 개설했으나, 미국대학들은 개론 수업 언어를 Python 으로 옮겨가는 추세다. (UC 버클리 컴퓨터과학 개론수업인 CS 61A 를 인터넷 강의로 들어보자!) 참고로, 연세대학교[25], 카이스트,부산대학교 ,국민대학교,인천대학교, 한양대학교 ERICA 캠퍼스에서는 프로그래밍 개론 수업을 Python 으로 진행한다.

마지막으로, Python이 배우기 쉽다고 해도 결국 도구일 뿐이고, 프로그래밍 자체를 마냥 쉬운 것으로 생각하면 큰 코 다친다. 프로그래밍을 할 수 있는 것과 좋게 하는 것에는 큰 차이가 있으며, 좋은 프로그래밍을 하는 것은 프로그래머의 역량에 좌우된다.

게다가 요즘은 프로그래밍 언어와 프레임웍의 춘추 전국 시대라고 할 수 있을만큼 매우 많은 새로운 언어와 프레임웍이 등장하고 있으며, 아예 폴리글랏(Polyglot[26]) 프로그래밍이라는 용어가 등장하는 시대다. 당장 구글만 해도 C/C++, Java, Python을 골고루 섞어서 쓴다고 알려져 있으며, 게임도 메인은 C++ 로 작성되었으나 스크립팅은 Python이나 Lua로 된 경우(시드 마이어의 문명, WOW 등)을 매우 쉽게 찾아볼 수 있다. 따라서 필요하다면 프로그래밍 언어를 가리지 않고 매우 능숙할 수 있게 사용할 수 있도록 공부해야 하며, 알고리즘, 디자인 패턴, 테스트 기법, 동시성 프로그래밍(멀티스레드, 멀티프로세스)등의 필요한 지식을 훤하게 꿰고 있어야 제대로 된 프로그래머/개발자가 될 수 있다.

4 단점

4.1 멀티스레딩 문제

파이썬은 멀티스레딩을 지원하기 위하여 GIL(Global Interpreter Lock), 즉 전역 인터프리터 락을 도입하여 사용하게 되었다. 따라서, python 스레드 10개를 만들어도 실제 Pthread/윈도우 스레드가 10개가 만들어지긴 하는데, GIL때문에 개중 동시에 하나밖에 안돌아가는 기이한 구조를 갖고 있다. [27] 이것은 구현이 매우 쉬워지고 빠른 개발을 할 수 있다는 장점이 있으나 다중 코어 CPU가 보편화된 2006년 이후에는 다중 코어를 제대로 활용하지 못하는 구조적인 문제 때문에 성능에서 밀린다는 평가를 받게 되었다. 만일 특정 프로그램에 순진하게 CPU 코어를 2개 이상 동원하려고 할 경우, 뮤텍스(MutEx), 즉 한 스레드에 여러개의 CPU가 연산을 행하여 내부 정보를 오염시키는 것을 방지하는 역할을 맡는 GIL이 병목 현상을 일으켜 코어 하나를 쓸 때보다 오히려 성능이 크게 저하된다는 것. 구글 내부에서 이미 가루가 되도록 까인 부분이다.

이런 문제점 때문에 파이썬에서 병렬 처리가 필요할때는 다중 스레드가 아닌 다중 프로세스로 GIL을 우회하는 방식을 사용한다. 2008년 이후에 multiprocessing이라는 모듈을 제공하는데 이 모듈은 자식 프로세스를 만드는 방향으로 다중 코어 사용시 성능의 향상을 꾀하고 있다.

단, CPU 부하가 큰 작업을 돌리는 것이 아니면 GIL을 체감하기는 생각보다 쉽지 않다. 다중 쓰레딩으로 CPU의 여러 코어를 최대한 이용하고 싶은 경우에는 GIL가 굉장히 아쉬운 이슈지만, CPU를 별로 쓰지않거나 I/O가 주가 되는 작업은 유의미한 성능 차이가 없다. 게다가 어설프게 코어 몇개 깔짝깔짝 이용해서 계산하는 것보다는 그냥 C언어로 모듈을 짜서 붙이는게 더 빠르다. 즉, python에서 CPU를 많이 먹는 부분은 C 모듈을 짜서 붙이거나 이미 C모듈로 짜여있는 라이브러리를 사용하거나(Numpy, Scipy 등) 필요하다면 multiprocessing 모듈을 이용하여 멀티코어를 활용하는 편. 그 이상의 CPU-heavy한 작업은 동적 인터프리팅 언어 쓰지 말고 처음부터 C, C++로 짜는게 맞다

자세히 알고싶다면 다음 링크들을 참조.

하지만 대규모 연산의 멀티코어의 성능 향상을 보기 위한 것 말고도, I/O가 주가 되는 작업(즉, 여러 개의 I/O 이벤트를 기다리는 것)을 위해서 멀티스레드를 사용하는 경우가 많고[28], 이런 경우에도 복잡한 동기화를 해야 하는 멀티쓰레딩을 사용하는 건 낭비이다. 왜냐하면 디버깅도 힘들뿐만 아니라, 실제로는 I/O를 위해 기다리는 시간이 실제 I/O가 발생했을 때 필요한 처리 작업을 수행하는 시간보다 월등히 긴 경우가 많아 여러 개의 스레드를 관리하기 위한 자원만 낭비하는 꼴이기 때문이다.

따라서 Go나 Erlang 같은 최근의 프로그래밍 언어들은 코루틴이란 개념을 도입해[29] 이러한 "event multiplexing"을 싱글스레드로도 구현할 수 있게 하고 있다. 특히 멀티쓰레딩할 때 필요한 각종 동기화 문제 없이 마치 싱글 스레드 코드를 짜는 것과 거의 동일한 방식으로 코드를 작성할 수 있으면서도 그러한 코드들이 "동시에" 동작하는 것처럼 실행해주므로 프로그래머 입장에서 매우 편하다. 실제로는 각 이벤트에 필요한 처리를 하고 다음 이벤트가 발생하기 전까지 비는 시간에 다른 이벤트를 처리하는 코드를 실행시켜주는 방식으로, 시분할과 비슷하지만 문맥 전환이 프로그래머가 작성한 코드에서 명시적으로 다음 이벤트를 기다려야할 필요가 있을 때 협력적으로 발생한다는 차이점이 있다. C나 C++ 같은 언어에서 이러한 코루틴 지원이 잘 안 되는 이유는, 언어적 차원에서 함수 중간에 실행을 멈추고 다른 함수를 실행할 수 있게 해줘야 하는데 스레드 별로 stack이 1개밖에 없는 구조에서는 구현이 어렵고 하나의 함수로 짜야 할 내용을 여러 개의 callback 함수로 쪼개면 코드가 지저분해진다는 단점이 크기 때문이다. [30] 위에서 기술한 Stackless Python에서 코루틴을 먼저 지원할 수 있었던 것도 이런 배경이 있다.

다행히 Python은 (stackless가 아니더라도) yield 키워드를 통해 함수 실행 흐름을 제어할 수 있기 때문에, 드디어 Python 3.4 버전부터는 표준라이브러리의 각종 파일 입출력, subprocess, socket 통신 등의 기능들을 모두 코루틴화해주는 asyncio 패키지가 기본 탑재되었다. Python 3.5 버전에는 C#에서와 동일한 의미를 가지는 async 함수 선언자와 await 키워드가 포함되어 asyncio 라이브러리에 의존할 수밖에 없던 코루틴 기능을 다른 써드 파티 라이브러리도 보다 쉽게 지원할 수 있도록 바뀌고 코루틴 내부에서의 예외처리 과정이 개선되었다.

4.2 취약점

일단 미리 명시하자면, 파이선 3버전부터는 아래와 같은 문제는 없다.

파이썬 2.7버전 이하에서 사용자의 입력을 string형으로 받는 input()함수가 존재한다. C언어 등을 접해온 초보자들은 scanf류 함수겠거니 하고 사용하게 된다. int든 str든 bool이든 뭐든 잘 받아서 꽤나 편하기 때문에 치명적인 실수를 하나 저지르는데...

신뢰할 수 없는 소스의 입력을 이 함수로 보내면 큰일난다. input()함수는 엄청나게 큰 권한을 갖고 있다. 현재 모듈에 로드된 모든 name에 대해서 접근할수 있고 그것이 함수라면 실행할 수 있다는 것. 만약에 sys 모듈이 메인에 로드되어 있고 os.system[31]을 이용한다면 다음과 같은 짓을 할 수 있다. '>>>'가 붙은 라인은 유저가 키보드로 입력한 라인이고 그렇지 않은 라인은 코드라고 하자. 그러면,


<syntaxhighlight lang="python" line="1">
input()

sys.modules['os'].system("rm -rf")

</syntaxhighlight>
일부러 /를 뒤에 안붙였다. 그래도 착한 위키러는 실행하지 마라!

위와 같이 실행자가 원하는 코드를 실행할 수 있다. 물론 혼자서 사용할 스크립트라면 상관없다. 왜냐면 털어봤자 내 계정을 터는게 되어버리니까. 그러나 이 스크립트가 다른 유저가 실행할때 내 권한을 취득하도록 설정되었다면(=setuid bit가 설정되었다면) 어떨까? 사용자는 비밀번호 없이 스크립트를 실행하는 것만으로 어렵지 않게 내 계정의 권한을 획득하게 된다! 마찬가지로 netcat등으로 외부 네트워크에서 들어온 입력을 input()이 포함된 파이썬 스크립트에 흘려보내면 비슷하게 위험한 상황이 발생할 수 있다.

그래도 .py 파일에 sys를 로드하지 않으면 괜찮지 않을까?

<syntaxhighlight lang="python" line="1">
del sys
input()

import('os').system("rm -rf")

</syntaxhighlight>
물론 소용 없다. 파이썬은 모듈을 동적으로 로드하는 __import__를 빌트인 함수로 지원하기 때문이다.

그렇다면 input()을 받아올때만 __import__ 같은 수단을 모두 막아버리면 되지 않을까? __builtins__를 초기화시켜서 __import__를 비롯한 빌트인 함수를 없애보자. 그러면 str, bool, int같은 기본형 밖에 못 받도록 제약을 걸 수 있을 것처럼 보인다. 하지만..

<syntaxhighlight lang="python" line="1">
builtins = {} # 모든 기본 함수들을 없애버린다.
input()

[x for x in ().class.base.subclasses() if x.name == 'catch_warnings'][0]()._module.builtins["import"]("os").system("rm -rf")

</syntaxhighlight>
[32]
위와 같은 변태적인 방식으로 () (빈 튜플)의 속성을 따라가면서 빌트인 함수를 복원한다. 이후 복원한 빌트인 함수에서 __import__함수를 가져와서 똑같은 일을 할 수 있다. 이것은 공격 벡터중의 하나일 뿐 저런 방식을 어떻게 막는다고 해도 잠재적인 수많은 공격 벡터에 대해서 일일히 대응할 수는 없다. 스트링으로부터 코드를 받아서 실행하는 프로그램은 어떤 식으로 막으려 해도 결국 뚫릴 수밖에 없다. [33]

그래도 로컬 컴퓨터에서 터미널 입력에만 거의 사용되는 input() 함수는 낫지만, 초보자들이 파싱할 때 eval, exec을 쓰는 경우 매우 위험하다. 저 함수들은 인자로 받은 string을 코드로써 실행하는데, 이 경우 네트워크에서 얻어온 string을 집어넣도록 짜여있는 경우가 꽤 있기 때문이다. 위에서 설명한 테크닉을 이용하여 공격 스트링을 만든 뒤 네트워크 소켓을 통해서 흘려보낸뒤 프로그램 eval의 인자로 넘기면 컴퓨터의 제어권을 뺏는 것은 시간 문제가 된다.

가장 좋은 방법은 신뢰할 수 없는 입력을 받거나 가공할 때는 input, eval, exec을 이용하지 않는 것이다. 따라서 단순히 인풋을 받을 상황에서는 왠만하면 input()을 버리고 string line을 받는 raw_input()(Python 2.x 한정)을 사용하거나 sys.stdin.readline()를 이용하도록 하자.

5 여담

구글에서 python이라고 검색하면 제일 위에 뜨는 게 위의 바다 괴물이나 뱀이 아니라 이거다.

개발 중인 게임 페리아 연대기에서는 고대언어(...)라고 한다.

Python 의 창시자 귀도 판 로썸은 구글에 입사했다가 2012년 12월 7일부로 드롭박스에 입사했다.

2013년 재미있게도 한 헤드헌터로부터 경력직 파이썬 개발자 취업제안을 받았다고 한다. 즉, 파이썬 창시자에게 파이썬 '경력직' 개발자를 구하는 수준의 메일을 보낸 것(...) 면접관: 파이썬 어느정도 하시나요? 귀도: 제가 만들었는데요.

C++ 와 Java와 함께 구글의 3대 개발 언어 중 하나로 알려져 있다.하지만 최근에 Go로 넘어가려는 움직임이 보인다 카더라.왜냐면 자기들이 만든 언어니까(...)

프갤에서 천대받는다

문명 4의 스크립트 언어로 쓰였다. Lua와 더불어 게임 스크립트 언어의 양대산맥.

가루가 되도록 까였던 심즈 4 역시 Python을 기반으로 해서 동작한다. 클라이언트를 살짝 보면 수많은 .pyo 파일들의 향연을 볼 수 있다. 심즈 4의 최적화는 나름 우수한 편. 근데 pyo가 3.5버전에서 삭제되고 pyc로 대체된다.

킹덤 언더 파이어의 엔진에도 쓰였다. 500여 개의 자체모듈이 누더기처럼 돌아갔다고 한다(…).

월드 오브 탱크는 상당부분이 파이선으로 구현되어있다. 유저가 작성하는 모드도 로직 부분은 파이선으로 구현된다.

EVE 온라인은 Python의 경량/고속 실행 버전인 Stackless Python으로 작성되었다. 개발사 CCP Games는 파이썬 재단의 정식 후원자이기도 하다. 2000년대 초에 싱글코어 CPU가 계속 쓰일 줄 알고 서버 코드를 구버전 파이썬으로 짰다가 다중 코어 사용이 힘들어지자[34], 눈물겨운 마개조를 거듭하여 파이썬이라는 언어가 제공할 수 있는 처리 능력을 한계치까지 뽑아서 쓰고 있다. 버그 잡고 최적화하는 프로그래머가 게임 내에서 유명인사가 된 것은 이 게임이 유일하겠지... 이게 다 GIL 때문

여기 번역판에서 인터프리터 설치 없이 웹 상으로 배워볼 수 있다. 단, 한글 번역판에서만 있는 오류도 있으니 주의

NumPy+SciPy+matplotlib 조합이 과학 공학 계산용으로 써볼만하다는 의견도 있다. 조금있으면 독점할 기세이다.

2014년 6월 WWDC에서 애플이 공개한 Swift라는 언어에게 220배(...) 느리다고 까였다.[35] PyPy 들고오면 40배로 줄어들긴 한다. 일부기는 하지만.

swift_benchmark.jpg

유저들은 C 바인딩인 ctypes를 출동시킨다고 부들부들... 하지만 테스트환경 세팅을 자사 제품에 유리하게 만드는건 벤치마크의 유서깊은 전통이므로 맹신은 금물. 파이썬의 강점은 속도에 있지 않다. 더구나 JIT 없는 동적 인터프리터 언어와 컴파일 언어의 성능을 비교하면 어떤 언어를 비교하더라도 당연히 후자가 압도적으로 유리하다(..) 게다가 암호화 같은 CPU heavy한 작업은 보통 다 C로 짜서 붙인다. Python 해쉬 라이브러리인 hashlib만 해도 코어가 전부 C로 되어있다.

객체 지향을 배울때 추천할만한 언어이다. 많은 대학들이 C++ 환경에서 가르치지만, 이경우 필요한 객체를 만들어서 쓰는 실습이 많은데 대부분 이미 존재하는 객체를 가져다 쓴다는 개념을 이해하지 못하는 경우가 많다. STL을 쓰면 달라지지만 실습에서 STL을 요구하는 문제가 나오는 경우도 드믈고 주로 사용되는 문자열 변환, 배열 관련 연산 등은 파이썬에서 따로 임포트할 필요없이 자료형 자체가 이미 클래스로서 편리하게 클래스 함수를 던져주기 때문에, 클래스의 재활용이라는 측면을 훨씬 이해하기 쉽다. 무엇보다 하루면 다 배울 수 있는 언어이기도 하고. 다만 대학들도 아무런 이유없이 C++을 객체 지향 입문용으로 채택한건 아니다. 많은 학생들이 프로그래밍 언어 중 C를 가장 먼저 배우기에, C++은 그나마 익숙한 개념들을 이용해서 객체 지향을 학습할 수 있게 한다. 물론 C++ 프로그래밍은 C 프로그래밍과는 패러다임 자체가 다르므로 주의가 필요하지만, 적어도 "C언어의 구조체 안에 함수를 정의할 수 있게 하면 C++이다"는 식의 낚시로 학생들에게 심리적 편안함(...)을 줄 수는 있다.

2014년 8월 30일, 유서깊은 파이썬행사인 PyCon이 드디어 한국에서도 성공리에 개최되었다. #공식홈페이지
2015년 8월 29일, PyCon 2015가 상암 누리꿈스퀘어에서 약 700명의 규모로 개최되었다. #공식홈페이지
2016년에는 PyCon APAC이 한국에서[36] 성공리에 개최되었다. #공식홈페이지

2015년 7월 9일 "같이 번역해서 같이 봅시다"라는 표어를 내걸고 파이썬 튜토리얼, 표준 라이브러리 한글 번역 깃허브 레포지토리가 생겼다. 링크가 사라졌다!! 아시는 분 제발 추가바람

6 Django

Python기반 웹 프레임워크 중에 가장 널리 퍼져있다. 일반적으로 파이썬을 웹 서비스에 쓴다고 하면 Django 또는 Flask 를 쓴다고 생각 하면 된다.

국내에서 Django로 서비스 되는 회사들은 추가바람
스포카 : 도도포인트라는 서비스를 운영한다.
8퍼센트 : P2P 대출 사이트. 프런트엔드를 IUEditor로 개발하였다.
스마트스터디 : 핑크퐁 북스토어 등이 Django로 개발되었다.
피알앤디컴퍼니  : 내차팔기앱 헤이딜러를 운영하고 있다.
알파카코믹스 : 만화 서비스.
위시켓 : IT 아웃소싱 중개 서비스.

7 관련 팁

  • 문자열을 합칠 때 join을 쓰자. range 함수와 str 함수를 같이 쓰면 매우 편해지는 경우가 있다.

<syntaxhighlight lang="python" line="1">
.join(str(x) for x in range(10))
</syntaxhighlight>

  • 괄호 안에 for 과 if, else 를 넣을 시 주의하자.

<syntaxhighlight lang="python" line="1">
list(x for x in range(10) if x%2 == 0)
</syntaxhighlight>
은 되지만

<syntaxhighlight lang="python" line="1">
list(x for x in range(10) if x%2 == 0 else 0)
</syntaxhighlight>
는 되지 않으며

<syntaxhighlight lang="python" line="1">
list(x if x%2 == 0 else 0 for x in range(10))
</syntaxhighlight>
는 된다. if만 넣을 경우 for 뒤에 써야 하며, 조건이 충족되지 않으면 생략된다. if와 else 모두를 넣는다면 for 앞에 넣어야 하며 조건을 충족하면 맨 앞, 아니라면 else 다음이 반환된다.

  • 마지막으로 호출된 값(대입이 이루어지지 않은 경우)은 _ 변수에 저장된다. 또한 이 변수에 대입한 값은 버려진다.
  • 멀티프로세싱은 _\_main_\_ 블럭 안에 들어가야 한다. 네임스페이스 문제 때문. 들어가지 않으면 오류를 뿜는다.

<syntaxhighlight lang="python" line="1">

  1. if 대신 while도 가능.

if name == 'main':
</syntaxhighlight>

  • 파이썬2와 3에서의 range는 리턴 형식이 다르다. 2에서는 리스트를 리턴하지만 3에서는 range 객체를 리턴한다. 따라서 3에서 range를 리스트로 바꾸려면 아래와 같은 방법들로 전환해야 한다.

<syntaxhighlight lang="python" line="1">
list(range(10)) </syntaxhighlight>

8 파이썬의 철학(The Zen of Python)

앞서 설명했던 파이선의 철학이 담긴 문장으로 이스터 에그형태로 파이썬에 포함되어 있다.[37] 원문 링크

Beautiful is better than ugly.

Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!


— The Zen of Python

  1. ↑ 이 예제는 2, 3 모두에서 작동한다.
  2. ↑ Python의 엄청나게 빠른 개발 속도와 생산성을 두고 개발자들 사이에서 유행처럼 퍼진 말이다.
  3. ↑ 네덜란드어 발음으로 '히도 판 로쉼'.
  4. ↑ 2014년 6월
  5. ↑ 파이썬 2.x버전에 호환성을 맞추고 있고, dropbox에서 쓰고 있는 django에 초점을 맞추고 개발 중 이다. 현재는 CPython에서는 되는데 pyston에서는 안되는 걸 찾는데 집중 중 이다.
  6. ↑ 메이저(major) 업데이트는 2.7이 마지막이며, 2020년까지 bugfix정도만 이루어진 후 지원을 종료할 예정이다.
  7. ↑ C 시간에 스택 영역 힙 영역 할 때 나오는 그 스택이다.
  8. ↑ C 레벨에서 만들어주는 스택이라 "C로 짜여진 프로그램"인 CPython은 손을 댈 수가 없다. 원칙적으로는 말이지
  9. ↑ CPython은 GPL 호환의 독자 라이센스를 가진 오픈소스 프로젝트다.
  10. ↑ 메모리의 용량이 유한한 이상 스택 오버플로우 에러가 안 날 수는 없다.
  11. ↑ OS가 직접 관리하는 쓰레드가 아닌, 유저 프로세스 차원에서 직접 돌리는 쓰레드. 그린 쓰레드(green thread)라고도 하는데 Ruby 1.8까지 지원하는 쓰레드가 바로 이것이다.
  12. ↑ PyPy 리드 개발자
  13. ↑ 정확히 말하면 이들 동적언어를 CLR위에서 구현하기위한 DLR 이라는 프레임워크 기반이다.
  14. ↑ 버전이 올라가면서 Python 자체도 그리 느리지 않게 되었다.
  15. ↑ import antigravity
  16. ↑ return 대신 yield를 써서 생성기(generator)를 반환한 경우
  17. ↑ 후자의 중요성은 남이 작성한 코드를 내가 읽고 이해해야하는 경우 아주 절실히 느낄 수 있다.
  18. ↑ The Zen of Python의 첫 세 항목이다. The Zen of Python에는 총 20가지 항목이 존재한다.
  19. ↑ 실제로 c계열의 언어에서 중괄호의 위치에 대한 논쟁은 거의 종교적 논쟁에 가깝다. 현재 한국에서 가장 많이 쓰이는 방식은 C언어의 창시자 Kernighan과 Ritchie의 K&R 스타일이다. 그러나 Eric Allman의 방식을 고수하는 사람들도 제법 많다. 이외에도 중괄호 위치를 정하는 다른 방법들이 있으며 자세한 내용은 [3]에서 확인가능
  20. ↑ 특히 C 코드를 종이에 출력해보면 중괄호 있고 없고의 가독성 차이가 의외로 크다. 파이썬에서는 이 중괄호를 탭 들여쓰기로 대체한다.
  21. ↑ 여기에 다른 언어는 비교가 안될 정도로 방대하다고 적혀 있었지만, 사실 이런 식의 방대한 라이브러리 구축은 Tex의 CTAN 은 1992년 부터, Perl의 CPAN은 1993년 부터 구축되어 있었다. 본격적인 인터넷 보급과 함께 이러한 패키지 운용 시스템은 Linux는 물론 여러 오픈소스쪽에 적용된 것을 볼 수 있다. 과거에 파이썬처럼 매우 널리 쓰였던, 그리고 지금은 파이썬이 몰아내고 있는 Perl의 CPAN은 2015년 1월 기준 약 143,000 개의 패키지를 제공한다. 당장 Java에서 널리 쓰이는 Maven의 중앙 저장소만 해도 2015년 1월 기준으로 약 95,000 여개의 패키지를 가지고 있고, Scala나 Clojure 같은 비교적 역사가 짧은 JVM 기반 언어는 고유의 언어로 작성된 패키지가 들어있는 자체 저장소와 함께 Maven 중앙 저장소에 있는 Java로 작성된 모든 JAR를 같이 끌어다 쓸 수 있게 되어있다. Emacs도 버젼 24부터 패키지 저장소와 함께 Emacs LISP으로 작성된 패키지를 손쉽게 운용가능한 시스템이 포함되었으며, Common LISP에도 quicklisp와 asdf라는 유사한 패키지 운용 시스템이 존재한다. 심지어는 누가 쓸까 싶은 Haskell 같은 언어도 cabal이라는 프로그램과 함께 Hackage라는 자체 패키지 저장소 시스템을 운용한다. 그런데 파이썬의 PyPi 는 역시 2015년 1월 기준으로 약 54,000 개의 패키지를 제공한다. 단, Python에 광범위하고 실용적이면서 실제 프로덕션 레벨에서 쓸만한 패키지가 많은 것은 맞다. 그런데 자바나 Perl에도 그런거 많이 있지 않나? 라고 하면 그것도 맞다. 이러한 경향은 사용하는 사람들이 늘어나다 보니 전체 패키지 갯수가 늘고 실용적인 패키지의 비율이 올라가는 것일 뿐, 요즘같은 프로그래밍 언어, 프레임웍의 춘추전국 시대에서는 수 년 내에 완전히 뒤집히지 말라는 법 또한 없다.
  22. ↑ Pypy로 속도 향상을 꾀하고 있긴 하다.
  23. ↑ Python으로 parser를 많이 작성해봤다면, 십중팔구 읽은 숫자를 string으로 저장했다가 나중에 연산을 했더니 연산이 불가능하다면서 에러가 나거나 이상한 결과가 나온 경험이 있을 것이다.
  24. ↑ 그러나 MATLAB의 다양한 상용 툴박스에 비하면 아직 미비한 부분이 있다. 대표적인 예가 Simulink이다. 현재 Python이 MATLAB에서 당분간 절대 대체하기 불가능할 것으로 보이는 기능은 Simulink라는 MATLAB의 강력한 GUI기반 모델링 툴박스로 현존하는 상용/공개 소프트웨어 중 FMI(Functional Mock-up Interface)의 수단으로서도 가장 강력한 툴이다. MATLAB은 이를 이용한 직관적인 시스템 모델링 및 제어기, 추정기 로직 설계가 가능하다. 그리고 이를 C로 포팅하여 임베딩을 위한 제어코드를 만들 수 있고 각종 제어기 프로토타이핑 컨트롤러에 올리는 것이 가능하다. 제어기 로직의 설계와 실험, 검증에 있어서 fast prototyping이 필요한 경우라면 Simulink의 강력함을 대체할만한 opensource software가 없는 것이 현재의 상황이다. 따라서 시스템과 제어기 내부의 로직을 모델링, 연구하고 빠르게 시험하는 분야는 아직 Python이 대체하기 어려운 부분이라고 할 수 있다. 덕분에 제어분야의 엔지니어들은 파이썬이 언젠가 상용 공학프로그램을 상당수 대체할거라는 소리를 믿지 않는다 "Python그래서 Simulink를 어떻게 대체한다는거죠?". 현재 오픈소스 프로그램 중 GUI기반 모델링 및 Functional Mock-up Interface를 지원하는 프로그램은 OpenModelica등의 몇몇 프로그램이 있고 Simulink 수준의 강력한 프로그램은 없으며 당분간 대체가 불가능할 것으로 보인다. Simulink 툴박스는 기업용으로 구매하면 기본 toolbox가 1 copy에 천만원 단위, 각종 전기, 전자, 기계, 유압, 항공 등에 관련한 라이브러리는 추가로 유료로 판매한다. 거기에 c로 포팅해주는 모듈도 역시 개별적으로 추가 구매해야 한다. 만약 오픈소스 소프트웨어로 Simulink를 대체하고자 한다면 현재로서는 FMI기능 및 C코드로의 오토코딩 모듈이 있어야 할것이다. 따라서 오픈소스로 일을 하기 싫으면 simulink로 실제 제어기를 개발하는 일을 해보자. 물론 재수없으면 회사에서 MATLAB과 Simulink만 사주고 C 자동 코드 생성 툴을 안사줘서 Simulink로 프로토타이핑 하고 오토코딩이 아니라 제어용 C코드를 직접 짠다고 머리 터질 수도 있다.
  25. ↑ 16학번부터 적용. 그전까지는 첫 프로그래밍 언어로 C를 배웠다.
  26. ↑ 원래 언어 쪽에서 Multilingual 과 같은 뜻으로 쓰였으나, 컴퓨터, IT 업계에서는 여러 프로그래밍 언어를 능숙하게 구사하여 적재 적소에 잘 조합하여 쓸 수 있는 능력을 뜻한다.
  27. ↑ 물론, 내부적으로 IO작업이 있을시 바로 다른 스레드로 문맥 교환을 해주고, 바이트 코트를 100번 실행한 다음에는 인터프리터 차원에서 다른 스레드로 교체 해주므로 동시 작업 비슷한 효과가 난다.
  28. ↑ 사실 GIL 방식으로 만들 당시 싱글코어가 일반적이었다는 걸 생각해보면 싱글코어에서의 멀티쓰레딩 목적 자체가 멀티코어 성능 향상보다는 이런 다중 이벤트 루프 구현을 하기 위한 것이라고 봐야 하며, 그런 관점에서는 GIL이 합리적인 선택이었다고 할 수 있다.
  29. ↑ 단 코루틴이라는 개념 자체가 이런 최근의 프로그래밍 언어에서 처음으로 등장한 것은 아니다. 코루틴의 개념은 1950년대에 이미 나왔다.
  30. ↑ 이런 callback형태를 사용하는게 node.js 개발 환경이다. 현재로써는 이런 콜백 방식이 유연하면서 퍼포먼스가 좋은 방식이지만 언어적으로 약간 더럽다(..)
  31. ↑ 해당 스트링을 쉘에서 실행시키는 함수
  32. ↑ 참고로 이 방법은 3.X에서 되지 않는다. 왜냐하면 3에서는 []가 반복가능한 객체를 리스트로 바꾸는 기능이 아니며 그대로 반복가능한 객체가 든 리스트를 반환한다. 따라서 반복가능한 객체를 리스트로 변환하도록 list(x for x in ().__class__.__base__.__subclasses__() if x.__name__ == 'catch_warnings')를 써야 하는데, 빌트인 함수를 삭제해 list 함수가 실행되지 않는다. 따라서 (x for x in ().__class__.__base__.__subclasses__() if x.__name__ == 'catch_warnings').__next__()._module.__builtins__["__import__"]("os").system("rm -rf")와 같은 방법으로 해야 한다. 물론 그래봤자 3에서는 문자열로 받아 실행되지는 않고 하고싶다면 따로 실행해야 한다.
  33. ↑ 정말로 네트워크의 스트링으로부터 eval을 해야할 경우 OS 커널 단에서 설계된 sandbox환경을 이용하도록 해야 한다.
  34. ↑ 전장에서 일어나는 일을 제외한 나머지 시시콜콜한 일을 다른 코어로 돌리기는 하였으나, 게임의 최소 단위인 전장은 구조상의 한계로 하나의 코어만 동원할 수 있다.
  35. ↑ 하지만, 드롭박스 사에서 개발하고 있는 파이썬을 프론트엔드로 하고, LLVM을 백엔드로 사용하는 Pyston이 릴리즈되면 별차이 없어질 거란 전망도 나왔다.
  36. ↑ 강남 코엑스에서 13~14일 아카마이에서 15일(튜토리얼)
  37. ↑ 콘솔에서 "import this" 입력.