현재 위치

홈 ›› Forums ›› 재미 ›› 개발자 고민상담실

Perl 과 Python 차이점

choroot의 이미지
글쓴이: choroot / 작성시간: 금, 2011/12/02 - 8:00오전


MATLAB등을 돌려서 결과값이 TXT 파일로 나오면 필요한 숫자만 뽑아서 엑셀로 그려야하는데요.

그동안 Perl을 사용해 왔었는데, 자꾸 Python이 더 좋다는 이야기들이 있어서요.

가장 큰 차이점이 무엇일까요? Python을 시작할 수 있는 사이트나 책등을 소개해주시면 감사하겠습니다.

Forums: 
개발자 고민상담실
snowall의 이미지

글쓴이: snowall / 작성시간: 금, 2011/12/02 - 1:21오후

펄이나 파이썬이나 둘 다 좋죠. (개인적으로는, 저는 파이썬을 매우 싫어합니다. 쓰라고 해서 쓰는 것이지만.)

파이썬은 http://www.python.org 와 http://www.python.kr 에서 시작하시면 되겠네요.

매트랩 쓰셨으면 파이썬으로 갈아타시는 것도 나쁘지 않습니다.
matplotlib라는게 있어서, 매트랩에서 지원하는 기능들을 얼추 다 지원하고 있거든요

피할 수 있을때 즐겨라! http://melotopia.net/b

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 금, 2011/12/02 - 2:34오후

Perl 좋냐 Python이 좋냐? 는 짜장면이 좋냐 짬뽕이 좋냐? 라는 질문과 같습니다.
텍스트를 처리하고 그걸 엑셀로 그리는 작업을 Perl로 잘하고 있다면
굳이 다른언어로 바꾸실 필요가 있을까 싶네요.

뭘 잘하고 있는 사람에게 뭐가 더 좋으니 이걸 써봐라 어떠니 하는 사람은
나중에는 Python보다 Ruby가 좋네.. Ruby 보다 Node.js 가 좋네..
이럴 확률이 높습니다.

랭귀쥐는 목적이 아니라 수단일 뿐입니다.
Buzz와 Fanboyism에 휘둘리기 보다는
하고 있는 일이 잘되게 하는 Getting Things Done에 집중하시길 추천드립니다.

Tony의 이미지

글쓴이: Tony / 작성시간: 금, 2011/12/02 - 2:36오후

파이썬을 배우면 새 버전이 나올때마다 새로 공부할 수 있는 장점이 있습니다.

revival의 이미지

글쓴이: revival / 작성시간: 금, 2011/12/02 - 3:22오후

엄청난 장점이군요.

----
오늘도 행복한 하루~
@from caesar

keedi의 이미지

글쓴이: keedi / 작성시간: 금, 2011/12/02 - 9:41오후

Python에는 Advent Calendar가 없지만

Perl에는 Advent Calendar가 있다는 것이죠. :-)

----
use perl;

Keedi Kim

pogusm의 이미지

글쓴이: pogusm / 작성시간: 일, 2011/12/04 - 2:03오전

그런데 혹시요..
http://advent.perl.kr/2010/2010-12-02.html 를 보시면

Net::Google::Calendar 모듈을 이용해서
구글 캘린더를 통해 SMS 알림 서비스를 이용하는게 나오던데..

따라해보니까
구글 캘린더에 일정이 추가되기는 하던데, 알림이 등록되지는 않더라구요..

$entry->reminder('sms', 'minutes', 1); 라는 구문이 제대로 작동하지 않는거 같은데..

구글 API 버전이 3이고
Net::Google::Calendar 의 버전이 구글 API 1 또는 API 2에 맞춰 개발되어서 그런건가요?

혹시 아시면 좀 알려주세요~~

감사합니다.

keedi의 이미지

글쓴이: keedi / 작성시간: 월, 2011/12/05 - 1:42오전

작년 이후로 구글 서비스가 이것저것 바뀐 것들이 워낙 많아서;;;

저도 아직 확인 못해봤는데 월요일 출근하면 한번 들여다 봐야겠네요.
한번 디버깅 해보고 결과를 댓글로 남겨두겠습니다. ;-)

----
use perl;

Keedi Kim

ascendo의 이미지

글쓴이: ascendo / 작성시간: 금, 2011/12/02 - 3:48오후

parsing 이 편하다.. 입니다.

TXT 파일 핸들링이나

파일의 특정 부분을 추출해서 원하는 format으로 만들어 내기는 perl 만한 것이 없습니다.

awk 나 grep 을 이용할 수도 있지만

perl 을 이용한다면 좀 더 수월하고 우아하게 사용하실 수 있으실 껍니다.

snowall의 이미지

글쓴이: snowall / 작성시간: 금, 2011/12/02 - 11:38오후

100% 공감합니다.

예전에...

...펄 덕분에 어떤 업무의 처리 시간을 1000분의 1로 줄인적이 있었죠. 그런 일이었거든요.

피할 수 있을때 즐겨라! http://melotopia.net/b

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 수, 2011/12/14 - 11:58오전

문자열 처리에 있어 속도와 메모리 효율성 비교 벤치마크 입니다.

http://onlyjob.blogspot.com/2011/03/perl5-python-ruby-php-c-c-lua-tcl.html

Perl 이 C/C++ 보다 빠름. 메모리도 다른 스크립트 언어에 비해서 작게 쓰고..

Perl 속도가 1이면 (숫자가 작을수록 빠름)

C 1.23
C++ 3.89
Python 5.59
Ruby 5.21
PHP 3.84

kasworld의 이미지

글쓴이: kasworld / 작성시간: 금, 2011/12/02 - 6:46오후

100% 개인 취향 입니다.
둘다 충분히 성숙된 언어이고 필요한 거의 모든 라이브러리가 존재합니다.

이응준의 이미지

글쓴이: 이응준 / 작성시간: 토, 2011/12/03 - 12:43오전

파이썬이 배우기 쉽습니다.

근데 이미 펄에 익숙하시면 굳이 파이썬을 쓸 필요는 없을 것 같네요.

특히 하시는 일이 문자열을 다루는 작업이라면 펄이 낫습니다.

choroot의 이미지

글쓴이: choroot / 작성시간: 토, 2011/12/03 - 4:35오전

답변에 감사드립니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 토, 2011/12/03 - 11:12오전

파이썬도 정규표현식 모듈을 기본 포함하고 있는 스크립팅 가능한 언어이니
로그파일 파싱이라던지를 두고 펄만의 장점이라고 할 순 없고
루비도 파이썬과 마찬가지죠...

펄6 또한 하위 호환성을 포기하며 나온 것이니
파이썬3를 두고 버젼이 오를 때마다 새로 공부해야 한다는 얘기를 할 수 없으며

굳이 파이썬과 펄의 차이점을 얘기해야한다면
파이썬은 들여쓰기를 강제할 정도로 정형화(?)된 코딩스타일을 강조하는 한편
펄은 똑같은 기능도 여러 문법으로 지원할 정도로 다양한 작성법을 즐기는 언어죠.

때문에 파이썬은 코드 작성하는게 불편하다고 하는 사람이 있을 수 있고
펄은 남이 작성해 놓은 코드를 읽기 불편하다고 하는 사람이 있는 것입니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 토, 2011/12/03 - 12:51오후

>파이썬도 정규표현식 모듈을 기본 포함하고 있는 스크립팅 가능한 언어이니
>로그파일 파싱이라던지를 두고 펄만의 장점이라고 할 순 없고
>루비도 파이썬과 마찬가지죠...

정규식은 어떤 언어든 지원하지만 Perl이 정규식의 원조격인 언어이고 고루 써보셨다면
정규식사용과 문자열 처리의 편리성을 따졌을때 Perl이 장점이 없다고 말할 수는 없을듯 하네요.

>펄6 또한 하위 호환성을 포기하며 나온 것이니
>파이썬3를 두고 버젼이 오를 때마다 새로 공부해야 한다는 얘기를 할 수 없으며

위에서 말하는 버젼 문제점은
Perl 6, Perl5.*
Python 2.*, Python 3.*
같은 앞자리가 바뀌는 major 버젼 업그레이드가 아닌 소숫점 이하의 minor 버젼 업그레이드시 문제를 말하는 것 같네요.
Perl,Python,Ruby를 다 써본 입장에서 평하자면.

* minor버젼 업그레이드시 문법의 하위호환성 보장정도
Perl: A
Python: B 2.6 2.7같은 중간 버젼 업그레이드시 문법이 바뀌는 경우가 있음
Ruby: C 1.8.1 1.8.2 같은 최소버젼 업그레이드에서도 문법이 호환안되는 경우가 생김

* minor버젼 업그레이드시 모듈들의 하위보장성 및 엄밀한 테스트 정도
Perl: A 특정 모듈의 버젼별 언어버젼별 OS별 자동테스트 리포트 및 통계예 http://www.cpantesters.org/distro/M/Moose.html
Python: B 어떤 모듈들은 2.6.* 에서만 동작한다는 식으로 못박는 경우(Twisted는 아직 2.7에 100% compatible하지 못함)
Ruby: C Rails같은건 만들어 놓으면 몇달지서 언어나 모듈 업데이트하면 안돌아가는 경우가 허다함

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/12/04 - 12:43오후

펄이 마이너 업그레이드시 별문제가 없다면...
배포판에 기본 포함되는 펄들은 왜 버젼이 잘 올라가지 않는걸까요? ^^

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/12/04 - 1:25오후

우분투는 비교적 잘 따라 올라가죠 rhel같은 경우 모든 패키지 업그레이드가 보수적이라 언어의 하위 호환성이랑은 별개문제고..

keedi의 이미지

글쓴이: keedi / 작성시간: 월, 2011/12/05 - 2:36오전

아무래도 그것은 안정성에 대한 부분이라고 생각합니다.
확실한 것은 펄은 마이너 버전에 대해서는 명시적으로 호환을 보장합니다.
지금은 5.X.Y 에서 마이너는 X에 해당하는 부분이겠죠.
실제로는 X가 Perl 5버전을 사용하는 사람 입장에서는 실질적인 메이저 버전입니다.

다만, 새로운 버전에서 업그레이드를 한다는 것은 내부적으로
리팩터링이 진행되거나 새로운 기능이 추가되는데,
그 과정에서 테스트 슈트를 모두 통과하고 릴리스를 하겠지만,
side effect로 이전에 없었던 버그가 발생할 수 도 있기 때문에
보수적으로 접근하는 것이라고 생각합니다.

개인적으로는 오픈소스 만큼은 최신 버전이 무조건 제일 좋다고 생각해요.
다만, 이전 버전과 비교했을 때 분명히 side effect가
발생할 수 있다는 것을 인지해야 할테구요.
(세상에 완벽한 것은 없잖아요? :)

최신 버전으로 갈아탈 때 얻을 수 있는 이득과,
기존 버전의 유지할 때 얻을 수 있는 이득을 고려해서
원하는 버전을 선택하는 것이 적절할 것 같습니다.

펄의 경우 컴파일 및 설치가 워낙 손쉬워서,
그런데 그마저도 perlbrew로 한줄 설치가 가능해서
펄을 쓰는 대부분의 사람들(저희 회사도 그렇구요)은
시스템 펄은 그대로 두고 개인 계정에 펄을 설치해서 사용하고 있습니다.

http://www.perlbrew.pl/

----
use perl;

Keedi Kim

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 1:59오후

Quote:
최신 버전으로 갈아탈 때 얻을 수 있는 이득과,
기존 버전의 유지할 때 얻을 수 있는 이득을 고려해서
원하는 버전을 선택하는 것이 적절할 것 같습니다.

Quote:
펄을 쓰는 대부분의 사람들(저희 회사도 그렇구요)은
시스템 펄은 그대로 두고 개인 계정에 펄을 설치해서 사용하고 있습니다.

왜 이런 이야기를 파이썬에는 적용해보지 못하는지... 재밌습니다.
keedi님께서는 그런 주장은 하지 않는듯 생각됩니다만...
파이썬을 버젼별로 깔아야 된다느니 하는 얘기가 있어서 말이죠.

keedi의 이미지

글쓴이: keedi / 작성시간: 월, 2011/12/05 - 9:49오후

펄을 최신 버전으로 쓸때 얻을 수 있는(제가 판단한) 이득은 다음과 같습니다.

- 항상 최신 및 edge의 기술을 평상시에 받아들임으로써 내부 코드를 최대한 모던하게 유지
- 개인의 역량 강화
- 각종 버그 패치

펄을 최신 버전을 사용할 때 잃는(제가 판단한) 이득은 다음과 같습니다.

- 사이드 이펙트로 인한 버그

정리하면 적어도(제가 5.6을 써보기엔 너무 젊군요. :) 5.8대 이후 버전의 펄에서
버전 변화로 인해 개발용 코드를 수정하거나 기존 모듈이 동작하지 않는 일은
아직까지는 겪어보지 못했습니다. 물론 들어보지도 못했구요.

혹시라도 그런 일이 있다면, 그것은 perlbug로 신고감이라고 할 수 있겠죠?
아마도 perl porters들은 최선을 다해 다음번 릴리스때 해당 문제를
해결해 주겠지요(왔지요).
현재 발생하고 있는 사이드 이펙트로 인한 버그도 신고만 한다면
엄청나게 난해한 문제가 아닌 이상 대부분 다음 릴리스때 해결되 되곤합니다.

저희가 자체 펄을 컴파일해서 사용하는 이유는 단지,
개발자 개개인의 역량 강화 및 외부 변화에 적극적으로 대처하는
개발팀을 꾸리기 위해서일 뿐입니다. :-)

파이썬에도 당연히 적용될 수 있는 이야기겠지요.
다만 이야기의 주제는 버전 변화로 인해 하위 호환성이
깨어지는 문제가 주제였던 것 같은데,
제가 파이썬은 잘 모르기 때문에 스킵하지만,
어쨌거나 펄은 하위 호환성을 지키는데는
매우 적극적으로 대응하고 있습니다.

어쩌면 그래서 그 틀을 벗어나기 위해 Perl 6가 나오는 것이겠지요.
사실 같은 Perl이라고도 할 수 있겠지만, 내부적으로
Perl 5와 Perl 6는 서로 완전히 다른 언어라고 인식하고 있는 듯합니다.
정리하면 Perl 6의 여부와는 별개로 Perl 5(현재 우리가 펄이라고 부르고 있는)는
계속 하위호환성을 유지하면서 발전해 나갈것입니다.

----
use perl;

Keedi Kim

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 화, 2011/12/06 - 12:01오전

Perl에서 MS Excel 파일을 다루는데 있어 최고의 모듈인
Excel::Writer::XLSX( https://metacpan.org/module/Excel::Writer::XLSX )모듈이
Perl 5.10 에서 도입된 편리한 // 연산자를 쓰기 위해 5.10 미만 버젼들에 대해서 지원을 포기했는데
여러 기업등 모듈 사용자들에게서 레거시한 시스템들의 Perl 5.8 환경에서도 계속 돌아가게
해달라는 요청을 받고 개발의 편리성을 포기하면서 까지 //을 다시 버리고 5.8버젼을 지원하도록 바꿨죠

http://blogs.perl.org/users/john_mcnamara/2011/12/goodbye-ill-miss-you.html

이 스레드 원래 질문하신 분도 Excel::Writer::XLSX 모듈 쓰시면 자료에서 수치뽑고
엑셀 열어서 데이터 파일열고 손으로 차트 그리실 필요 없이 엑셀을 열지 안고도
챠트까지 그려진 엑셀파일을 생성가능하실겁니다.

keedi의 이미지

글쓴이: keedi / 작성시간: 화, 2011/12/06 - 2:55오후

다른건 몰라도 Excel::Writer::XLSX 모듈은 정말 *갑*이긴 하지요. :-)

----
use perl;

Keedi Kim

clique의 이미지

글쓴이: clique / 작성시간: 토, 2011/12/03 - 4:11오후

perl python ruby 등은 전적으로 취향입니다만(셋 다 성숙한 스크립팅 언어죠),
python이 말씀하신 matlab, SciPy등과의 연동에서 편리하기 때문에 이과쪽에서 인기가 많은 것 같더군요.(물리라든가...)

keedi의 이미지

글쓴이: keedi / 작성시간: 토, 2011/12/03 - 4:27오후

개인의 존중을 취향해야죠...(...응?)

perl, python, ruby 모두 성숙한 스크립트 언어라는데,
그리고 취향 문제라는데 전적으로 동의합니다.

셋 중 어느 하나라도 evil이라면 이렇게 전세계 적으로 쓰일리가 없겠죠.
각 언어마다 스타일이 있는 만큼 자신의 스타일과 맞냐가 중요하지
이것이 더 좋고, 저것이 더 나쁘다란 것은 다 부질없지요.

원 글쓴이께서는 파이썬에 마음이 기우신 것 같으니 파이썬을 공부하시는 것을 추천드립니다. ;-)

P.S.
얼마전 학교에 동아리 홈커밍데이로 갔는데 생명정보학과 1학년 학생이 파이썬을 배운다더군요.
교수님께서 파이썬이 펄보다 더 좋다고 하셨다고... ㅎㅎ
교수님의 취향은 존중하지만, 교수님의 취향을 학생에게 강요하는 것은 참 불편하더군요.
펄 조낸 구려~ 라고 하시는 분 중에 펄을 제대로 써보거나, 공부해보신 분은 아직 본 적이 없네요.

그래서 요즘은 이런 이야기 들으면, 그냥 웃지요. :-)

P.S.
펄로 hello world 겨우 찍는 사람이,
루비를 한다고 루비온레일즈 웹앱을 뚝딱 만드는건 아니겠지요. :-)

----
use perl;

Keedi Kim

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 토, 2011/12/03 - 4:46오후

Perl에도 Matlab 보다 더 빠른( http://www.freesoftwaremagazine.com/articles/cool_fractals_with_perl_pdl_a_benchmark )
PDL( http://pdl.perl.org/ ) 이란게 있습니다.
그리고 다른 수치계산 모듈도 이미 CPAN에 아주 많습니다.
https://metacpan.org/search?q=Math
Excel과의 연동 모듈도 많고~
https://metacpan.org/search?q=excel

sblade의 이미지

글쓴이: sblade / 작성시간: 토, 2011/12/03 - 4:46오후

python 은 1년이 지난 후 코드를 다시 보면 바로 이해할 수 있고
perl 은 약간 머리를 싸매야 합니다.
그래도 regex 및 string 처리는, python 에도 있을건 다 있지만, 뭔가 perl 이 좀 더 편하더군요.

그리고 숫자를 그리는데 matlab 을 안쓰시는 이유라도?

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 토, 2011/12/03 - 4:57오후

>python 은 1년이 지난 후 코드를 다시 보면 바로 이해할 수 있고
>perl 은 약간 머리를 싸매야 합니다.

이런걸 FUD라고 하죠... 그냥 주위에서 그러니 그렇다더라~

예로 구글켈린터를 이용해서 문자메시지를 보내는 Python, Perl 스크립트

Python - http://wikidocs.net/read/683
Perl - http://advent.perl.kr/2010/2010-12-02.html

을 비교해보시길... 뭐가 더 가독성좋고 간결한지...

sblade의 이미지

글쓴이: sblade / 작성시간: 토, 2011/12/03 - 5:35오후

일단 가독성 때문에 python 이 perl 보다 근본적으로 우월하다는 소리는 아니었습니다. 그렇게 읽힐 수도 있겠네요. 하지만 perl 의 강점이 가독성은 아니라 봅니다. 문법에 특수목적 construct 들도 상당히 많고 (다른 언어라면 library 로 떼어놨을만한), 기호도 많이 쓰고, data-structure 들도 기호구요. 익숙하면 괜찮지만 다른 사람의 코드를 읽을 땐 제 경운 좀 어렵더군요.

그런데 두 코드는 기능상 같지가 않군요. 이 둘로 비교가 무슨 의미가 있는지는 잘 모르겠습니다. 간결함이 가독성을 의미하지도 않구요. 오히려 가독성을 위해서는 어느 정도는 영어 문장처럼 읽힐 수 있도록 약간의 verbosity 가 필요한 듯 합니다.

keedi의 이미지

글쓴이: keedi / 작성시간: 토, 2011/12/03 - 6:23오후

나쁜 의도로 드리는 쓰는 답글이 아니니 편하게 읽어주세요. :)

전 1년 지난 제 Perl 코드도 너무 잘 읽히더라구요.
가독성은 언어의 문제가 아니라 개개인의 훈련 또는 역량 문제라고 생각합니다. :-)
그래서 항상 제가 가르치게(도와주게) 되는 사람들에게는
그것이 C든 Perl이든 항상 코딩 스타일을 익히게 하는데 큰 공을 들입니다.

오늘이 2011년 12월 3일이니까 정말 정확하게 1년 지난 제 perl 코드입니다.

http://advent.perl.kr/2010/2010-12-03.html

코드가 이해되지 않는 것은 문법(syntax) 문제가 아니라 흐름(logic) 문제라고 생각합니다.
혹시라도 문법이 문제라면 그것은 문법이 아직 익숙해지지 않았다는 방증이겠죠.

전 영어 문법은 잘 알지만, 읽기는 너무 힘들어요.
영어의 문법이 이상해서 가독성이 나쁘다고 할 수는 없겠지요.

----
use perl;

Keedi Kim

clique의 이미지

글쓴이: clique / 작성시간: 토, 2011/12/03 - 6:24오후

''개인적''으론 python이 perl에 비해서 제약된 들여쓰기 때문에 가독성이 좀 더 낫다고 생각합니다.
perl은 표현력이 너무 좋은 게 오히려 마이너스가 되지 않나 싶을 정도고요.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 토, 2011/12/03 - 6:54오후

과 영어단어같은 Verbose함이 가독성을 높혀준다고 생각하면
http://www.slideshare.net/xSawyer/perl-dancer-for-python-programmers
이 자료를 추천....

Python의 엄격함? 덕에 쓸 때 주의해야 할 것들은
http://kfsone.wordpress.com/2010/11/30/take-that-python/
http://bitcheese.net/wiki/nopython
http://luisartola.com/software/2010/python-flaws-scope-and-shadows/
http://stackoverflow.com/questions/371966/are-there-any-good-reasons-why-i-should-not-use-python
을 추천...

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/12/04 - 2:46오전

C, 자바 등의 소스를 작성하면서 다들 들여쓰기를 합니다.
남들이 써놓은 들여쓰기 규칙이 맘이 들지 않으면 indent 툴로 들여쓰기를 바꿀할 수 있습니다.
펄로 들여쓰기를 제대로 해서 소스를 작성했을 때, 또는 들여쓰기 자동화 툴을 돌렸을 때,
가독성 면에서 파이썬과 어떤 차이가 있을까요?
즉, 들여쓰기는 어느 언어나 다 합니다. 들여쓰기 강제한다고 해서 그것 때문에 가독성이 좋아진다고 보기가 어렵습니다.
개인적으로는 파이썬 코드를 알아먹기가 자바 코드보다 어렵더군요.
파이썬 문법 자체가 문제가 있다고 생각합니다.

1. 객체 생성(생성자 호출), 함수 호출 헷갈림. 명시적 new 없기 때문. 이름붙이기(naming) 규약이 허술

2. }, end 없어서 중첩 if의 경우 헷갈림. 이래서 들여쓰기를 강제할 수 밖에 없음. 프로그래머가 적절한 곳에서 줄바꿈 해주면 이해하기 수월할텐데 줄바꿈 안 하고 주욱 늘어놓으면 정말 헷갈림.

3. 첫번째 함수 인자로 self 가 들어가는 점. 실제 함수를 호출할 때 인자로 self 를 써주지 않음.

참 모순적인 문법이라 할 수 있습니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/12/04 - 12:41오후

실제 함수를 호출할때 인자로 self를 써줍니다.
그 위치가 괄호안이 아니라 함수앞에 온다는게 다른 인자와의 차이점이지만 ^^
(이게 더 가독성이 높으니까요...)

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/12/04 - 3:52오후

음.. 제가 하고자 하는 이야기는...
http://docs.python.org/tutorial/classes.html 여기 보시면...

class MyClass:
    """A simple example class"""
    i = 12345
    def f(self):
        return 'hello world'

함수 f 호출
x = MyClass() # 생성자 호출, 함수 이름도 대문자 시작할 수 있으므로 함수 호출인지 생성자 호출인지 명확하지 않음.
x.f() # 함수(메소드) 호출, 인자 self 넣지 않고 호출. # 일관성이라고 해야할까 직교성이라고 해야할까 아무튼 모순적임.

입니다.
제 개인적인 생각입니다.
익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/12/04 - 3:59오후

생성자도 함수입니다.
인스턴스를 리턴하는 함수죠. ^^

그리고 self의 인자를 넣고 호출하는 것이라고 위 댓글에서 얘기했습니다만...
단지 self의 경우는 다른 인자와 달리 f(x)라고 하는 것보다는 x.f()라고 하는 것이 더 가독성이 좋지 않습니까? ^^

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/12/04 - 4:30오후

아무래도 C++이나 자바의 그것과 달라서 그런 생각을 가지는 듯한데...
C++이 오히려 이상한게 아닐까요?

class foo {
   int a;
public:
   int get_a() const { return a; }
   ...
};

같은 코드가 있다고 할때 const는 대체 뭐가 const라는 얘기일까요?

this포인터가 const라는 얘깁니다.
만약 C++도 파이썬의 self처럼 꼬박꼬박 this를 쓰게 해 두었다면
저렇게 뒤에 쓰지 않고 그 인자 자리에 const를 붙혔겠죠?

int get_a(const foo *this) { return this->a; }
익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 토, 2011/12/03 - 9:49오후

파이썬과 펄의 차이점을 얘기한다면...

문법적인 특징은 위에서 언급된듯하므로 구현의 부분을 살펴보면
펄은 파이썬에 비해 REPL이 완전하지 못한 느낌입니다.
한문장짜리는 펄 디버거같은 걸로도 REPL같은 느낌을 낼 수 있지만
for문 같은걸 실행해 보려면 슬슬 짜증이 밀려옵니다.

또 다른 점은..
파이썬은 깔끔하게 바이트코드화 되는 반면
펄은 그렇지 못합니다.
캐쉬등의 이유로 컴파일된 코드를 사용하는 경우도 있으나
모든 펄코드가 가능한게 아니라고 합니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 토, 2011/12/03 - 11:11오후

>펄은 파이썬에 비해 REPL이 완전하지 못한 느낌입니다.
>한문장짜리는 펄 디버거같은 걸로도 REPL같은 느낌을 낼 수 있지만
>for문 같은걸 실행해 보려면 슬슬 짜증이 밀려옵니다.

Perl에서 간단한 REPL은 perl 디버그 모드

$ perl -de 0

로 가능하죠. 그리고 좀 불편하나마 여러라인을 넣고 테스트하려면
$ perl 엔터
foreach (0..10) {
        print $_,"\n";
}
CTRL+D 누르고 엔터

식으로 할수 있습니다.

for문 같은걸 실행해 보려면 애로가 있다는건
Perl은 Python이나 Ruby와는 다르게 my 로 정의하는 엄밀한(explicit) lexical변수가 존재하기 때문에
REPL에서 { }내의 렉시컬영역 처리 때문입니다.

완벽한 REPL을 원한다면 별도의 모듈을 사용하면 됩니다.
참고:
https://metacpan.org/release/Devel-REPL
http://saillinux.egloos.com/1765103

>또 다른 점은..
>파이썬은 깔끔하게 바이트코드화 되는 반면
>펄은 그렇지 못합니다.

Perl에서도 과거 Python의 pyc처럼 바이너리컴파일된 형태를 지원하려고 했으나
구현에 들이는 공수등에 비해 거기에서 얻어지는 속도향상(초기 로딩에 있어 약간의 속도향상)
,소스숨기기(해봐야 구조상 쉽게 decompile됨)등 잇점이 크지않다고
의견이 모여 하지않기로 되었습니다.

그리고 요즘 pyc 파일에 악성코드를 집어넣는
방법이 발명되어 보안상으로도 위협요소가 되고 있기도 합니다.
http://securityrealwebblog.blogspot.com/2011/10/this-python-has-venom.html
https://github.com/jgeralnik/Pytroj

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/12/04 - 12:17오후

그럼 펄6의 패롯은 잘못된 것일까요? ^^
펄을 사랑하는 마음은 알겠지만...
중간코드를 생성한다는걸 까는건 이해하기 어렵군요.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/12/04 - 1:27오후

python만을 위한 중간코드와 언어중립적인 패롯의 중간코드와는 비교가 적절하지 못한듯 하네요

loias의 이미지

글쓴이: loias / 작성시간: 일, 2011/12/04 - 9:03오전

진짜 중요한 가독성관련문제는

문제는 남이 짠코드를 자기가 쉽게 읽을 수 있느냐 입니다..

파이썬은 이게 강제적이라서, 남이 짜 놓은 코드를 그냥 훑어보면 어떤식으로 구조가 잡혀있는지, 보입니다.

이게 가장 큰 장점중 하나라고 보는데요,,

펄보다 파이썬이 전파속도가 빠른게 이부분도 상당히 많이 기여를 했다고봅니다

자기 생각을 남이 쉽게 공유한다는것

이게 펄보다 파이썬이 훨씬 빠른거 같습니다.

이게 모냐하면 고수들의 비기를 쉽게 익힐 수 있다는 장점이 있는거죠,

물론 어느정도 형식을 맞추어서 같은 형태로 암묵적으로 동의하고 펄을 쓰면 똑같은데,
사람이 바뀌면 다르더라고요,,

저는 둘다 씁니다.

펄은 커맨드라인같은데서 one liner로 쓰면 참좋더라고요,,
파이썬은 그냥 좋고요,,

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/12/04 - 11:07오전

파이썬의 강제적 문법, 어떤일에는 한가지 방법...같은 모토는
Perl이 너무 방법이 많고 자유로와서 읽기어려운 코드를 쓸 수 밖에 없다는 뜬소문과 마찬가지로
역시 그냥 그렇다니까 그렇다더라하는 점도 많습니다.

일례로 python에서 리스트를 카피하는 방법만 쳐도
참고: http://news.ycombinator.com/item?id=3201033

    b = a[:]
    b = list(a)
    b = copy(a)
    b = deepcopy(a)

이렇게 여러가지죠... 위 링크에서 제일 웃겼던건

a[:] feels a bit too much like Perl.

라는 얘기에

The irony being that in Perl, a list copy looks like this:

@dest = @src

라는 대답...
이것만 봐도 사람들은
뭐가 어떻더라 말하면서도 진짜 어떤지도 모르고 말하는 경우가 많다는 걸 알 수 있죠.

보너스로 다음은 엄격함?을 무시한 아름다운 Python코드예 입니다.
http://preshing.com/20110822/penrose-tiling-in-obfuscated-python

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/12/04 - 12:22오후

a[:]가 펄처럼 느껴지는건...
단어가 아니라 기호를 사용하기 때문은 아닐런지요? ^^

위 4가지 예시중에 3가지는 단어로 되어 있는데
펄같다고 얘기하는 문장은 유일하게 [:]라는 기호를 사용하고 있죠.
펄에서 @이라는 기호를 사용하는 것처럼 말이죠...

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/12/04 - 1:31오후

그러면 ( ) [ ]는 기호 아닌가요? @는 파이선에서도 힘수노테이션에쓰고 루비에서도 클래스 맴버변수에 쓰이죠 기호쓰는거 가지고 너무 확대해석 하시는듯

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 2:32오후

파이썬의 "There is only good one way to do it"에도 어긋나고

오히려 펄의 @dest = @src가 더 직관적이라고 말한 답을 보면,
@이라는 기호를 쓴게 가독성에 영향을 주지 않았다는 것을 알 수 있죠.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 2:56오후

shallow copy와 deep copy 두가지 copy가 있는 것을 두고
"There is only good one way to do it"에 어긋난다고 하는 것은 개그가 아닐지? ^^

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 3:22오후

What's the best way to interleave two Python lists?
http://blog.jarrodmillman.com/2010/10/whats-best-way-to-interleave-two-python.html
7가지가 넘는 방법
one way. really?

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 일, 2011/12/04 - 4:00오후

http://docs.python.org/tutorial/index.html

파이썬이 좀 거시기한 면이 있긴 한데 파이썬이 펄,루비보다 널리 쓰이니 파이썬 배워서 손해볼 것은 없습니다.
파이썬 하다가 취향이 아니다 싶으면 다른 동적 언어로 갈아타시면 됩니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 11:32오전

파이썬은 "한국에서" 널리 쓰이고 있죠.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 12:04오후

"한국에서" 널리 쓰인다는 FUD는 어떻게 해서 나온걸까요? ^^

PySIDE, PyGTK같은 것만 봐도...
루비나 펄보다 파이썬을 더 널리 쓰는구나 하는 느낌을 받습니다만...

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 2:28오후

굳이 그렇게 봐야 파이썬이 좀 널리 쓰인다고 느낌받나요?
개인적으로 그렇게 느낀다면 뭐라 않겠습니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 2:46오후

통계자료를 참고해 주세요.
아래 자료 보시면 파이썬이 펄,루비보다 널리 사용되고 있음을 알 수 있습니다.

http://lang-index.sourceforge.net/

Results: December 2011 update

Language category:
any *)

Rank Name Share
1 Java 18.652%
2 C 17.719%
3 Objective-C 9.719%
4 C++ 6.400%
5 PHP 6.179%
6 Basic 5.567%
7 Python 3.804%
8 Perl 3.766%
9 C# 3.470%
10 JavaScript 2.225%
11 Ruby 1.652%

Language category:
script *)

Rank Name Share
1 PHP 24.521%
2 Python 15.097%
3 Perl 14.944%
4 JavaScript 8.829%
5 Ruby 6.556%

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 3:06오후

느낌으로 따지면
요즘 Perl , Python, Ruby 니 다 Javascript가 쓰이는 만큼 쓰이지도 못한거 같은데
코에걸면 코걸이 귀에걸면 귀걸이인 자료들 들먹이며
니가 잘났니 내가 잘났니 싸울 필요까진 없을듯요..

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 3:58오후

"파이썬은 "한국에서" 널리 쓰이고 있죠"라는 잘못된 주장에 대한 반박 자료일 뿐입니다.
이 스레드의 제목이 Perl과 Python의 차이점이니 자바스크립트까지 나올 필요는 없는것 같습니다.

프로그래머가 어떤 언어를 많이 사용하는가? 어떤 언어로 만들어진 프로그램이 많이 사용되는가? 에 대해서는 이 스레드에서 논할 필요가 없습니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 3:47오후

미국 언어별 Job 통계

http://www.indeed.com/jobtrends?q=perl%2Cpython%2Cruby%2Cphp&l=

미국 언어별 연봉통계
http://www.jiansnet.com/topic/24694/Top-IT-Skills-and-Salaries-In-2011

Perl          $94,210
Python        $90,208
Ruby on Rails $89,973
 
--Java: 90k ~ $100k
--C/C++: $90k
--C# $85k

cleansugar의 이미지

글쓴이: cleansugar / 작성시간: 금, 2011/12/09 - 9:00오전

유용한 사이트네요.

재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.

아이디의 아이디어 무한도전
http://blog.aaidee.com

귀태닷컴
http://www.gwitae.com

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 2:52오후

PySIDE는 QT 제작사에서 직접 만들었고
PyGTK는 gnome을 깔면 기본으로 깔리고 있는데...
뭘 또 예로 들어야 될까요? ^^

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 금, 2011/12/09 - 11:52오전

개인적으로 python이 perl보다 GUI 어플 만들기 더 좋다고 생각하고 있습니다.

그러나 gtk는 다양한 언어 바인딩을 제공하기 위해 C로 만들어졌습니다.
그러니 perl, python, ruby, c++ 등 넘치도록 지원하고 있죠.
이건 python과 perl의 차이점도 아니고 python의 장점도 아닙니다.

예를 잘못 드신 것 같네요.

keedi의 이미지

글쓴이: keedi / 작성시간: 월, 2011/12/05 - 9:35오후

음 PyGTK가 있다는 것 자체로는 펄이나 루비보다
파이썬이 더 널리쓰이는 이유라고 들기 어려울 것 같습니다.

GTK는 C로 만들어진데다가, GObject 시스템 덕분에
다른 언어로의 바인딩이 상대적으로 쉬워서
대중적인 언어 중에 GTK 바인딩이 없는 언어를 찾기가
더 어려울 거라고 생각합니다.

PySide가 뭔가해서 찾아보니 Python for QT인 것 같은데,
마찬가지로 펄도 CPAN에 Qt 모듈이 있습니다.

파이썬이나 루비도 마찬가지겠지만
당연히 WxWidget 및 SDL 바인딩도 역시 있습니다.
모두 CPAN에서 관리 및 릴리스 되고 있구요.

다른 의도가 있다기 보다는 말씀하신 'PySIDE, PyGTK같은 것만 봐도...'는
대부분의 메이저 언어에도 바인딩이 있기 때문에 별로 설득력이 없어보입니다. :)

----
use perl;

Keedi Kim

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2011/12/08 - 8:23오후

"파이썬 바인딩만 있다."라고 한적도 없는데 왜 이런 얘기를 꺼내는지
이것에 대한 반론을 싸봐야 같은말 반복이라서 말았는데
달아드려야 할 것 같군요.

"한국에서" 널리 쓰인다는 얘기를 꺼냈기에 그 반론으로
PySide와 PyGTK가 나왔습니다.
그 어디에도 qt와 gtk의 바인딩은 파이썬만 있다고 한 적이 없죠.

PySide는 QT제작사에서 직접 만든 바인딩이고...
PyGTK는 python으로 제작된 프론트엔드가 상당수 있고
그래서 gnome을 깔면 의존성때문에라도 그냥 기본으로 깔립니다.

이런것만 봐도 파이썬은 "한국에서" 널리 쓰이고 있다는건 말이 안되죠.
("한국에서"라는 단어를 따옴표로 쳐가며 집어넣는건 어불성설이란 말입니다.)

pung96의 이미지

글쓴이: pung96 / 작성시간: 목, 2011/12/08 - 11:48오후

"PySIDE, PyGTK같은 것만 봐도...
루비나 펄보다 파이썬을 더 널리 쓰는구나 하는 느낌을 받습니다만..."

라고 하셨는데요.

조금더 추가하자면,
"펄이 XXX 모듈만 봐도 펄이 얼마나 파이썬이나 루비보다 훌륭한가 하는 느낌을 받습니다만."
이라고 말하면 아마도 이런 답글이 달리겠죠.

"파이썬도 XXX할수 있는 YYY 모듈이 있는데요"

그럼 전 이렇게 말할꺼구요.
"XXX 가 YYY 보다 이런 점이 더 좋습니다."

하지만 이렇게 말하지는 않죠
"파이썬으로 못한다고 하지 않았어요, 왜이러삼"

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2011/12/08 - 11:54오후

왜이러삼!!

"더 널리 쓰인다"고 했지 이런점이 더 뛰어나다느니까지 얘기하진 않았죠.

프론트앤드쪽에서 많이 쓴다는 건 펄을 지지하는 다른 익명도 지지할 정도아닙니까? ^^
그러니 예를 잘든거죠.

한국에서만 많이 쓰이는게 아니라 한국외에도 널리 쓰이는 예를 보인거 아닙니까.

pung96의 이미지

글쓴이: pung96 / 작성시간: 금, 2011/12/09 - 2:34오전

keedi님과의 글에대해서 얘기하는거죠.
다른 익명들끼리의 얘기에 대해서는 별로 관여하고 싶지 않습니다.
다만 keedi님은 드러나있는 분일 뿐더러 잘 아는 분이라 오해받는 걸 가만히 보기 힘들어서 하는 얘깁니다.

제 얘기를 잘못 이해하신거 같은데
1. 자세한 설명없는 짧은 글은 ( 비난이 아닙니다 저도 그렇게 쓰니까요 )
2. 자세한 설명이 없기 때문에 다양한 종류의 반박을 얻을 수 밖에 없고
3. 자신의 주장을 옹호하고 싶으면 그냥 다양한 종류의 반박에 대해 자신의 의견을 얘기하면 되는 겁니다.

당연히 원본이 짧은 글이기 때문에 "저는 AAA라고 말 안했습니다." 라고 말하려고 해도 사실 말한게 별로 없죠.
이게 자연스러운 과정이라는 겁니다.

님의 경우에는
"PySIDE, PyGTK같은 것만 봐도...
루비나 펄보다 파이썬을 더 널리 쓰는구나 하는 느낌을 받습니다만..."
라고 말씀하셨고,

이에 대해서는 펄도 GTK와 QT에 대해서 훌륭한 바인딩을 가지고 있다 라고 반박하는 것은 당연한 수순입니다.
이에 대해 님은 후에 말씀하신것 처럼 "나도 그건 안다.(혹은 미처 몰랐다) 하지만 파이썬의 경우에는 QT측에서 직접만든 것이 있고, GTK의 경우에는 GNOME과 함께 기본으로 설치되는 바인딩을 가지고 있기 때문에 내 주장은 여전히 유효하다"
라고 하실수 있구요. 훌륭한 전개입니다 짝짝짝.
그럼 또 반박하는 측은 "그건 그쪽 취향에 따른 특수한 경우이다" 라거나 "perl의 경우는 CPAN에서 관리 되기 때문에 상황이 다르다" 등등의 많은 얘기를 또 할수 있겠죠.

이게 바로 정상적인 상호 논리 전개의 과정이고 본인들이나 많은 사람들에게 도움이 되는 방법이 아니겠습니까?

keedi 님께서 "님께서 파이썬만 바인딩을 가지고 있다고 주장하시는데" 같이 말하지 않았는데 ""파이썬 바인딩만 있다."라고 한적도 없는데 왜 이런 얘기를 꺼내는지" 라고 말하는게 이상한거죠.

게다가 keedi님께서는 "프론트앤드만" 이라거나 "한국에서만" 에대해 말씀하신 적도 없고 동의하신 적도 없는데, 왜 싸잡아서 비난하시는지 모르겠습니다.
모든 펄러와 파이썬 유저를 양분하시고 같은 편으로 보시는 것 같습니다.

제생각엔 다른 분들과의 의견을 나누는 과정에서 약간 흥분하신 것 같습니다. 충분히 이해할 수 있고, 저도 그럴 수 있죠. keedi님에 대한 답글도 그런 차원에서 이해할 수 있구요.
진정 하시기 바랍니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 2:06오후

프로그램 언어 순위를 보면 파이썬이 펄,루비보다 널리 쓰이고 있습니다.
또한 리눅스쪽에 프론트 엔드는 펄,루비보다 파이썬이 장악하고 있죠.
굳이 "한국"이라고 한정지을 필요는 없는 것 같습니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 2:25오후

프론트앤드라고 한정지어야 하는군요.
공백문자가 토큰으로 쓰이는 언어로 한정지어도 1위일 듯하네요.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 2:32오후

파이썬이 펄,루비보다 더 널리 사용되는가에 대한 논쟁은 불필요합니다.
아래 통계 사이트를 참고해주세요.

http://langpop.com/

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 2:40오후

드뎌 악명높은 티오베 사이트의 링크가 첨부되는군요.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 2:47오후

그러면 여기를 보시지요.

http://lang-index.sourceforge.net/

아무리 익명이라도 예의를 지켜주시기 바랍니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 2:39오후

언어 순위는 사이트마다 다릅니다.
"프론트엔드로 한정지어 좋은 언어"라는 걸 굳이 자랑스럽게 여기는 것도 웃긴겁니다.
언어란 각자의 도메인을 가지게 되기 마련이죠.
그걸 확대 인식해서 머리에 각인해서 좋을 거 없습니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 2:52오후

"프론트엔드로 한정지어 좋은 언어"라고 말한 적이 없습니다.

토의/토론 예의를 지켜주시기 바랍니다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 2:58오후

Ubuntu쪽에 Desktop app들이 PyGtk같은걸 써서 만들어진게 좀 됩니다만.
Python으로 쉽게 빨리 만들려고 그랬었는지는 모르겠지만 속도, 메모리, 안정성등에서
C,C++ native로 만든것에 비해 너무 퀄러티가 떨어집니다.
(아마도 이런게 리눅스 데스크탑환경이 영원히 반쯤 만들어진 상태에서 더 이상 발전이 없게 하는 이유같기도...)

욕심 같아서 자기가 아는 언어로 모든 작업을 다하고야 싶겠지만 스크립트 언어 GUI바인딩은
프로토타입 혹은 실험적이고 장난감같은 툴 만들때는 몰라도 많은시간 안정적이고 빠르게
돌아가야하는 데스크탑환경 같은데는 자제해줬으면 하는 바람이더군요.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/05 - 10:24오전

회사에서 사용 하는 python script중에 라이브러리 호환성이 python 버젼마다 틀린게 좀 되서 자주 한 서버에 python interpreter를 2-3개 다른 버젼으로 돌릴때가 있습니다.

python version으로 인해 library 버젼과 문법 업데이트를 어떻게 관리 되는지 그리고 python의 어떤 version이 가장 많이 사용되는지 공유가 되면 좋은 정보가 될꺼 같습니다.

keedi의 이미지

글쓴이: keedi / 작성시간: 월, 2011/12/05 - 9:53오후

백만년 전에 산화해서 없어진 주제인 줄 알았는데...
오랫만에 보는 Perl vs Python 플레임이라 그런지 재밌네요. :-)

p.s.
Vim vs Emacs 플레임도 재미있을텐데...

----
use perl;

Keedi Kim

dwlee의 이미지

글쓴이: dwlee / 작성시간: 월, 2011/12/05 - 11:06오후

토론 란에 왜 애플은 Objective-C를 고수하는 지에 대한 것도 가관이었습니다ㅋ

keedi의 이미지

글쓴이: keedi / 작성시간: 화, 2011/12/06 - 3:02오후

쿨럭... 이거군요.

http://kldp.org/node/103842

2년 37주전 주제가 아직도 펄떡거린다는게 흥미롭군요. ;-)

----
use perl;

Keedi Kim

neocoin의 이미지

글쓴이: neocoin / 작성시간: 화, 2011/12/06 - 12:01오전

다른 언어들은 등장도 못한다는 점이 아쉽습니다.

keedi의 이미지

글쓴이: keedi / 작성시간: 화, 2011/12/06 - 2:58오후

아마 그렇다면 논점이탈 마이너스 점수를 받지 않을까 사료됩니다.
그냥 총출동해서 '언어의 제왕' 플레임으로 승화되면 더 재미있을텐데 말입니다. ;-)

----
use perl;

Keedi Kim

kaeri17의 이미지

글쓴이: kaeri17 / 작성시간: 월, 2011/12/05 - 11:50오후

글쓴분이 물었던게 이런건 아닌것 같은데 이런 류의 질문은 진행되다 보면 항상 Perl vs Python으로 가는듯 하네요. 순환떡밥인듯..

keedi의 이미지

글쓴이: keedi / 작성시간: 화, 2011/12/06 - 3:00오후

개인적으로 이거 좋아요! 는 해도 이거 나빠요! 라고 말은 잘 하지 않습니다.
다만, Perl이 가독성이 나쁘다는 FUD가 나오면 아무래도 한마디는 하고 지나가게 되는 것 같네요.
한국에서 Perl에 대한 FUD가 정설처럼 굳었다는 것은 안타까운 것 같습니다.

----
use perl;

Keedi Kim

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 화, 2011/12/06 - 3:33오후

openoffice나 libreoffice는 python을 기본 지원하고 있습니다.

http://wiki.services.openoffice.org/wiki/Python
http://help.libreoffice.org/Common/Scripting

excel을 사용해야 된다면 python win32를 통해 작업할 수 있을듯 하네요.

http://oreilly.com/catalog/pythonwin32/chapter/ch12.html

keedi의 이미지

글쓴이: keedi / 작성시간: 목, 2011/12/08 - 5:59오후

openoffice를 업무에 적극적으로 사용하고 있는 입장에서 정리하면
openoffice는 UNO를 사용해서 이기종간의 플랫폼과 통신해서 원하는 동작을 실행시킬 수 있습니다.
공식 홈페이지 및 사용자 그룹의 위키를 보면 아시겠지만 UNO 자체는 플랫폼 독립적입니다.
원하는 동작을 xml로 생성하기만 하면 쉘의 echo로도 움직이게 할 수 있지요.

Perl역시 CPAN에 있는 OpenOffice::UNO 라이브러리를 이용해서 손쉽게 오픈오피스를 제어할 수 있습니다.

마지막으로 openoffice나 libreoffice나 UNO단에서 변경된 것은 전혀 없습니다.
늬앙스의 차이긴 한데 python이 두 오피스를 모두 지원한다기 보다는
오픈오피스 내부 통신 규약 표준인 UNO를 지원하고 오라클이 싫어서(저도 싫습니다 :)
포크해 나간 libreoffice 역시 동일한 UNO 프토로콜을 사용하므로 똑같이 사용 가능하다 라고 보면됩니다.
perl 역시 마찬가지고, 이렇게 설명하는 것이 뭐가 문제냐고 한다면...

뭐... perl도 openoffice, libreoffice 둘 다 지원합니다.

정도가 되겠네요. :)

----
use perl;

Keedi Kim

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2011/12/08 - 7:22오후

뭔가를 자꾸 달리 읽으려는거 같은데...
"python이 두 오피스를 모두 지원한다"라고 한적이 없죠...

그냥 링크에 있는 원문을 바로 인용하겠습니다.
"OpenOffice.org 3.1 ships with the Python scripting language,"
"LibreOffice internally supports the following scripting languages: 4.Python"

그렇게 설명하지도 않았는데 그런식으로 읽고서 그런식으로 반론하는게 납득이 잘 안됩니다.

pung96의 이미지

글쓴이: pung96 / 작성시간: 목, 2011/12/08 - 7:41오후

자자, 뉘앙스 문제로 오해 하기 시작하면, 자기 논리가 흐트러 지기 시작합니다. 대범하게 넘깁시다.

keedi의 이미지

글쓴이: keedi / 작성시간: 목, 2011/12/08 - 7:57오후

저 역시 뭔가를 자꾸 달리 읽으려고 한 적도
그럴 생각도 없음을 확실하게 말씀드립니다.
당연히 반론도 아닙니다. 반론할 거리는 아니였지요.
이쪽(perl)이든 저쪽(python)이든 fact를 이야기한 것이니까요.

혹시 위쪽에 PyGTK와 PySide를 언급하셨던 분이신지요?
그때는 논리전개를 이해할 수 없어서 제가 오히려 불편했었는데,
이번에도 라이브러리와 관련한 소개 이야기가 나와
그때와 일맥 상통한 느낌이 있어서 사족을 달았습니다.

동일한 분이 아니셔서 정보 전달 이상의 감정이 전해져
불쾌하셨다면 사과드립니다.

죄송합니다.

----
use perl;

Keedi Kim

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 목, 2011/12/08 - 6:06오후

Perl의 Excel::Writer::XLSX( https://metacpan.org/module/Excel::Writer::XLSX ) 모듈은
리눅스에서도 됩니다. 윈도우와 엑셀없이 엑셀문서를 만들어 낼 수 있죠.

위의 http://oreilly.com/catalog/pythonwin32/chapter/ch12.html 에 나오는 방법은
오피스가 설치됐을때 COM컴포넌트를 핸들링하는 것이기 때문에 윈도우에 오피스가 안깔려있으면
못씁니다. 그렇게 COM을 쓸꺼면 Python 깔지 않고도 기본으로 윈도우에 포함된 VBscript나 Jscript를
사용해도 되죠.

아마 스크립트 언어들을 통틀어 Excel::Writer::XLSX 만한 기능을 지원하는 모듈은 없을 것 같네요.
있으면 한 번 보고싶은~

Supermania의 이미지

글쓴이: Supermania / 작성시간: 목, 2011/12/08 - 6:41오후

간만에 흥미로운 플레임이라 재미있게 보고있다가 아는 주제가 나와서 그냥 한마디 해봅니다 :-)
John McNamara씨가 아주 오래동안 관리하고 있는 Spreadsheet::WriteExcel 과 최근 XLSX용 Excel::Writer::XLSX는 몇년동안 업무에서 잘 쓰고 있는 모듈입니다. 대부분의 엑셀의 파싱/생성 관련 라이브러리들은 윗분이 설명해 주신것 처럼 COM 컴포넌트를 처리하는 방식이기 때문에 플렛폼에 제약이 있지만 이 모듈들은 XLS/XLS 파일의 형식을 binary 해킹해서 ms office 와 전혀 독립적으로 동작하는 방식으로 엑셀파일을 처리하고 있습니다. 제공하는 기능도 단순하게 셀에 값을 체우는정도가 아니라, 대부분의 서식 지정, 차트 , 엑셀 내부 합수연산 지정,메모,필터제어 등 제가 엑셀에서 손으로 할수 있는 작업은 대부분 잘 지원하고 있습니다. (그림을 포함한 상세한 예는 여기 있습니다. https://metacpan.org/module/Spreadsheet::WriteExcel::Examples ) 이 모듈은 2000년 1월부터 만들어졌고 지속적으로 업데이트 되고 있습니다. 저는 이런 실용적인 문제 접근방식과 강력함을 좋아합니다 :-)

내가 인내하는 만큼 나는 내꿈에 다가서고 있다.

cleansugar의 이미지

글쓴이: cleansugar / 작성시간: 금, 2011/12/09 - 9:04오전

저는 펄을 잘 몰라서 논쟁에 끼고 싶지는 않습니다.

다만, 파이썬에서 엑셀 다루기에 관심이 생겨서 검색해봤습니다.

*파이썬
http://pypi.python.org/pypi/pyExcelerator/0.6.4a
COM안씀

http://pypi.python.org/pypi/pyXLWriter/
It's a port of John McNamara's Perl Spreadsheet::WriteExcel module version 1.01 to Python. It allows writing of Excel spreadsheets without the need for COM objects.

http://pypi.python.org/pypi/Python%20For%20Excel/beta%2C%201.1

http://pypi.python.org/pypi/rbco.msexcel/0.0.1

http://pypi.python.org/pypi/pyutilib.excel/3.0.7

http://pypi.python.org/pypi/xlutils

http://pypi.python.org/pypi/xlrd3/0.1.4

http://www.opentradingsystem.com/PythonForExcel/main.html

*자바(자이썬)
http://jexcelapi.sourceforge.net/

http://poi.apache.org/spreadsheet/

http://www.moyosoft.com/jec/

http://www.aspose.com/categories/java-components/aspose.cells-for-java/default.aspx

http://www.jxcell.net/

*닷넷(아이언파이썬)
안 찾아봄

재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.

아이디의 아이디어 무한도전
http://blog.aaidee.com

귀태닷컴
http://www.gwitae.com

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 금, 2011/12/09 - 10:29오전

이번에는 Excel관련 Perl 모듈입니다.
http://metacpan.org 에 들어가서 Excel이라고 검색했더니, 샥하고 나와버렸습니다.

DateTime::Format::Excel 0.31
Task::Kensho::ExcelCSV 0.28
CPAN::Testers::WWW::Statistics::Excel 0.02
Spreadsheet::WriteExcel::FromXML 1.1
Spreadsheet::WriteExcel::FromDB::Query 0.01
Win32::Excel::Refresh 0.02
Spreadsheet::WriteExcel::Styler 1.00
Xymon::Server::ExcelOutages 0.03
DBIx::Report::Excel 0.2a
Spreadsheet::ParseExcel::Stream 0.05
Spreadsheet::Excel2Text 0.04
Spreadsheet::PrintExcelSheet 0.02
XML::Excel 0.02
XML::SAXDriver::Excel 0.06
Excel::Writer::XLSX 0.39
Spreadsheet::ParseExcel 0.59
Spreadsheet::WriteExcel 2.37
Spreadsheet::WriteExcelXML 0.13
CatalystX::CRUD::View::Excel 0.07
DBD::Excel 0.06
Test::Excel 1.24
Spreadsheet::WriteExcel::Simple::Tabs 0.09
CatalystX::Controller::ExtJS::REST::SimpleExcel 0.1.1
Catalyst::View::Excel::Template::Plus 0.03
Excel::Template 0.33
Spreadsheet::SimpleExcel 1.9
Querylet::Output::Excel::OLE 0.142
Querylet::Output::Excel::XLS 0.132
Catalyst::Action::Serialize::SimpleExcel 0.015
Spreadsheet::ParseExcel_XLHTML 0.04
Spreadsheet::TieExcel 0.75
Spreadsheet::WriteExcel::Worksheet::SheetProtection 0.03
Spreadsheet::ExcelHashTable 0.02
Excel::Template::Plus 0.05
Excel::Template::TT 0.0.1
Spreadsheet::WriteExcel::Simple::Save 0.05
Excel::Template::Element::Cell::AutoSize 0.04
Spreadsheet::ParseExcel::Simple 1.04
Spreadsheet::WriteExcel::FromDB 1.00
Spreadsheet::WriteExcel::Simple 1.04
Spreadsheet::XlateExcel 0.02
Win32::ExcelSimple 0.3
MojoX::Renderer::WriteExcel 1.11
Mojolicious::Plugin::WriteExcel 2.01
App::ZofCMS::Plugin::DataToExcel 0.0101
Spreadsheet::DataFromExcel 0.0101
Spreadsheet::DataToExcel 0.0103

Supermania의 이미지

글쓴이: Supermania / 작성시간: 금, 2011/12/09 - 10:59오전

혹시라도 파이썬만 사용해야하는 상황이 온다면 참고하겠습니다. 감사합니다 :-) 링크해 주신 모듈은 모두 살펴봤는데
xlwt 0.7.2 / xlrd 0.7.1 이 두 모듈이 가장 유용할것 같아 보입니다. 관련 내용은 http://www.python-excel.org/ 에 잘 정리되어있네요

내가 인내하는 만큼 나는 내꿈에 다가서고 있다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2011/12/12 - 7:16오후

두달전부터 이 모듈을 사용하고 있는데
모 이런 좋은것이 있나 했습니다.

아이디어에 대한 해결책을 CPAN 에서 못찾으면 내 아이디어가 넘 안드로메다라
하겠습니다 ^_^

페이지

둘러보기