파이썬 딕셔너리의 활용

딕셔너리, get을 쓰자.

파이썬을 처음 익힐때, 리스트에서 자동화를 구현하고 짜릿했지만, 딕셔너리는 처음 봤을때부터 그 복잡한 모습과 사용성에 학습을 뒤로 미뤘다. 리스트에서 봤던 대괄호 []가 이젠 요소를 참조하는데 쓰인다니, 리스트와 딕셔너리는 무슨 연관이라도 있는걸까 고민하기도 했었다.

몇 년이 지나고, 결국 딕셔너리를 활용해야하는 때가 왔다. 몰라도 대부분의 자동화와 머신러닝이 가능했다는게 신기하다. 하지만 웹을 다루는 이상, 딕셔너리는 필수다.

딕셔너리는 {‘키1’ : ‘벨류1, 벨류323, 벨류 665453’, ‘키2’ : ‘벨류2’, ‘키434′:’벨류434’,… }로 이루어졌다. 일대 다 관계만 지키면, 그 값(Value)는 무한히 확장히 가능하다. 그리고 각 요소별로 따로 매기는 순서가 없다. 값을 불러서 사용할 땐 x1 = dictionary_name[‘key1’] 같은 식으로 사용이 가능하다.

• {키 : 벨류, 키 : 벨류, 키 : 벨류} 로 이루어짐
• key 요소에 순서가 없다.

선언방법

1. 타이핑
   dict_exam = {‘엑셀’:’xlsx’, ‘파워포인트’:’pptx, ‘워드’:docx}
2. 정의식
   dict_exam2 = dict([(‘City’:’Gumi’), (‘Population’:’404867′)}
3. 간소화된 정의식
   dict_exam3 = dict( City = ‘Gumi’, Population = 404867 )

참조방식

1. 안정적인 방식 : dictionary.get(‘key’)
   • dict_exam2.get(‘City1212’)
     😺 찾으려는 key값이 없을 경우, None이 출력된다. 이를 통해 에러가 나야할 상황에도 전체 코드가 멈추지 않고, 사용자에게 알리거나, 더 똑똑하게 대응을 하도록 ‘잘’ 짤 수 있다.
2. 간소화된 방식 : dictionary[‘key’] (비추천…!)
   • dict_exam2[‘City1212’]
     😿 찾으려는 key값이 없을 경우, KeyError: ‘City1212’ 를 띄우고 작동을 멈춘다.
3. 숫자 인덱스 딕셔너리 참조 방식
   • dict_exam2[0]
     😺 순서로 인덱싱을 할 경우, 여기선 ‘Gumi’가 출력되게 된다. 처음 알았다.

추가방식

1. dict_exam2[‘Weather’:’sunny’]

업데이트 방식

1. dict_exam2.update(Weather=’cloudy’)
2. temp = {‘Weather’ : ‘cloudy’}
   dict_exam2.update(temp)
3. 위 추가방식을 그대로 활용. 순간 문법이 기억안날때 활용도 굿.

반복하는 방식

1. dict_exam2.keys()
2. dict_exam2.values()
3. dict_exam2.items()

list(dict_exam2.keys())로 list로 형변환(type casting)이 가능하다. 매우 중요한 특징으로 보인다.

대괄호는 왜이렇게 많이 쓰일까?(파이썬에서의 Index braket)

1. Index bracket(인덱스 브라켓)으로 불리는 대괄호는 단연 리스트를 정의할 때 많이 쓰인다. 거의 무의식에 저장된 수준으로.
2. list(리스트)나 string(스트링, 문자열) 내부의 한 요소에 접근할 때도 쓰인다.
3. list(리스트)나 mutable sequences(변형 가능한 순서열. 예) 딕셔너리, 리스트)
   아무튼 str.split(‘.’)[0] 이런 식을 쓸 때, str.split[‘.][0] 이런 식으로 실수하곤 한다. 정의를 알면 절대 헷갈리지 않을거같다.

느낀점 : 나는 여태껏 리스트만 많이 썼지, 복잡한 생김새와 사용성에 딕셔너리는 거의 쓰지 않았는데, 웹 개발을 하면서 거의 필수적으로 json과 딕셔너리를 다루기 시작했다. 딕셔너리의 Value를 참조할 때 get을 쓰면 안정적인 코딩이 가능하다는 것을 처음 알았다. try except 때도 그렇고, 에러가 났을때, 사용자에게 알리고, 코드는 계속 돌아가게 하는 방법을 알아서 좋다. 일이 중간에 멈추는게 아닌, 가공이 끝나고 내게 보고를 해주기 때문에 그것들에 대해서만 처리를 하면 된다.

물론 오류가 아예 안나는 코드를 짜는게 최우선이지만, 현직에서 급하게 코딩을 하고 바로 적용을 시킬 때에는 에러가 전혀 안나도록 코딩할 여유가 없다. 그리고 그냥 인풋 실수로 에러가 발생해도, 결과를 뽑아서 전달해주고, 100 중에 90을 살리는게 우선이다. 10은 노가다를 뛰든, 그것에 대한 처리는 뒤에 하는게 더 좋았다.

딕셔너리를 정의할 때 간소화된 정의식도 있다는 걸 처음 알았다. (근데 굳이 그렇게 써야할 필요를 못느껴서 까먹을 거 같다.)