이 책을 읽는 많은 분은 전체 소프트웨어 개발 기술을 배울 필요가 없으며, 일부는 파이썬을 단편적으로 습득할 수 있다. 하지만 이와 동시에 여러분이 마주하게 될 코드에서 언어의 어떤 부분이라도 사용될 수 있기 때문에 대부분의 프로그래머에게는 어떤 부분도 전적으로 선택 사항이 될 수 없다. 더군다나 심지어 비정기적인 스크립트 개발자나 취미로 개발하는 사람이라도 코딩을 잘하고, 이미 코딩된 도구들을 적절하게 활용하기 위해서는 기본적인 소프트웨어 개발 원칙을 알아야 할 필요가 있다. --- p.xxix

그러나 실제로 이러한 오픈 소스의 장단점은 기존에 이미 안정화된 버전들보다는 최첨단 기능을 포함한 최신 릴리즈에 더 많은 영향을 준다. 예를 들어 여러분이 파이썬 2.X에서 여전히 고전 클래스를 사용하고 있다면, 2000년대 초중반에 나타난 클래스 기능의 급증과 새로운 스타일의 클래스로의 변화에 거의 영향을 받지 않는다. 비록 이것들이 3.X에서는 다양한 기능과 함께 필수적인 요소가 되었지만, 오늘날 많은 2.X 사용자들은 여전히 이러한 이슈를 운 좋게 피해가고 있다. --- p.20

2장에서 설명한 프로즌 바이너리 실행 파일은 여러분이 작성한 프로그램의 바이트 코드와 파이썬 인터프리터를 단일 실행 프로그램에 결합한 패키지다. 이 접근 방법은 여러분이 일반적인 프로그램을 실행할 때와 동일한 방법으로 파이썬 프로그램을 실행하는 것을 가능하게 한다(아이콘 클릭, 명령 라인을 통한 실행 등). 이 방법은 프로그램 판매 시에 전달을 목적으로 사용하면 좋지만, 프로그램 개발 시에 사용하기 위한 것은 아니다. 여러분은 일반적으로 개발이 끝난 다음 제품을 패키징하기 전에 프로즌 바이너리를 생성하게 된다. 이 옵션에 대한 자세한 내용은 앞 장을 참고하자. --- p.104

여러분은 이 책과 이 장을 통해 배우게 되겠지만, 파이썬은 스크립트에서 사용할 객체의 특정 타입을 선언하지 않는다. 사실, 대부분의 프로그램은 특정 타입에 대해 신경 쓸 필요가 없다. 그 대신, 타입들은 다양한 상황에서 우리가 직접 타입을 지정하는 것보다 더 자연스럽게 적용된다. 동적 타이핑은 파이썬 언어의 유연함의 근원이고, 새롭게 파이썬을 배우는 사람들에게 잠재적인 장애물이기 때문에 이 장을 통해 간략히 살펴보도록 하자. --- p.223

이 방법은 종종 재귀적(recursive) 비교라고 불린다. 최상위 객체에 요청된 동일한 비교가 결과가 결정될 때까지 중첩된 각 객체에 적용되며, 그리고 해당 객체 안에 중첩된 또 다른 객체에 다시 적용된다. 나중에 19장에서 중첩된 구조와 유사하게 동작하는 재귀 함수를 작성하는 방법에 대해서 다룬다. 지금은 이러한 구조에 대한 비유가 필요하다면 두 웹 사이트에 연결된 모든 페이지를 비교하는 작업과, 이러한 작업을 처리하기 위해 재귀 함수를 작성해야 하는 이유에 대해 생각해 보자. --- p.379

여기서 단지 튜플에서 중첩된 문자열을 둘러싼 추가적인 따옴표를 의미하며, 이 따옴표는 2.X에서 괄호에 포함된 여러 아이템들을 출력하기 위해 생성되었다. 중첩된 객체의 표시는 다른 객체 타입의 경우 더 많은 차이가 날 수 있으며, 특히 연산자 오버로딩을 통해 다른 표시 방식을 정의한 클래스 객체의 경우 많은 차이가 날 수 있다. 이 주제에 대해서 일반적인 내용은 파트 6에서 다루며, 상세한 내용은 30장에서 다룬다. --- p.462

문서화는 일부 프로그래머들 사이에서 우선순위가 낮은 경향이 있다. 많은 주석은 종종 여러분 자신에게 도움이 되며, 정확하고 최신인 상태를 유지할수록 더 좋다. 또한, 코드를 자유롭게 문서화하는 것이 바람직하다. 이는 실제로 잘 작성된 프로그램의 중요한 부분이다. 그러나 실제 주석을 작성할 때, 아직 문서화 문자열의 구조에 대한 표준은 없다. 주석은 무엇이든 작성할 수 있다. 코드를 작성하는 것과 마찬가지로 문서 내용을 작성하고 최신 상태로 유지하는 것은 개발자의 몫이지만, 어디까지나 일반적인 상식선에서 작성해야 한다.

사실, 클래스는 세 가지 중요한 특징을 가진다. 기본적인 수준에서는 클래스는 파트 5에서 학습했던 모듈과 매우 유사한 단순한 네임스페이스다. 하지만 모듈과 달리 클래스는 다수의 객체를 생성할 수 있으며, 네임스페이스 상속과 연산자 오버로딩을 지원한다. class문을 통해 이 세 가지 특징에 대해 알아보도록 하자. --- p.999

클래스가 포함한 함수의 범위에 접근할 권한이 있기는 하지만, 클래스 내에 중첩된 코드에 대한 포함 범위로 동작하지는 않는다. 파이썬이 참조된 이름을 찾을 때 포함된 함수는 검색하지만, 포함된 클래스는 절대 검색하지 않는다. 즉 클래스는 지역 범위고 포함된 지역 범위에 접근할 수 있지만, 더 중첩된 코드에 대한 지역 범위로는 동작하지 않는다는 뜻이다. 메서드 함수 내에서 이름에 대한 검색이 메서드를 포함한 클래스를 건너뛰므로 클래스 속성은 반드시 상속을 통한 객체 속성으로 접근해야 한다. --- p.1100

이 장에서 클래스가 가지는 재사용성과 코드 분할의 이점을 최적화시키기 위해 클래스를 사용하고 결합하는 일반적인 방법들에 대하여 알아보았다. 재사용성과 코드 분할은 대체로 특정 프로그래밍 언어와는 독립적인 디자인 이슈로 여겨진다(하지만 파이썬은 이를 구현하기 좀 더 쉽도록 한다). 우리는 위임(객체들을 프록시 클래스에 감싸는 것), 구성 관계(내장 객체를 제어하는 것), 상속(다른 클래스들로부터 행위를 얻기)에 대하여 유사개별 속성, 다중 상속, 바운드 메서드, 팩토리 같은 비전에 가까운 개념과 함께 학습하였다. --- p.1228

파이썬 2.6과 3.0 전에는 예외를 클래스 인스턴스와 문자열 객체로 정의할 수 있었다. 문자열 기반의 예외는 2.5에서 사용 중단 경고를 하기 시작했으며, 2.6과 3.0에서는 제거되어 현재로는 이 책에서 보여 주는 대로 클래스 기반의 예외를 사용해야 한다. 하지만 옛날에 작성된 코드를 이용하여 작업해야 한다면, 여전히 문자열 예외와 마주칠 수 있다. 이는 (파이썬 역사상 이것이 영원할 것으로 여겨졌던) 수년 전에 작성된 책이나 튜토리얼 또는 웹 자료에서도 발견할 수 있을 것이다. --- p.1413

데코레이터는 일부 잠재적 문제점도 가지고 있다. 데코레이터가 래핑(wraing) 로직을 추가할 때 이는 데코레이트된 객체의 타입을 변경할 수 있으며, 호출 또는 인터페이스 프록시로 사용될 때 부가적인 호출을 야기할 수 있다. 하지만 이런 문제는 객체에 래핑 로직을 추가하는 모든 기법에서 동일하게 발생하는 것이다. --- p.1599

왜 우리는 3.X에서 클래스가 tye 클래스의 인스턴스임에 관심을 가져야 하는가? 이는 메타클래스를 코딩할 수 있게 해주기 때문이다. 오늘날에는 타입의 개념이 클래스와 동일하기 때문에 우리는 이를 변경하기 위해 일반적인 객체 지향 기법과 클래스 구문을 이용하여 tye을 서브클래싱할 수 있다. 그리고 클래스는 실제로 tye 클래스의 인스턴스이기 때문에 tye의 변경된 서브클래스로부터 클래스를 생성하는 것은 커스터마이즈된 클래스를 구현할 수 있게 해준다. 자세히 말하자면, 이 모든 것은 3.X와 2.X의 새 형식 클래스에서 모두 자연스럽게 동작한다.