1

파이썬 문법책을 그만 볼 때가 된 개발자들에게 권한다. print(‘hello world’)부터 시작하는 초입자가 아니라면, 대부분의 개발자가 파이썬에 대한 정보를 얻을 수 있는 몇권 안되는 국내 서적이라 할 수 있다.

정말 과장을 조금 더 보태자면, ‘점프 투 파이썬’을 다 봤고, 본인이 참을성만 있다면 이 책을 읽는게 좋다. 파이썬은 생각보다 암묵적인 규칙이 많다. 이 규칙에 익숙하면 GitHub의 코드가 자신을 위한 좋은 정보가 될지 모르지만, 규칙에 대한 이해가 없다면 GitHub은 거대한 hdd 이상의 가치가 없기 때문이다.

만약 파이썬 문법을 완주 했다면 “사라, 이 책을!”

---

도움이 굉장히 많이 된 챕터

1.2, 1.4, 2, 3, 6, 7, 8.3, 11, 14

난 어디에 속하는 걸까? C/C++이 적은 초보자를 만드는 것은 포인터에서 포기시키기 때문이지 않을까?(흐흣..)

글 쓰는 것만 쓰게 되고 더는 갈고 닦아야 할 필요가 느껴지지 않는다고 할까? 그 때문에 C, C++ 같은 언어는 적은 초보자와 많은 고급자를 양산해 내는 반면 루비, 파이썬 같은 스크립트 언어들은 많은 초보자와 적은 고급자를 만들어 내곤 한다.

‘많이 어렵다’

이 책은 약간 어렵다. 아마도 처음 읽기를 시도했을 때는, 까만 것은 글씨고, 하얀 것은 종이로구나 하는 사람들도 있을 것이다(특히나 책에 중간 중간 나오는 파이썬 개발자 인터뷰 내용이 그럴 것이다). 그냥 지나쳐서 읽으라. 아, 뭔가 이런게 있구나 하고, 망막을 스치며 보이는 부분만 읽어도 된다.

2017년이 되면 ‘구글 앱 엔진’도 py3를 지원할까?

2.7은 2016년까지 계속 지원될 것이다.

아니야~ 가자 py3!! “너, py3로 업그레이드 해라!”

지금 코드가 2.7을 지원하고 있다면 굳이 이 버전들을 지원할 필요는 없다.

좋은 ‘삽화’다.

표준 패키지 디렉토리 구조(p3)

항상 생각하면서 잊게 된다. “잊어야 한다는 마음으로” 살아서 그런가 보다.

언제나 타입이 아닌 기능에 따라 코드를 분류하자.

PEP-440을 읽어보자!

PEP 440은 모든 파이썬 패키지와 애플리케이션이 따라야 하는 버전 포맷을 명시하고 있다.

버전에 ‘간지’를 입혀보자!

더 복잡한 버전 번호를 원하다면 PEP 426이 정의한 소스 라벨에 주석을 남길 수 있다.

과연 그럴까?!

[…] 그래서 pep8을 쓰면 이 검사를 자동으로 할 수 있다.

pep8 이라도 잘 쓰자!

새 프로젝트를 시작한다면 이러한 도구 중 하나를 사용해 코드 품질과 스타일을 자동으로 검사하길 권한다. 이미 작성된 코드가 있다면 많은 경고 옵션을 끄고 한 번에 경고 카테고리 하나씩 문제를 해결하는 것도 좋은 방법이다. 이러한 도구들이 각자의 프로젝트나 설정에 완벽하게 들어맞진 않겠지만 flake8이나 hacking을 함께 쓰면 코드의 품질과 안정성을 높이는 데 도움이 될 것이다. 적어도 이 목표를 달성하기 위한 좋은 출발이다.

export 할 때 조심하자!

모듈을 찾을 때 sys.path 리스트에 대한 루프를 돌기 때문에 리스트 내 경로의 순서가 중요할 수도 있다.

훗…

모든 라이브러리르 최소한 한 번은 대충이라도 훑어보는 것이 좋다.

접수!

collections, json, multiprocessing, operator, os, uuid

py3는 소중하다!

그럼에도 불구하고 오픈스택에서 우리가 할 수 있는 최선의 판단을 내리기 위해 다음 체크리스트를 사용한다. 1) 파이썬 3 호환, 2) 활발한 개발 3) 활발한 유지 보수 4) 운영 체제에 포함여부 5) API 호환 여부

Lib v.s. Framework

이와 반대로 라이브러리는 우리 코드가 더 추가적인 작업을 하기 위해 사용하는 ‘추가 기능’이라고 볼 수 있다. […] 반대로 우리 코드의 뼈대를 구성하여 우리가 하는 작업은 그 뼈대 위에 특정 기능을 올리는 것이다. […] 이득도 많지만 프레임워크에 종속되는 것 같은 무시할 수 없는 단점도 있다. // 프레임워크를 바꾸는 것은 엄청나게 힘든 일이다. 파이썬이 아무 많은 기능을 제공하지만 이것에 대해 도와줄수 있는 건 없다.

bisect에 대해서 알게 되었다!

표준 라이브러리에서 더 많이 사용했으면 하는 모듈 세 개 : abc, bisect, collections

안될놈은 안되는 거다.

이 시점에 파이썬 3를 지원하지 않는 라이브러리르들은 거의 ‘유지 보수 안 됨’으로 분류될 수 있다.

역시 만들고 변경하지 않기 위해선 설계를 열심히 해야 한다. 그래서 출시가 안되는 제품이 얼마나 많은지 사람들은 모르고 있을꺼야…

API를 변경할 때 변경에 대한 문서화를 확실하게 하는 것이다. 다음 정보를 꼭 포함해야 한다. 1) 인터페이스 문서화 2) 중단되는 인터페이스 문서화 3) 어떻게 이주할지에 대한 문서화

아아… 나를 알고 있었던가?

파이썬 API를 설계할 때 개발자들이 하는 실수는 무엇인가? ‘단위 테스트를 만들지 않는 것’

음? 스핑크스 아니였어?!

파이썬에서 사용하는 사실상의 표준 문서화 포맷은 reStructuredText다.

둘 다 배워둬야 한다는…

setuptols는 현재의 배포 라이브러리이지만 미래엔 distlib이 사용될 수도 있으니 주목하자

venv는 pip가 설치 안되니 ‘주의’

지금은 virtualenv를 게속 사용하는 것이 최선이다. 두 모듈 모두 같은 기능을 수행한다는 점에서 그리 문제 될것은 없다.

‘TDD’가 중요하다는데 어떻게 생각하시나요?라고 조엘 블로그에 댓글은 달지 말자.

테스트되지 않는 코드를 만드는 것은 동작 여부를 증명할 수 없으므로 본질적으로 무익하다고 볼 수 있다.

용어 습득

단위 테스트에서 픽스처는 테스트 전에 구축되고 테스트 후에 지워져야 하는 데이터를 뜻한다.

다중 상속… 피해야 하는게 아닐까?

[…] 자연스러운 방법은 믹신 클래스를 사용하는 것이다. 부모 클래스 하나는 단위 테스틀를 가지는 클래스이고, 다른 하나는 특정한 드라이버를 설정한 클래스이다.더 나은 방법은 testsoenarios 패키지를 사용하는 것이다.

지당한 말씀을…

파이썬 코드를 짤 때 […] 품질을 높기이 위한 최선의 전략은 무엇인가? “기능 나누기다”

오~~

하지만 아마 super()가 사실 생성자이고 호출할 때마다 super 객체를 인스턴스화하고 있음은 몰랐을 것이다.

그렇다고 리스프를 배워보란 말씀을 하시다니요… 배워보지요..

하지만 파이썬은 함수형 프로그래밍을 꽤 상세하게 지원한다. 많은 파이썬 개발자들이 이에 대해 잘 모르는 것은 부끄러운 일이다.

결과를 캐싱한다는게 매력이지만 뭔가 궁금함이 많아졌다.

메모이제이션은 결과를 캐싱하여 함수 호출 속도를 높여주는 기법이다.

나도 py3 라이브러리에 대해서 굉장히 모르는구나!

“파이썬 3.3은 벤치마크를 위해 경과된 시간을 측정하는 time.perf_count()함수를 새로 내놓았다. 최선의 방법이다.”

이벤트 프로그래밍은 사랑이다.

1. 백그라운드 작업들을 돌려야 한다면 가장 쉬운 방법은 이벤트 루프를 사용하는 애플리케이션을 마드는 것이다. 2. 워크로드를 분산하고 싶다면 다수의 프로세스를 쓰는 것이 더 쉽고 효율적이다.

다음달에 집중적으로 볼 생각으로 책을 수집하고 있는데 한권(?!) 있음.. 흣..

트위스트디는 이 영역에서 몇 년 동안 거의 표준적인 역할을 했다.

mariadb만 사용하기로 마음 먹었다.

ORM이 필요해지는 다른 문제는 여러 데이터베이스를 지원할 때다.

쉽게 될지는 하늘만이 알것이다.

contextlib 표준 라이브러리의 contextmanager는 enter__와 __exit 메서드를 생성해주는 제네레이터를 통해 이 기법을 쉽게 구현할 수 있게 해준다.