카카오 개발자 박승규님의 2019년 파이썬 개발자 대회에서 발표한 자료의 슬라이드를 보고 감명받아서 적어봅니다.
# -*- coding: utf-8 -*-
s1 = "파이썬"
s2 = "우분투"
def f():
yield "수아는 " + s1 + "을 공부합니다."
yield "규리는 " + s2 + "를 좋아합니다."
g = f()
print(type(g))
print(next(g))
print(next(g))
제너레이터는 함수안에 return 대신 yield 를 포함시키면 만들 수 있다고 합니다.
그리고
이해하기가 쉽지않습니다 문법의 깊이가 > 저세상 난이도> 입니다…
한번에 이해가 안되기에… 반복적으로 하루에 한번씩 쳐다봅니다…
한 삼천번만 읽고 쓰고 읽고 쓰고를 반복하다보면 언젠가는 이해가 될거라 생각하고
지금 무쟈게 참고문헌을 찾아서 읽어재끼고 있는중입니다…
참고문헌:
[1] GitHub - wapj/pyconkr2019tutorial: 파이콘 2019 튜토리얼 준비 (박승규님의 발표 자료)
[2] 39. Generator(제네레이터) - 파이썬 - 기본을 갈고 닦자! (위키독스 개념 설명)
[3] iterator, 반복자 :: 류광의 번역 이야기 (관련 용어 개념에 대한 심도있는 분석 – 반복자에 관한)
[크롬OS 에서 작성했씁니다]
[크롬OS 에서 내용을 매끄럽게 수정 및 보완했습니다]
[우분투 18.04 파여폭스 나비에서 여러차례 예제 코드를 고쳤습니다]
# -*- coding: utf-8 -*-
# 우분투 한국 대화방 서니님의 도움 코드: 20190530
import sys
import time
def spinning_cursor():
while True:
for cursor in '|/-\\':
yield cursor
spinner = spinning_cursor()
for _ in range(31):
sys.stdout.write(next(spinner))
sys.stdout.flush()
time.sleep(0.3)
sys.stdout.write('\b')
# 편집: Emacs 26.2 (Ubuntu 18.04)
마이클잭슨의 춤사위(3)를 보면 춤동작이 참 힘이있고 아름답다라는 느낌이 오는데,
가다 서다 가다 서다를 반복함에 한번씩 '멈춤’이 그 비결이라는걸 어데서 읽은거 같아요.
그 적재적소의 ‘멈춤’ 덕분에 춤을 예술의 경지로 승화시키는!
파이썬의 ‘yield’ 에서 춤사위에서의 ‘멈춤’ 처럼 그런 느낌을 받습니다…
파이썬 코드를 예술로 만들어주는 마법의 단어
yield
오늘은 yield 의 그 느낌만 간직한채 참고문헌 읽는걸 멈출까해요,
참고문헌
(1) 구글: “yield 활용”
(2) 아기와 yield (모두의공원): 프로그래머 부부의 아기옷 : 클리앙
(3) 마이클잭슨 1999년 내한공연: 서울 잠실 올림픽주경기장 [1999-06-25]
[우분투 파여폭스 나비에서 작성했씁니다]
[우분투 파여폭스 나비에서 추가 참고문헌을 적었습니다]
[크롬OS 에서 주석을 보강했씁니다]
소를 봐야 소 가격 흥정을 할 수 있듯… yield 가 어데 쓰이는 물건인지를 봐야 좀 더 동기부여가 되지 않을까요… 해서 찾아봤습니다.
대한민국 리눅스 사용자에겐 필수 항목인 입력기 프로젝트 ibus 에서요. libhangul/ibus-hangul 소스코드에선 yield 가 발견되지 않았습니다…
ibus 소스코드를 git clone 해서 find/xargs/grep 로 찾아보니 딱 4군데서 yield 를 쓰고 있었습니다.
실제 프로젝트에서 어떻게 쓰이느냐는 엄청 중요합니다. 이보다 더 큰 > 동기부여> 가 있을까요?
ibus 는 Wayland 도 지원합니다. 아주 중요한 요소입니다. 리눅스/오픈소스 사용자들에게 Wayland 는 곧 미래이며 희망입니다.
ibus 소스코드를 통해서 전 yield 가 무엇인지를 그리고 어떻게 쓰이는지를 두눈으로 확인하고자 합니다. 정말 간절합니다.
꾸벅,
참고문헌 및 주석
(1) ibus: Intelligent Input Bus - Wikipedia (위키백과 영문)
(2) ibus 핵심 인물:
[크롬북 우분투 18.04 파여폭스 나비에서 작성했씁니다]
[크롬북 우분투 18.04 파여폭스 나비에서 내용을 보강했습니다]
한글 입력이 쉽지 않음을 다들 알고계십니다. 그래서 libhangul 의 위대함… 감사함이 다시금 새겨집니다… 한글을 한자 한자 자판으로 입력할때마다 전 느낍니다. 지금은 나비로 한글을 입력중입니다. 정확히 두벌식 옛글 모드로 설정을 해둔 상태입니다.
하지만 때가 가까운 미래는 Wayland 시대이므로… 나비에서 ibus-hangul(Wayland 지원함) 로 갈아탈 준비를 하고 있습니다.
데비안 11 (Bullseye) 이 출시될즈음 어느정도 Wayland 가 안정화되지 않을까 생각합니다. 2년 정도 남았어요.
그때까진 이 나비를 딸래미 아끼듯 애지중지 소중히 다뤄보고 싶어요. 이제 2년정도 남았기에,
nabi 소스코드에서도 yield 는 발견되지 않았씁니다.
ibus [2] 소스코드가 yield 공부자료로 확정되는 순간입니다.
소의 볏짚이 yield 와 무슨 상관이 있길래 첫글에 사진으로 첨부했느냐…
실무(농사꾼의 실무를 말함)에서도 yield 방식의 활용으로 덕을 보고 있습니다.
소에겐 볏짚이 소화제입니다.
사료를 먹어도 볏짚을 안먹어주면 그 먹은 사료를 소화를 못시키며,
다음 끼니때 사료를 더 못먹습니다. 배(위)가 아파오는 까닭입니다…
그래서 소에겐 볏짚이 정말 중요합니다. 마치 물과 물고기의 관계처럼요,
볏짚을 줄때에 두가지 방식이 있습니다.
첫번째, 한덩어리(원형으로 생긴 뭉치-- 대략 300~400kg) 자체를 소여물통에다 놓고 소가 그 볏짚을 먹어치워서 다 떨어질때마다 다시 채워주는 방식입니니다.
이를 무제한급여라고 합니다. 먹고싶을때 아무때나 원하는만큼 먹을수 있기에 소들은 좋아할지라도,
필요이상으로 먹어치우므로 볏짚이 많이 소요됩니다. 창고에 비축해둔 볏짚이 빨리 동납니다…
두번째, 이게 yield 방식입니다. 끼니때에 딱 소에게 필요한 만큼의 볏짚을 소여물통에 공급해주는 방식입니다. 농장주가 일거리가 좀 늘어나는 단점이 있지만,
필요이상으로 소모되는 볏짚을 절약할 수 있는 장점이 있습니다. 그래서 원가절감위하야 이렇게 yield 방식으로 소를 키우는 농가가 늘어나고 있습니다.
볏짚도 돈을 주고 사야하는 농가는 진짜 와닿는 방식입니다. 저도 최근 yield 방식으로 볏짚을 급여중입니다.
제 자신이 비전공자라 콤푸타의 한 개념을 이해하기빡센고로 문과적인 개념을 끌어다와서 콤푸타의 yield 개념을 보충하였습니다.
이제 갑니다. 진짜 yield 를 파이썬적으로 요약한 문서를 발견했어요. 박연오님의 yield 설명입니다. [1]
진짜로 쉽지않습니다…;;;
[1] 반복자와 생성기(제너레이터) 그리고 yield: 7.4 반복자와 생성기 | 연오의 파이썬 프로그래밍 입문서
[2] ibus 공식 소스코드 저장소: GitHub - ibus/ibus: Intelligent Input Bus for Linux/Unix
[우분투 18.04 파여폭스 나비에서 작성했씁니다]
[크롬OS 에서 내용을 좀 더 매끄럽게 고쳤습니다]
코루틴은 대략 협업의 개념 같아요…
실무에서 볏짚작업할때 트랙터 두대(+두명)가 출격합니다.
한대는 집초기를 매고, 다른 한대엔 결속기를 매달고 들판에 함께 나갑니다.
볏짚작업을 대략 파이썬 함수(제너레이터)로 그림을 그려봤어요~
(문과적 상상속에서 그린 함수라서 결함이 존재합니다. 개념파악차원에서만 봐주세요~^^^)
def 볏짚작업():
while True:
yield 집초() # 볏짚작업시 집초작업을 먼저함
yield 결속() # 집초작업 끝나자마자 결속작업 수행함
가을걷이 = 볏짚작업()
for 마지기 in range(100): # 100마지기의 들판
next(가을걷이) # 100마지기 다할때까지 볏짚작업() 반복수행.
yield 위치에 return 을 삽입해도 수행은 되지만, return 을 삽입하면 트랙터 기름값이 많이 들어가며 시간도 많이 소요됩니다.
참고문헌 및 주석: 볏짚작업 사진 추가 (들판에서 집초작업중인 트랙터)
사진출처: http://blog.daum.net/_blog/BlogTypeView.do?blogid=0Bo6u&articleno=17233367&categoryId=876106®dt=20110906233143
[크롬OS 에서 작성했씁니다]
[우분투 18.04 파여폭스 나비에서 오타 수정했습니다]
yield 링크를 타고 타고 가다보니… 비동기/동기와 만나더이다…
부득이하게,
트랙터 1대가 작업할때 마지기마다 집초작업/결속작업을 같이하면서 100마지기를 해나가는것이 [동기방식]이요,
해당 트랙터에 집초기 달아서 100마지기 전체를 집초작업만을 먼저 빠르게 해치우고나서,
다시 결속기로 옮겨매달고서 결속작업으로 마무리 해나가는게 [비동기방식]입니다.
(잠시 문과적 상상을 끌어들여 개념을 보충합니다)
비동기가 빠릅니다. 동기는 꼼꼼합니다. 둘 다 일장일단이 있습니다.
실무에선 비가 간헐적으로 오지않는한은 대부분 비동기방식으로 볏짚작업을 해나갑니다.
빠르거등요, 그리고 비동기방식으로 하면 시간도 절약하며 인건비/기계대여비도 적게 듭니다.
과거 저의 경험입니다.
FreeBSD 4.x 시절에 파일시스템이 UFS 였는데…
파일 하나 압축을 해제하거나 다른 파티션으로 복사할때 리눅스 파일시스템에 비하여 시간이 좀 걸렸습니다.
그래서 FreeBSD 5.x 에서 UFS2 라는 파일시스템이 생겼습니다. 좀 빨라졌더라구요…
설치시에 파티션분할을 자동모드로 해두면 5.x 에서 루트(/) 는 UFS 그리고 /home 파티션류는 UFS2 로 할당하더이다.
지금 깨달은 사실이지만, 큰틀에서 봤을때 UFS 는 [동기방식], UFS2 는 [비동기방식] 이었습니다.
다시 볏짚작업으로 돌아와서, 2대의 트랙터로 작업하더라도 말이죠,
각각의 트랙터 1대가 집초작업과 결속작업을 같이 해나가면 그게 심지어 10대라 하더라도 시간이 많이 걸리며 인건비/기계대여비 엄청 들어갑니다.
1마지기할때마다 집초기 달았다가 결속기 옮겨달았다를 수없이 반복해야하기에, 기계 옮겨매다느라 시간을 많이 잡아먹는까닭입니다.
솔직히 사람 힘도 많이 들어갑니다, 기계 옮겨매다는게 진짜 빡셉니다…;;;
동기방식이 비동기방식에 비해 속도가 안나오는 근원적 배경입니다.
비동기방식으로 하면 1대는 집초작업만 쭈우욱 해나가고 뒤따라가면서
나머지 한대가 결속작업만 해나가면 인건비/기계대여비도 아끼고 전체작업시간을 앞당길 수 있습니다.
결론: 비동기방식이 생산성 향상에 좋습니다^^^
[크롬OS 에서 작성했씁니다]
실무에선 비가 간헐적으로 오지않는한은
다음날 또는 오후 늦게 비가 오게되면 100마지기 전체 작업이 불가능합니다.
그래서 20마지기 정도만 집초작업하고서 바로 그 20마지기만 결속작업완료후 모든 볏짚작업을 종료시킵니다.
나머지 80마지기는 비가 그치고 며칠정도 들판을 햇볕에 말린후에
작업 재개합니다.
만약 비를 무시하고
100마지기 전체다 집초작업 해놓으면 80마지기는 비에 젖은채로 결속해야하는데,
비에 젖은 볏짚을 결속해놓으면 내부에서 볏짚이 썩어들어가고 그 볏짚은 소가 먹질 못합니다.
비가 오는 날은 볏짚작업이 불가능한 이유였습니다. 다른표현으로 비오는 날을 앞두고선 비동기방식을 쓸 수가 없습니다.
재부팅 시점에서 더이상 다른 작업을 벌이지 않고 (하던작업을 모두 정상종료시킨 후) sync; sync; sync; 를 여러번 쉘(슈퍼유저)에서 입력하고서,
콤푸타[FreeBSD 4.x 이하]를 재부팅(reboot) 또는 전원을내리는(shutdown) 이치가 위의 비올때의 볏짚작업 상황이랑 비슷합니다.
주석: sync(8) – FreeBSD
URL: sync(8)
[우분투 18.04 파여폭스 나비에서 작성했습니다]
[크롬OS 에서 내용 보완했습니다]
잠시 쉬어갑니다.
위에서 우리가 입력기 나비에서 ibus(한글: ibus-hangul) 로 갈아탈 수 밖에 없는 이유가 Wayland 였습니다.
이 Wayland 가 아직은 안 와닿는건 여전히 많은 리눅스 배포판들이 Xorg 위에서 돌아가는중이며,
원체 밑바닥에서 돌아가는거라 관련 개발자외엔 신경쓸 필요가 없기때문입니다.
그래서 일반사용자 수준에선 웹브라우저 바꾸듯 쉽게 교체해가며 테스트 하기 힘든 영역입니다.
그 침묵을 깨고 데비안이 10번째판 부스타에서 먼저 시도를 했어요. 기본 윈도를 Xorg 에서 Wayland 로 바꾸었습니다.
모질라 프로젝트에서도 어떤 준비를 하고 있을거라 생각합니다. 웹브라우저플젝중 가장 오픈소스 친화적인 곳이니깐요.
그리고 혹시라는 마음에 찾아보니 크롬프로젝트에서도 2018년(사실 더 이전)부터 꾸준히 준비를 해왔던 정황을 방금 발견했씁니다.
Xorg 를 탈피하고 Wayland 위에서 크롬OS 나 크롬브라우저가 돌아가게끔하는 준비를 해왔던겁니다.
Xorg 에서 Wayland 로 넘어가는건 거의 개벽수준입니다. 어마어마합니다…
데비안 11번째판 Bullseye 가 출시될때에나 Wayland 가 좀 안정화되지 않을까 생각합니다.
(좀 더 정확히 Wayland 를 지원하는 응용프로그램들이 많이 생길거라는 의미)
https://github.com/Igalia/chromium/tree/ozone-wayland-dev (Wayland 이식 실험 및 작업 공간 – 외부저장소[BRANCH])
https://bugs.chromium.org/p/chromium/issues/detail?id=578890 (크롬플젝 본진에서의 Wayland 작업현황 – 버그와의 빡센 전투중)
태그: Wayland, 리눅스, Chromium
[크롬OS 에서 작성했씁니다]
