Python 에 대한 사실 N 가지
앞으로 Python 에 대한 사실을 포스팅하기 전에 재미로 사실 N 가지를 소개해보려고 한다.
파이썬을 발명한 사람은?
파이썬(Python)은 1990년 암스테르담의 귀도 반 로섬(Guido van rossum)이 개발했다
인터프리터 vs 컴파일 언어?
파이썬은 인터프리터 언어이다. 인터프리터 언어란 소스 코드를 한 줄씩 해석한 후 그때그때 실행해 결과를 바로 확인할 수 있는 언어를 말한다.
파이썬 이름의 유래는?
귀도는 파이썬이라는 이름을 자신이 좋아하는 코미디 쇼인 ‘몬티 파이썬의 날아다니는 서커스(Monty python's flying circus)’에서 따왔다고 한다.
파이썬의 다른 의미는?
파이썬의 사전적 의미는 ‘고대 신화에 나오는 파르나소스 산의 동굴에 살던 큰 뱀’을 뜻하며, 아폴로 신이 델파이에서 파이썬을 퇴치했다는 이야기가 전해지고 있다. 대부분의 파이썬 책 표지와 아이콘이 뱀 모양으로 그려져 있는 이유는 바로 이 때문이다.
파이썬은 주로 어디에서 사용하는가?
파이썬은 컴퓨터 프로그래밍을 교육할 때뿐만 아니라 기업에서 실무를 할 때도 많이 사용한다. 직관적이고 쉬운 문법과 다양하고 풍부한 라이브러리들을 바탕으로 한 강력한 생태계를 가지고 있어 프로그래밍 교육, 인공지능, 데이터 분석 및 빅데이터, 백엔드, 프론트엔드, 웹 스크래핑 등 다양한 분야에서 사용된다.
소프트웨어 업계에서 파이썬의 입지는?
구글에서 파이썬의 입지는?
구글에서 만든 소프트웨어의 50% 이상이 파이썬으로 작성되었다는 이야기도 있을 정도이다. 이 밖에도 인스타그램(Instagram), 넷플릭스(Netflix), 아마존(Amazon) 등 우리가 알고 있는 많은 IT 기업에서 파이썬을 사용한다.
파이썬의 장점은?
파이썬 프로그램은 공동 작업과 유지 보수가 매우 쉽고 편리하다. 이 때문에 이미 다른 언어로 작성된 많은 프로그램이 파이썬으로 재구성되고 있다. 국내에서도 그 가치를 인정받아 사용자 층이 더욱 넓어지고 있고 파이썬을 사용해 프로그램을 개발하는 업체 또한 늘어나고 있는 추세이다.
파이썬의 습득 난이도는?
실행할 수 있는 의사 코드(Executable pseudocode)라고 불릴 정도로 문법이 단순하며 매우 미려하다. 학습 난이도 역시 초보자가 배우기 쉽기에 프로그래밍 입문용으로 많이 추천된다
파이썬 디자인 철학은?
파이썬의 디자인 철학에 맞는 코드를 짜는 것을 파이써닉(pythonic)이라고 부른다. 이는 단순히 스타일 가이드라인을 맞추는 것을 넘어, 파이썬의 파이썬에서 권장되는 다양한 클린 코드 기법을 통해 복잡하지 않고 의미가 명확하며, 명백하게 흐름이 보이는 PEP 20을 염두에 둔 코드를 작성하는 것을 말한다.
파이썬의 특이한 점
파이썬에서는 중괄호 대신 들여쓰기를 사용한다. 이 들여쓰기 문법은 시각적으로 파이썬과 다른 언어가 구분되는 특징이기도 하다. Lex Fridman과 진행된 귀도의 인터뷰에 따르면 공백은 가독성에 중요한 영향을 끼치며, 코드가 무슨 일을 하는지 알기 어렵게 되기 때문에 필수적이라고 하였다. 그렇다고 해서 가독성이 뛰어나냐!? 매우 뛰어나다!!
파이썬에서의 타입?
Python에는 원시 타입(primitive type)이 존재하지 않으며, 클래스, 함수를 비롯한 모든 것이 객체로 취급된다.
변수 선언은?
Python 은 javascript 의 `let` , `var` 와 같은 변수 선언을 별도로 하지 않는다.
Comprehension?!
Python 개발자는 매우 귀찮음이 많은 사람이었나보다. 단축 코드가 상당히 많다.
[f"{i:03d}" for i in range(100) if i % 3 == 0 or i % 2 == 0]
PEP??!?
파이썬의 모든 새로운 기능 혹은 규칙은 PEP 에서 등장한다. PEP(Python Enhancement Proposals, 파이썬 개선 제안서)란 파이썬 커뮤니티에 정보를 제공하거나, 파이썬이나 파이썬의 프로세스나 환경을 위한 새 기능을 설명하기 위한 내용을 담은 디자인 문서이다.
파이썬의 철학은?
파이썬의 디자인 철학은 PEP 20에서 잘 나타나 있다.
-
아름다운 것이 추한 것보다 낫다. (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.)
-
그 방법이 처음에는 명확해 보이지 않을 수 있다.[3]. (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!)
사실 더 도움이 되는 여러 진실들이 많다. 오늘은 처음이니까 이 정도로 마무리 지어볼까 한다.