IT/모바일
저자: 스티브 피긴스(Stephen Figgins), 역 전순재
comp.lang.python 뉴스그룹에서는 파이썬 개발팀을 비난하는 분노의 게시물들이 줄줄이 흘러 넘쳤다. 겉에 보이는 기능에 너무 치중했다(† 역자 주: creeping featurism, 최초의 우아한 디자인을 무시하고 순간순간의 제안에 따라 구현을 바꾸는 것), 기업계의 이익에 파이썬을 팔아 치웠다, 너무 빨리 앞으로 나아간다, 파이썬 공동체의 소리에 귀를 기울이지 않고 있다 등등… 무엇 때문에 이와 같은 비난이 한 순간에 터져나왔는가? 왜냐하면 파이썬 개발 팀이 print 서술문의 구문을 바꾸자는 제안 하나를 받아들였기 때문이다.
print 서술문은 파이썬의 직관적인 특징을 잘 나타내주는 것으로 얼마나 파이썬이 배우기 쉬운지를 잘 보여주는 예이다. 무엇인가를 화면에 인쇄하고자 한다면, print 명령어 뒤에 그냥 원하는 것을 놓기만 하면 된다. 여러 개를 인쇄하고자 한다면 각 항목들을 쉼표로 분리해주면 된다. 정말 명료하지 않은가? 게다가 이해하기도 쉽다. 안타까운 점은 print는 오직 표준출력 화면에만 더 정확히 말해 sys.stdout 파일 핸들에만 출력할 뿐이다. 여기에서 말하는 "표준 출력(Standard out)"이란 도스나 유닉스 프롬프트와 같이 텍스트 기반의 콘솔과 통신하는데 사용되는 세 개의 공통적인 시스템 파일 핸들중의 하나를 말한다. 표준출력과 (에러를 보고하는데 사용되는) 표준에러(standard error)는 콘솔로 인쇄한다. 표준 입력(Standard in)은 키보드와 관련된다. 이러한 연관성은 텍스트 기반의 콘솔을 가지지 않는 그래픽 운영 시스템에서는 약간 깨질 수 밖에 없지만, 표준파일 핸들은 콘솔을 사용하는 시스템이나 혹은 프로그램을 배우는 중이라면 믿을 수 없을 정도로 유용한 도구이다. 프로그램에 키보드 입력이 필요하면 입력을 표준입력에서 읽는다. 무언가를 인쇄하고 싶으면 그것을 표준출력에 인쇄한다.
그렇지만 항상 표준출력에 인쇄하기를 원하는 것은 아니다. 어떤 경우에는 파일이나 기타 다른 장치에 인쇄하고 싶을 수도 있다. 예전에 사용하던 print 명령어로는 표준출력을 별개의 함수 호출로 방향전환하거나 표준출력을 완전히 포기하고 쓰기 함수를 따로 사용해서 표준출력이 아닌 다른 장치에 출력할 수 밖에 없었다. 이와 같은 사용법은 혼란스러웠으며 어떤 사람들은 우아하지 못하다고 생각했다. 배리 바르소(Barry Warsaw)는 print 명령어가 출력을 더 쉽게 방향전환할 수 있도록 변경되어야 한다고 PEP 214에서 제안했다. 그는 텍스트를 파일로 또는 write 함수를 가진 파일류의 다른 어떤 객체로 출력하기를 원한다면 그 의도를 표시하기 위하여 print 구문에 특수한 표식설정자를 추가하자고 제안했다.
바르소(Warsaw)가 제안한 표식설정자인 >>는 그 논쟁의 초점이 되었다. 어떤 사람들은 그 표식설정자가 보기에 안 좋으며 너무 C++같은 느낌이 든다고 했다. 또 어떤 사람들은 "to"와 같은 예약어를 새로 하나 만드는 편이 더 좋겠다고 생각했다. "to"를 이전에 예약되지 않은 단어로 사용한 몇몇 코드들이 깨지게 된다 하더라도 말이다. 또 어떤 사람들은 새로 writeln() 함수를 만들어서 방향전환을 처리하는 편이 더 낫다고 했다. 다른 사람들의 생각은 어떤 경우라도 필요한 것은 아니며 우리는 그저 우리의 것을 고집해야만 했다. 그러나 디자인 팀이 바르소의 아이디어를 좋아했기 때문에 파이썬 2.0에 최상의 해결책으로 코딩해 넣었다. 이 외에도 여전히 의문을 품는 게시물들이 여럿 있었다. "도대체 개발팀은 귀를 열어 놓고 있는가?"라는 질문에 대한 뉴스그룹에서의 전반적인 반응은 CNRI 라이센스에 대한 반응보다도 더 나빴다. 아마도 그 이유가 과거 CNRI가 파이썬 공동체에 대하여 했던 어떤 것(† 역자 주: 라이센스 문제로 파이썬 공동체와 긴장감이 있었음) 때문이었으리라 생각하지만 이 >> 문제는 우리 친애하는 독재자님과 파이썬 개발 팀이 직접 행한 것이다.
항의의 물결에 대한 대답으로 귀도(Guido)는 처음으로 PEP 승인의 정당성을 게시하면서 "왜 이 제안이 최상의 해결책으로 받아 들여졌는가"에 대한 이유들을 자세히 설명하였다. 귀도는 게시물에서 그 PEP 프로세스로 구현되어 들어갈 생각의 종류를 보여준다. 그리고 일부 파이썬 열광자들의 불만에도 불구하고 그 PEP 프로세스가 잘 작동한다는 것을 보여준다. 귀도의 설명으로 불만의 목소리는 일부 가라 앉았다. 그리고 앞으로도 그 불만의 목소리는 서서히 줄어들 것이라고 예상한다. 여전히 PEP 214를 승인한 분별력에 대해 논쟁하고 싶은 마음이 있는 사람들도 있겠지만 이미 끝난 계약이다. 개발팀은 계속 작업중이다. 파이썬 2.0b1가 배포되면, print >>myfile, "Hello, my file!"와 같은 것들을 사용할 수 있을 것이다. 벌써부터 이것이 기다려진다. 결국 이 논쟁이 차츰 사그러들 즈음에는 어떤 논쟁들이 올라올까도 기다려진다.
comp.lang.python 뉴스그룹에서는 파이썬 개발팀을 비난하는 분노의 게시물들이 줄줄이 흘러 넘쳤다. 겉에 보이는 기능에 너무 치중했다(† 역자 주: creeping featurism, 최초의 우아한 디자인을 무시하고 순간순간의 제안에 따라 구현을 바꾸는 것), 기업계의 이익에 파이썬을 팔아 치웠다, 너무 빨리 앞으로 나아간다, 파이썬 공동체의 소리에 귀를 기울이지 않고 있다 등등… 무엇 때문에 이와 같은 비난이 한 순간에 터져나왔는가? 왜냐하면 파이썬 개발 팀이 print 서술문의 구문을 바꾸자는 제안 하나를 받아들였기 때문이다.
print 서술문은 파이썬의 직관적인 특징을 잘 나타내주는 것으로 얼마나 파이썬이 배우기 쉬운지를 잘 보여주는 예이다. 무엇인가를 화면에 인쇄하고자 한다면, print 명령어 뒤에 그냥 원하는 것을 놓기만 하면 된다. 여러 개를 인쇄하고자 한다면 각 항목들을 쉼표로 분리해주면 된다. 정말 명료하지 않은가? 게다가 이해하기도 쉽다. 안타까운 점은 print는 오직 표준출력 화면에만 더 정확히 말해 sys.stdout 파일 핸들에만 출력할 뿐이다. 여기에서 말하는 "표준 출력(Standard out)"이란 도스나 유닉스 프롬프트와 같이 텍스트 기반의 콘솔과 통신하는데 사용되는 세 개의 공통적인 시스템 파일 핸들중의 하나를 말한다. 표준출력과 (에러를 보고하는데 사용되는) 표준에러(standard error)는 콘솔로 인쇄한다. 표준 입력(Standard in)은 키보드와 관련된다. 이러한 연관성은 텍스트 기반의 콘솔을 가지지 않는 그래픽 운영 시스템에서는 약간 깨질 수 밖에 없지만, 표준파일 핸들은 콘솔을 사용하는 시스템이나 혹은 프로그램을 배우는 중이라면 믿을 수 없을 정도로 유용한 도구이다. 프로그램에 키보드 입력이 필요하면 입력을 표준입력에서 읽는다. 무언가를 인쇄하고 싶으면 그것을 표준출력에 인쇄한다.
그렇지만 항상 표준출력에 인쇄하기를 원하는 것은 아니다. 어떤 경우에는 파일이나 기타 다른 장치에 인쇄하고 싶을 수도 있다. 예전에 사용하던 print 명령어로는 표준출력을 별개의 함수 호출로 방향전환하거나 표준출력을 완전히 포기하고 쓰기 함수를 따로 사용해서 표준출력이 아닌 다른 장치에 출력할 수 밖에 없었다. 이와 같은 사용법은 혼란스러웠으며 어떤 사람들은 우아하지 못하다고 생각했다. 배리 바르소(Barry Warsaw)는 print 명령어가 출력을 더 쉽게 방향전환할 수 있도록 변경되어야 한다고 PEP 214에서 제안했다. 그는 텍스트를 파일로 또는 write 함수를 가진 파일류의 다른 어떤 객체로 출력하기를 원한다면 그 의도를 표시하기 위하여 print 구문에 특수한 표식설정자를 추가하자고 제안했다.
바르소(Warsaw)가 제안한 표식설정자인 >>는 그 논쟁의 초점이 되었다. 어떤 사람들은 그 표식설정자가 보기에 안 좋으며 너무 C++같은 느낌이 든다고 했다. 또 어떤 사람들은 "to"와 같은 예약어를 새로 하나 만드는 편이 더 좋겠다고 생각했다. "to"를 이전에 예약되지 않은 단어로 사용한 몇몇 코드들이 깨지게 된다 하더라도 말이다. 또 어떤 사람들은 새로 writeln() 함수를 만들어서 방향전환을 처리하는 편이 더 낫다고 했다. 다른 사람들의 생각은 어떤 경우라도 필요한 것은 아니며 우리는 그저 우리의 것을 고집해야만 했다. 그러나 디자인 팀이 바르소의 아이디어를 좋아했기 때문에 파이썬 2.0에 최상의 해결책으로 코딩해 넣었다. 이 외에도 여전히 의문을 품는 게시물들이 여럿 있었다. "도대체 개발팀은 귀를 열어 놓고 있는가?"라는 질문에 대한 뉴스그룹에서의 전반적인 반응은 CNRI 라이센스에 대한 반응보다도 더 나빴다. 아마도 그 이유가 과거 CNRI가 파이썬 공동체에 대하여 했던 어떤 것(† 역자 주: 라이센스 문제로 파이썬 공동체와 긴장감이 있었음) 때문이었으리라 생각하지만 이 >> 문제는 우리 친애하는 독재자님과 파이썬 개발 팀이 직접 행한 것이다.
항의의 물결에 대한 대답으로 귀도(Guido)는 처음으로 PEP 승인의 정당성을 게시하면서 "왜 이 제안이 최상의 해결책으로 받아 들여졌는가"에 대한 이유들을 자세히 설명하였다. 귀도는 게시물에서 그 PEP 프로세스로 구현되어 들어갈 생각의 종류를 보여준다. 그리고 일부 파이썬 열광자들의 불만에도 불구하고 그 PEP 프로세스가 잘 작동한다는 것을 보여준다. 귀도의 설명으로 불만의 목소리는 일부 가라 앉았다. 그리고 앞으로도 그 불만의 목소리는 서서히 줄어들 것이라고 예상한다. 여전히 PEP 214를 승인한 분별력에 대해 논쟁하고 싶은 마음이 있는 사람들도 있겠지만 이미 끝난 계약이다. 개발팀은 계속 작업중이다. 파이썬 2.0b1가 배포되면, print >>myfile, "Hello, my file!"와 같은 것들을 사용할 수 있을 것이다. 벌써부터 이것이 기다려진다. 결국 이 논쟁이 차츰 사그러들 즈음에는 어떤 논쟁들이 올라올까도 기다려진다.
TAG :
이전 글 : 이아스님이 전하는 자바 헤드라인
다음 글 : FreeBSD와 FreeBSD 듀얼 부팅하기
최신 콘텐츠