기록

에디터 버전 : 2021.3.28f1 (LTS)

Asset Pipeline

예전 에디터 버전에서는 Asset Pipeline 은 version 1, 2를 구분하여 선택하여 사용할 수 있었지만 최근 버전에서부터는 Asset Pipeline 2로 자동설정되며 선택할 수 없다.

에셋을 처리하는 과정에 대한 설정을 관리하는 항목들이다.

Remove unused Artifacts on Restart

재실행시 사용하지 않는 아티팩트들을 삭제할지 여부에 대한 토글로 기본으로 활성화된 상태이다.

유니티는 에디터가 실행될 때 라이브러리 폴더의 artifact 파일과 에셋 데이터베이스 엔트리에서 제거한다.

가비지 콜렉션의 형태로 이 설정을 비활성화하면 에셋 데이터베이스의 가비지 컬렉션이 비활성화된다.

즉 더 이상 사용하지 않는 수정된 아티팩트가 에디터가 재실행될 때에도 계속 보존되기 때문에 예상하지 못한 임포트 결과를 디버그 할 때 유용하다.

하지만 계속해서 사용하지 않는 데이터들이 쌓여갈 수 있기 때문에 일반적인 상황에서는 활성화해두는게 나을 것 같다.

라이브러리 폴더

유니티에 임포트 된 에셋은 두 가지 버전으로 구분된다. 하나는 사용자가 사용하기 위한 것이고 다른 하나는 유니티가 사용하기 위한 것이다. 이 유니티가 사용하기 위한 에셋은 프로젝트의 라이브러리 폴더에 캐시로 생성된다. 즉 라이브러리 폴더 내의 캐시들은 로컬에서 에디터가 빠르게 작업을 처리하기 위해 사용하는 정보들로 많은 정보들을 계속해서 저장하기 때문에 용량이 큰 편이다.

로컬에서만 필요한 이 정보들은 프로젝트가 켜질 때마다 확인하는 과정을 거치며 폴더가 없으면 다시 생성하기 때문에 프로젝트를 공유하는 경우에는 제외시켜도 되는 파일들이다.

Parallel Import

에셋을 임포트 할 때 동시에 진행하도록 하는 설정이다.

해당옵션은 기본으로 비활성화되어있고 이 경우 에셋을 순차적으로 임포트 하게 된다.

이 기능은 특정 유형의 에셋에서만 지원되며  에디터가 프로젝트 폴더에서 에셋이 새로 임포트 되거나 수정된 에셋을 감지하고 자동으로 임포트 할 때 발생하는 에셋 데이터베이스가 새로고침을 수행할 때만 실행된다. 이때 에셋은 하위 프로세스에서 임포트가 실행된다.

특정유형

- Texture Importer로 가져온 이미지 파일

- Model Importer 로 가져온 모델 파일

특정 유형은 임포트 시간이 오래 걸리는 두 가지로만 구성되며 현재 버전까지는 별도의 스크립터블이 가능한 API는 마련된

지 않은 상태이다.

이외의 유형은 해당 설정이 활성화되어 있어도 순차적으로 임포트 된다.

Desired Import Worker Count

병렬 임포트에서 사용할 작업 프로세스의 최적의 수

Standby Import Worker Count

쉬고 있는 상태에서도 유지시킬 최소의 작업 프로세스의 수

에디터에서 작업에 필요한 프로세스의 수가 최소보다 큰 경우 쉬고있는 프로세스를 중지시키고 시스템 리소스를 확보하도록 한다. 

Idle Import Worker Shutdown Delay

쉬는 상태의 작업 프로세스를 종료할 때 대기하는 시간

또한 Edit > Preferences > Asset Pipeline에서 새 프로젝트에서 필요한 작업 프로세스의 기본 값을 제어할 수 있다.

Import Worker Count % 의 값을 사용하여 Desired Import Worker Count 값을 할당할 수 있다.

이때 할당되는 값은 시스템에서 사용할 수 있는 논리 코어 수의 비율에 해당한다.

(16개의 논리 코어가 있다면 이중 25%를 할당하여  Desired Import Worker Count 값은 4가 할당된다.)

Cache Server (project specific)

Asset Pipeline 1 일 때 사용한 기능으로 버전 2에서는 기본으로 비활성화되어 있고 활성화할 수 없고 Unity Accelerator로 대체되었다.

Accelerator

팀 작업 속도를 높이기 위한 기능이다.

임포트 한 에셋의 사본을 유지하는 캐싱 프락시 에이전트이다. 팀이 동일한 네트워크에서 작업할 때 프로젝트 일부를 다시 임포트 할 필요가 없도록 하여 반복 시간을 줄일 수 있도록 돕는다.

Unity Accelerator

Prefab Mode

프리팹 관련 설정

Allow Auto Save

프리팹 설정 시 자동으로 저장되는 기능을 활성화할지 여부를 정할 수 있다.

활성화된 경우 프리팹 수정 씬에서 자동 저장 기능을 사용할 수 있는 상태가 된다.

Editing Environments

프리팹을 수정하는 환경을 편집하는 기능을 제공한다.

Regular Environment

일반 프리팹을 편집하는 환경에서 사용하고자 하는 신을 할당하면 배경으로 사용할 수 있다.

UI Envrionment

UI 프리팹의 편집하는 환경에서 사용할 수 있다.

Graphics

Show Lightmap Resolution Overlay

씬의 드로우 모드 중에서 Baked Lightmap 모드에 체커보드 오버레이를 그린다. 

여기서 타일 하나는 텍셀에 해당하며 라이트매핑 작업 시 씬의 텍셀 밀도를 확인할 수 있다.

Use legacy Light Probe sample counts

활성화 시 Progressive Lightmapper를 사용하여 베이크 할 때 고정된 라이트 프로브 샘플 수를 사용한다. 

Direct Sample 64, Indirect Sample 2048, Environment Sample 2048

Enable baked cookies support

2020.1 이상의 프로젝트는 기본적으로 베이크 된 쿠키가 Progressive Lightmapper의 베이크된 광원과 혼합 광원에 대해 활성화된다. 이전의 경우 해당 부분이 비활성화되는데 이 옵션은 이전 버전과의 호환성을 위해서 제공되는 기능이다.

Cookie

특정 모양이나 색상의 그림자를 만들기 위해 광원에 배치하는 마스크로 광원의 모양과 강도를 변경한다.

쿠키를 통해 런타임 성능에 최소한 또는 전혀 영향을 미치지 않는 선에서 복잡한 조명 효과를 효율적으로 사용할 수 있다.

바이너리와 텍스트(YAML) 비교

비주얼 스튜디오에서 바이너리를 볼 수 있는 확장 툴을 설치해서 해당 파일을 분석해 본다.

프로젝트 설정 중에서 에셋 데이터를 관리하는 방식인 바이너리와 텍스트 두 가지에 대해서 몇 가지 테스트를 해볼 것이다.

두 방식을 비교해 보기 위해서 프로젝트에서 모든 컴포넌트의 데이터가 동일한 오브젝트를 생성해 보고 차이점을 비교한다. 

하이어라키에서 큐브를 생성하고 프리팹으로 만들어 파일을 확인해 본다.

파일의 크기는 3kb이며 파일 내용은 YAML 형식으로 오브젝트의 모든 컴포넌트의 정보가 저장되어 있다.

길이는 100줄 정도 된다.

데이터 내용을 그대로 보아도 어떤 정보를 담고 있는지 파악하기 쉽다.

그대로 프로젝트 세팅에서 Asset Seriailization 모드를 Force Binary로 변경한다.

용량이 더 줄어들었을 거라고 예상했지만 반대로 증가했다.

파일의 마지막은 다음과 같이 정보를 보여준다.

좌측의 메모리주소와 우측의 아스키코드에 대응하는 문자는 편집기의 기능으로 데이터에 포함되지 않는 정보일 것이다.

맨 앞의 8자리 숫자+알파벳의 조합은 16진수로 보인다.

이 주소가 16 단위로 증가하고 뒤에 오는 정보는 8 + 8 총 16으로 정보의 개수를 의미하는 것 같다.

메모리 주소 뒤에 오는 행렬 형태의 정보는 아스키코드로 보이는데 아스키 테이블에서 20은 공백, 3C는 < 로 확인할 수 있다. 따라서 맨 우측에는 테이블에 대응하는 문자를 확인된다.

마지막 주소가 2030으로 10진법으로 변환 시 8240이다. 즉 총 8240개의 데이터가 담겨있으며 파일의 크기가 9kb인 것으로 생각해 볼 때 하나에 1byte로 떨어지고 각 데이터가 아스키코드이므로 1byte라고 생각하면 얼추 맞아떨어지는 거 같다.

파일크기는 9kb로 나오는데 해당 파일을 속성을 열어서 자세히 보면

더 근접한 크기임을 알 수 있다. 

좀 더 정밀하게 계산하면 마지막 줄에는 데이터 4개가 빠져있어서 8236이다. 즉 최종적으로 16byte가 모자라다.

만약 마지막 메모리가 온전히 16을 차지한다고 해도 8240이 최대일 텐데 그래도 12byte가 채워지지 않는다.

어디서 계산이 잘못된 건지 이 부분은 다시 확인해 볼 필요가 있다.

다시 본래의 목적으로 돌아가서 YAML 형식이 바이너리보다 용량이 적은 것은 의문이 들어서 프리팹의 크기를 키워보기로 한다. 기존의 큐브 프리팹에 자식으로 큐브를 추가해서 수정해 결과를 확인해 본다.

바이너리의 경우 768 byte 가 추가되었다.

모드를 변경해서 Text의 크기를 확인해 보니 6kb로 처음 경우에서 2배로 사이즈가 커졌다. 증가량만 따졌을 때는 엄청난 크기 차이가 있다.

몇 번 더 큐브를 추가해 보면서 살펴본다.

프리팹에 오브젝트가 많이 포함되어 있을수록 파일의 사이즈는 확연히 차이가 난다.

게임을 만들다 보면 프리팹 하나에 여러 오브젝트들이 붙어있게 되는 경우는 많기 때문에 거의 일반적으로 Text 모드가 용량이 크다고 보인다.

비교

테스트 결과로 비교해 보면 바이너리를 사용하는 것이 데이터의 크기를 줄여주기 때문에 프로젝트를 열고 데이터를 저장하는 과정에서 시간이 단축될 수 있다.

하지만 유니티를 사용한 프로젝트를 협업할 때에는 바이너리보다는 Text 가 권장된다. Github에서는 공식문서에서 해당 부분에 대하여 Force Text로 설정해야 한다고 명시해 두었다.

Github - Git and Unity

유니티에서도 기본값은 Force Text이며 이렇게 Force Text를 권장하는 이유는 바이너리 형식으로는 파일을 수정하고 병합하는 것이 불가능하다. 따라서 변경된 사항을 파악하는 것이 불가능한데 협업뿐만 아니라 개인 프로젝트 또한 버전 컨트롤을 사용하는 것이 일반적인데 해당 기능을 사용하지 못하는 Mixed 또는 Binary 모드는 더 이상은 사용되지 않는 기능으로 생각된다.

에디터 버전 : 2021.3.28f1 (LTS)

유니티 에디터의 전체적인 설정을 변경할 수 있는 항목이다.

Unity Remote [Depricated]

Android, iOS 등 앱을 개발할 때 사용하기 위한 기능으로 유니티 플레이 모드에서 화면 출력과 입력이 디바이스와 연결되도록한다. 따라서 빌드 이전 단계에서 타겟 디바이스를 통한 테스트가 가능하다.

2020.1 및 이후 버전에서는 depricated 되었으며 Device Simulator Package가 기능을 대신한다.

Device Simulator Package

2020 이후 버전이라면 에디터에 기능이 포함된 상태로 Window > General > Device Simulator 를 통해 사용할 수 있다.

이전 버전의 경우 패키지를 설치해 주어야 창을 열 수 있다.

패키지 매니저를 통해서 설치가 가능하며 이 때 패키지가 검색해도 나오지 않는 경우 

패키지 매니저 창에서 어드밴스 설정에 들어가서 

Pre-release Package 옵션을 활성한 이후에 패키지를 검색하면 찾을 수 있다.

Asset Serialization

프로젝트를 저장할 때 에셋들의 정보를 저장하는 방식에 대해서 설정할 수 있는 옵션이다.

Serialization 옵션에는 세가지가 있다.

Mixed

에셋이 바이너리와 문자열 각각의 저장된 상태로 유지된다. 새로 추가되는 에셋의 경우 바이너리가 적용된다.

Force Binary

에셋을 바이너리로 저장한다. 

임의의 프리팹을 생성하고 파일을 열어보면 바이너리로 저장된걸 확인할 수 있다.

비주얼 스튜디오에서 파일이 열리지 않는 경우 Extensions > Manage Extensions 에서 HexVisualizer 를 설치하면 된다. 이때 실행중인 비주얼 스튜디오는 모두 종료해야 설치가 진행된다.

Force Text

에셋을 문자열로 저장한다.

저장된 정보는 텍스트 기반으로 데이터 직렬화 언어로 많이 사용되는 YAML 형식이다.

프리팹의 정보가 키&밸류 형태로 정리되어있어  바이너리와 달리 사람이 쉽게 읽을 수 있도록 표현되었다.

Force Text 모드에서 프리팹을 생성하고 Mixed 모드로 변경시 기존 프리팹은 텍스트, 새로 생성된 프리팹은 바이너리로 저장된다.

Mixed 또는 Force Text 를 선택한 경우 Serialize Inline Mappings On One Line 토글이 활성화된다.

이 옵션은 참조 및 인라인 맵핑을 한 줄에 쓸것인지 여부를 정한다. 비활성화시 한 줄의 총 문자가 80자 이상이 되면 텍스트가 분할된다.

Default Behaviour Mode

프로젝트를 처음 생성시 2D 또는 3D를 선택하는데 프로젝트 생성 이후에도 해당 설정에서 변경이 가능하다.

유니티에서는 프로젝트가 Full 2D 인 경우 이외에는 모두 3D 로 작업환경을 정할 것을 추천한다.

2D와 3D 설정에는 프로젝트의 몇가지 기본세팅에서 차이가 있다.

2D

- Import 하는 모든 영상은 2D 이미지로 간주되며 Sprtie로 설정된다.

- Scene View 가 2D로 세팅된다.

- 게임 오브젝트가 기본적으로 실시간 Directional light 의 광원을 받지 않는다.

- 카메라의 기본 위치가 0, 0, -10 으로 설정된다.

- 카메라가 Orthographic 으로 설정된다.

- Lighting 창의 옵션의 경우

   * 새로운 씬에 대해서 Skybox가 비활성화

   * Ambient Source 는 Color(54, 58, 66) 로 설정

   * Realtime Global Illumination(Enlighten) 꺼짐 상태

   * Baked Global Illumination 꺼짐 상태

   * Auto-Building 꺼짐 상태

3D

- Import 한 모든 이미지가 2D 이미지로 간주되지 않는다.

- Sprite Packer 가 비활성화된다.

- Scene View 는 3D로 설정된다.

- 기본 게임 오브젝트가 리얼 타임 Directional Light 광원을 받는다.

- 카메라의 기본 포지션은 0, 1, -10 으로 설정된다.

- 카메라가 Perspective 로 설정된다.

- Lighting 창의 경우

  * Skybox 는 built-in Default Skybox 로 설정

  * Ambient Source 는 Skybox 로 설정

  * Realtime Global Illumination (Enlighten) 켜짐 상태

  * Baked Global Illumination 켜짐 상태

  * Auto-Building 켜짐 상태

차이점을 보면 2D에서 3D 작업을 한다고 해서 치명적인 문제가 발생하지는 않는다.

하지만 몇가지 기본 설정들은 각 상황에서만 사용하는 경우가 많기 때문에 맞춰서 작업하는것이 권장된다.

새로운 시작을 위해서 머나먼 타국으로 떠나 있던 누이가 잠시 귀국을 했다.

나의 기준에서는 엄두도 못할 과감한 결단이였기에 걱정이 앞섰지만 종종 전해오는 소식들이 그 결정이 좋은 방향으로 나아가는 듯 보여서 안도가 되면서도 항상 무슨 일을 하기에 앞서 걱정부터 하며 섣불리 행동으로 옮기지 못하는 삶의 태도에 대해서도 다시 한번 생각해 보게 된다.

같은 땅을 밟고 있을때에도 각자의 삶이 이끄는 대로 흘러가다 보면 좀처럼 보기가 쉽지 않다. 이제는 드넓은 바다 저편에서 지내게 되면서 그 만남은 더 어려워졌기에 이번 재회는 아주 귀중한 시간이었다. 

이것저것 챙겨온 선물 속에서도 재밌는 것이 눈에 띄었다.  

치토스 로고를 보고 당연히 과자겠거니하고 그중에서도 맥 앤 치즈맛이라는 생소한 제품일 거라 생각했다.

그래서 퇴근 후 심심풀이로 선물받은 과자나 먹어볼까 하고 포장을 뜯고 내용물을 본 순간 잠시 다음 동작을 이어가지 못했다.

사실 포장을 뜯고나서도 뿌셔뿌셔와 비슷하게 가루를 넣고 흔들어 먹는 과자가 아닐까 잠깐 생각을 해봤지만 너무 나도 날것인 내용물에 뒤늦게 포장지를 살펴보기 시작했다.

언어의 장벽을 기술의 힘을 빌어 허물고 찬찬히 살펴보았고 단순한 과자가 아닌 약간의 조리가 필요한 레트로트 식품이라는 걸 깨달았다. 조리 방법은 냄비에 물을 올려 조리하는 것과 전자레인지를 사용한 두 가지가 있었다.

사실 처음 조리법만 읽고 추가적으로 필요한 재료를 사오느라 두 번째 방법이 있다는 사실은 사진을 다시 보게 되는 시점에서 알게 되었다.

즉시 우유와 버터를 사 와서 조리에 들어갔다.

조리법은 간단했다. 

면을 삶은 후 버터를 녹이고 우유와 동봉된 가루를 넣어 잘 섞어준다.

가루에서는 꼬릿꼬릿한 치즈와 약간의 매콤한 향이 난다. 섞어주다 보면 점점 맥엔치즈 냄새에 가까워진다.

마지막으로 후추를 뿌려서 마무리하고 나니 꽤 먹음직스러워 보인다. 

치토스의 맛은 잘 모르겠지만 일반적인 맥엔치즈 맛이 나고 맥주랑 먹기 좋은 맛이다.

생각보다 양이 많아서 혼자서 다 먹으려니 배가 불렀다. 딱 둘이서 안주 삼아 먹는 게 좋을 것 같다.

뜻밖의 재밌는 선물 덕분에 평범한 일상 속에서 잠시나마 소확행을 즐길 수 있었다.

딕셔너리는 해시 테이블 또는 키, 밸류라고 부른다. 

데이터는 중괄호 안에 선언되며 키와 밸류는 콜론으로 구분된다.

>>> dic_1 = {"key_1": 'value_1', 'key_2':"value_2"}
>>> dic_1["key_1"]
'value_1'
>>> dic_1['key_1']
'value_1'
>>> dic_1["key_2"]
'value_2'

키는 큰 따옴표 또는 작은따옴표를 사용해 선언할 수 있다.

키값의 경우 보통 문자열, 숫자, 튜플 등이 사용되고 밸류에는 어떠한 데이터 타입도 사용할 수 있다. 

딕셔너리의 특징은 맵 형식이기 때문에 순서가 보장되지 않는다. 따라서 인덱스를 통한 요소의 접근이나 첫 번째, 마지막 등의 순서가 필요한 정보에 대해서는 접근이 불가능하며 키값을 사용해서 접근해 사용한다.

>>> dic_1[0]
Traceback (most recent call last):
  File "<pyshell#9>", line 1, in <module>
    dic_1[0]
KeyError: 0

중복된 이름의 키를 사용하게 될 경우 에러는 발생하지 않지만 앞에 선언된 키, 밸류가 뒤에 값으로 덮어씌워진다.

>>> dic_2 = {'key_1':'val_1','key_1':'val_2'}
>>> dic_2['key_1']
'val_2'
>>> len(dic_2)
1

딕셔너리의 요소 개수를 반환하는 함수인 len()을 사용하면 앞에 선언된 요소가 존재하지 않는걸 알 수 있다.

튜플은 리스트처럼 배열로 요소를 저장할 수 있다.

요소를 선언할 때는 값을 콤마로 구분해서 저장이 가능하며 이때 소괄호를 사용해서 값을 감싸서 튜플로 표시하는 게 일반적이다.

>>> tuple_1 = 1, 2, 3
>>> tuple_2 = 4,
>>> tuple_3 = (5, 6, 7)
>>> tuple_1
(1, 2, 3)
>>> tuple_2
(4,)
>>> tuple_3
(5, 6, 7)

이렇게 튜플에 값을 할당하는것을 패킹이라고 한다.

이 튜플은 한 번에 여러 개의 변수에 값을 할당하는 게 가능한데 이것을 언패킹이라고 한다.

>>> tuple_1 = 4, 5, 6
>>> x, y, z = tuple_1
>>> x, y, z
(4, 5, 6)

불변성

튜플이 리스트와 다른 점은 선언된 이후에 값의 수정이 불가능하다.

>>> tuple_1 = 1, 2, 3
>>> tuple_1[0] = 4
Traceback (most recent call last):
  File "<pyshell#38>", line 1, in <module>
    tuple_1[0] = 4
TypeError: 'tuple' object does not support item assignment
>>> tuple_1 = 4, 5, 6
>>> tuple_1[0]
4
>>>

튜플의 요소에 인덱스로 접근하여 값을 변경하면 에러가 발생하지만 새로 값을 할당하는 것은 문제가 되지 않는다.

이러한 튜플의 특징을 활용해서 런타임에 값이 변하면 안 되는 정보를 저장하거나 또는 하나 이상의 정보가 조합을 이룰 때 의미를 가지는 데이터를 저장할 때 사용된다.

>>> tuple_1 = 4, 5, 6
>>> x, y, z = tuple_1
>>> x, y, z
(4, 5, 6)
>>> vector3 = (10, 2, -4)
>>> x, y, z = vector3
>>> x
10
>>> y
2
>>> z
-4
>>> x, y, z
(10, 2, -4)

여래 값을 전달할 수 있기 때문에 함수에서 여러 개의 값을 반환하거나 또는 매개변수로 전달이 필요할 때 등 다양하게 활용이 가능하다.

프로그래머들은 각자의 개발 철학을 가지고 있다.

프로그래밍 언어들의 다양한 특징들은 개발자들의 철학을 배경으로 만들어지게 된다.

파이썬 또한 개발자의 철학이 담겨 있는 프로그래밍 언어이다. 그 철학은 pep-20으로 알려진 문서에 담겨있다.

PEP 20 – The Zen of Python

문서의 제목을 번역하면 파이썬의 선이다.

여기서 선은 불교용어 선(禪)이다. 서구권에 선이라는 개념을 정착시킨게 일본 불교학자이다 보니 일본식 발음인 젠(zen)이 고유명사가 되었는데 문서에서 사용된 뜻이 불교의 선과 동일한 의미를 가지기 보다는 파이썬의 개발 철학이나 가치와 원칙 등 방향성을 나타내는 의미로 쓰인거같다. 제목도 일반적인 문서스럽지 않은데 이는 파이썬의 공식 문서 대부분이 비슷한 느낌을 준다.

문서의 저자를 보고 Tim Peters가 파이썬을 만든사람인줄 알았지만 알고보니 파이썬의 초기 개발자는 Guido van Rossum(귀도 반 로섬)이라는 네덜란드 개발자였다.

Foreword for "Programming Python"

파이썬의 서문에서는 탄생 배경에 대한 인터뷰 내용이 있다. 심심했던 그는 ABC 언어에 영감을 받고 취미로 만들기 시작했다고 하는데 그렇게 만들어진 언어가 지금까지도 많은 사람들에게 사용된다는게 그의 천재적인 면모가 보인다.

다시 파이썬의 선으로 돌아가서 저자인 Tim Peters는 파이썬 초기 설계부터 현재까지 개발과 커뮤니티에 많은 영향을 준 인물이다. 해당 문서는 커뮤니티에 파이썬의 가치와 철학을 공유하고 강조하기 위해서 작성되었으며 커뮤니티 안에서 협업할 때 지켜야할 원칙을 정리하고 제시하는 목적을 가지고 있다.

작성 배경이 그렇다보니 문서의 내용이 다소 가볍고 사용되는 표현들도 유머러스함이 보인다. 

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!
(네임스페이스는 정말 훌륭한 아이디어다 -- 더 많이 사용하자!)

문서에서 반복해서 명확성, 간결성, 가독성을 강조한다. 이러한 철학으로 인해서 문법면에서는 엄격하며 이를 위한 스타일 가이드도 있다. (PEP 8)  이러한 코드 스타일들은 대부분 기술적인 제한 보다는 프로그래머들간에 지켜야할 관례이다.

예를 들어서 상수의 경우 모두 대문자로 표기하는 것을 규칙으로 한다.

하지만 일반 변수를 모두 대문자로 표기하고 그 값을 마음대로 바꾸어 사용한다고해서 실행이 안되거나 하지 않지만 다른 프로그래머들에게는 상수의 값이 변경되는 예상하지 못한 동작이 될 수 있고 이는 파이썬의 철학과 반대되는 행동이라 볼 수 있다.

리스트

순서를 가지는 객체의 모음이다.

list_1 = []	# 빈 리스트 	
list_2 = [0, 1] # 정수타입
list_3 = ['a', 'b', 'c'] # 문자타입
list_4 = [0, 1, 'a', 'b'] # 정수와 문자타입
list_5 = [0, ['a', 'b']] # 리스트는 리스트를 요소로 가질 수 있다.

0개 이상의 요소를 콤마로 구분하며 전체 요소는 대괄호로 감싼다.

값을 참조할 때는 대부분의 프로그래밍 언어에서 사용되는 배열과 마찬가지로 인덱스로 접근할 수 있다.

역시 첫 번째 인덱스는 0으로 시작한다.

>>> list_1 = []
>>> list[0]
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    list[0]
TypeError: 'type' object is not subscriptable
# 비어있기 때문에 값을 참조할 수 없다.

>>> list_2[1]
1

>>> list_3 = ['a','b']
>>> list_3[0]
'a'

>>> list_5[1][1]
'b'

리스트 내부에 리스트 요소는 다차원 배열의 접근과 유사하다.

함수

리스트는 다양한 함수를 사용해서 다룰 수 있다.

append

리스트 맨 끝에 요소를 추가한다.

>>> list_functions = []
>>> list_functions.append('a')
>>> list_functions.append('b')
>>> list_functions
['a', 'b']

insert

지정한 위치에 요소를 추가할 수 있다.

>>> list_functions.insert(0, 'aa')
>>> list_functions
['aa', 'a', 'b']
# 지정한 인덱스에 요소가 추가되고 그 뒤로 기존 요소들이 한칸씩 밀린.

pop

리스트의 마지막 요소를 반환 후 삭제한다.

>>> list_functions.pop()
'b'
>>> list_functions
['aa', 'a']

# 요소를 반환 후 해당 리스트에는 제거됨

remove

지정한 값과 동일한 요소를 삭제한다.

>>> list_functions = ['a', 'a', 'b']
>>> list_functions.remove('a')
>>> list_functions
['a', 'b']
# 동일한 요소가 있을 경우 먼저 나오는 요소가 제거된다.

index

요소의 인덱스를 반환한다.

>>> list_functions.index('a')
0
>>> list_functions.append('a')
>>> list_functions.index('a')
0
# 동일한 요소가 있을 경우 먼저 나오는 요소의 인덱스를 반환

count

리스트 내에서 지정한 값과 동일한 요소의 개수를 반환한다.

>>> list_functions.count('a')
2

sort

요소들을 정렬한다. 

>>> list_char = ['d', 'a', 'e', 'c', 'b']
>>> list_int = [3, 2, 5, 4, 1]
>>> list_char.sort()
>>> list_int.sort()
>>> list_char
['a', 'b', 'c', 'd', 'e']
>>> list_int
[1, 2, 3, 4, 5]

오름차순으로 정렬되는 것으로 보이지만 정확하게는 기본값이 오름차순이고 이는 함수의 매개변수를 통해 설정가능하다.

>>> list_char_inc = ['d', 'a', 'e', 'c', 'b']
>>> list_char_dec = ['d', 'a', 'e', 'c', 'b']
>>> list_char_inc.sort(reverse=False) # defualt가 False이기 때문에 매개변수가 없으면 오름차순
>>> list_char_dec.sort(reverse=True)
>>> list_char_inc
['a', 'b', 'c', 'd', 'e']
>>> list_char_dec
['e', 'd', 'c', 'b', 'a']

reverse

요소들을 역순으로 정렬한다.

>>> list_char = ['d', 'a', 'e', 'c', 'b']
>>> list_char.reverse()
>>> list_char
['b', 'c', 'e', 'a', 'd']

clear

리스트의 요소를 모두 제거한다.

>>> list_clear = [1, 2, 3, 4, 5, 6]
>>> list_clear
[1, 2, 3, 4, 5, 6]
>>> list_clear.clear()
>>> list_clear
[]

데이터 타입

파이썬에서 다룰 수 있는 가장 기본적인 데이터의 종류는 정수, 부동소수점, 문자열, 부울값이 있다.

이러한 타입들은 엄밀하게 구분되는데 type() 함수를 사용하여 변수나 값의 타입에 대한 정보를 알 수 있다.

연산 과정이 있어도 결과 값으로 타입이 결정된다.

문자열을 값을 할당할 때는 큰 따옴표("") 또는 작은따옴표('')로 문자를 감싼다.

일반적인 문자열을 감쌀 때는 두 부호가 동일하게 동작을 하지만 특수한 상황에서 다르게 사용한다.

만약 문자열 안에 부호가 포함되어 있는 상황에서는 문자열의 범위를 표현하려던 부호가 의도와 다르게 적용될 수 있다.

Hello "Python"!
I'm Bak

a = "Hello "Python"!"

b = 'I'm Bak'

이런 경우에는 문자열을 해석할 때 오류가 발생하지 않도록 두 종류의 방식을 모두 사용할 수 있도록 한다.

형변환

type casting

데이터형을 다른 데이터 형으로 변환하는 것을 뜻한다.

Int

int() : 데이터 타입을 정수로 변환시킨다.

Float

float() : 데이터 타입을 부동소수점으로 변환한다.

String

str() : 데이터 타입을 문자열로 변환한다.

Bool

bool은 어떤 조건이 성립했는지 아닌지 처리를 바꾸면서 실행된다. 

True와 False 둘 중 하나로 존재한다.

bool()을 사용하면 입력된 식이나 값을 평가해서 bool 타입의 값으로 출력한다. 이때 0의 경우 false 그 외의 값들은 모두 true로 평가된다.

함수는 여러 개의 처리를 기능별로 모아 놓은 것이다. 

사용할 때는 함수가 어떤 기능을 하는지만 알아도 되며 내부에서 처리되는 과정들은 알 필요가 없다.

이때 함수에 전달하는 데이터를 인수, 함수로부터 돌아오는 값을 반환값이라고 한다.

필요에 따라 직접 함수를 구현해서 사용할 수 있지만 파이썬에는 미리 준비된 함수도 많이 제공된다.

예를 들어서 두 개의 값을 비교해서 더 크거나 또는 작은 값을 구하는 처리가 필요한 경우가 빈번하게 사용되는 상황일 때, 매번 값을 비교하는 과정을 작성하는 것은 비효율적이다. 이럴 때 함수를 만들어서 처리하면 코드가 간결해진다. 

만약 필요한 함수가 파이썬에서 제공되는 것이라면 직접 구현하는 과정도 생략이 될 수 있다.

예시에서 처리하는 기능의 경우 파이썬에서 max(), min() 함수가 있다.

max(a, b)  : a와 b 중 큰 값을 반환

min(a, b) : a와 b 중 작은 값을 반환 

함수는 기본적으로 함수명() 형태로 선언되며 실행할 때 괄호를 붙여 실행한다. 어떠한 값을 입력해야 한다면 괄호 안에 변수나 값을 넣는다.