최근 Stackless Python 에 대해 읽었 으며 바닐라 cPython과 비교할 때 많은 이점이있는 것 같습니다. 그것은 그 멋진 등 무한 재귀, microthreads, 연속성을, 같은 기능을 모두 가지고 있으며, (경우 10 % 동시에 빠른 CPython을보다 파이썬 위키 믿을 수있다) 및 버전을 적어도 2.5 (그것과 호환, 2.6 및 3.0).
이 모든 것이 사실 이기에는 거의 너무 좋아 보인다. 그러나 TANSTAAFL 은 Python 커뮤니티에서 Stackless에 대한 열정을 많이 보지 못하며 PEP 219 는 실현되지 않았습니다. 왜 그런 겁니까? Stackless의 단점은 무엇입니까? Stackless 옷장에는 어떤 골격이 숨겨져 있습니까?
(Stackless는 실제 동시성, 동시 프로그래밍 방식의 쉬운 방법을 제공하지 않습니다. 실제로 귀찮게하지는 않습니다.)
답변:
Wiki에서 "스택리스 (Stackless)가 10 % 빠릅니다"라는 곳을 어디에서 봤는지 모르겠지만 다시 한 번 성능 수치를 측정하지는 않았습니다. Stackless가 큰 차이를 만들기 위해 무엇을하는지 생각할 수 없습니다.
Stackless는 여러 조직 / 정치 문제가있는 놀라운 도구입니다.
첫 번째는 역사에서 비롯됩니다. Christian Tismer는 약 10 년 전에 결국 Stackless가 된 것에 대해 이야기하기 시작했습니다. 그는 자신이 원하는 것을 알았지 만 자신이하고있는 일과 사람들이 왜 그것을 사용해야하는지 설명하는 데 어려움을 겪었습니다. 그의 배경에는 코 루틴과 같은 아이디어에 관한 CS 교육이 없었고 그의 프리젠 테이션과 토론은 구현 지향적이기 때문에 아직 끊임없는 지식을 가진 사람이 솔루션으로 사용하는 방법을 이해하기 어렵습니다. 그들의 문제.
이런 이유로 초기 문서는 열악했습니다. 써드 파티 (third-party) 기고자들로부터 최선을 다해 사용법을 설명했습니다. PyCon 설문 조사에 따르면 PyCon 2007에서 " 스택리스 사용 "에 대해 이야기했습니다 . Richard Tew는 이러한 정보를 수집하고 stackless.com을 업데이트 하고 새로운 Python 릴리스가 출시 될 때 배포를 유지 관리 하는 데 많은 노력을 기울 였습니다. 그는 EVE Online의 개발자 인 CCP Games 의 직원으로 게임 시스템의 필수 부분으로 Stackless를 사용합니다.
CCP 게임은 또한 사람들이 Stackless에 관해 이야기 할 때 사용하는 가장 큰 실제 사례입니다. Stackless의 주요 튜토리얼은 Grant Olson의 " Stackless Python을 사용한 동시 프로그래밍 소개 "이며 게임 지향입니다. 나는 이것이 사람들이 게임을보다 쉽게 지향적으로 지향 할 때 Stackless가 게임 지향이라는 생각을 왜곡 시킨다고 생각합니다.
또 다른 어려움은 소스 코드였습니다. 원래 형태로 파이썬의 많은 부분을 변경해야했기 때문에 파이썬 리더 인 귀도 반 로섬 (Guido van Rossum)은 경고했다. 그 이유 중 일부는 call / cc에 대한 지원이 나중에 "더 높은 수준의 양식이있을 때 goto를 지원하는 것과 매우 흡사 한 것"으로 제거되었다고 생각합니다. 나는이 역사에 대해 확신하지 못하므로이 단락을 "스택리스 (Stackless)가 너무 많은 변경이 필요했습니다."라고 읽습니다.
이후 릴리스에서는 변경 사항이 필요하지 않았으며 Tismer는 계속해서 Python에 포함하도록 추진했습니다. 몇 가지 고려 사항이 있었지만 (내가 아는 한) 공식 입장은 CPython이 Python 구현 일뿐 아니라 참조 구현의 의미이며 Jython으로 구현할 수 없기 때문에 Stackless 기능을 포함하지 않는다는 것입니다. 또는 철 파이썬.
" 코드베이스에 대한 중요한 변경 "에 대한 계획은 전혀 없습니다 . Arafangion (의견 참조)의 인용 및 참조 하이퍼 링크는 대략 2000/2001입니다. 구조적 변화는 오래 전에 이루어졌으며 위에서 언급 한 것입니다. 스택리스는 이제 안정적이고 성숙했으며 지난 몇 년 동안 코드베이스를 약간만 수정했습니다.
Stackless의 마지막 제한 사항-Stackless에 대한 강력한 지지자는 없습니다. Tismer는 이제 Python for Python의 구현 인 PyPy에 깊이 관여하고 있습니다. 그는 PyPy에서 Stackless 기능을 구현했으며 Stackless 자체보다 훨씬 우수하다고 생각하며 PyPy가 미래의 길이라고 생각합니다. Tew는 Stackless를 유지하지만 옹호에 관심이 없습니다. 나는 그 역할을하는 것을 고려했지만 그로부터 수입을 얻는 방법을 알 수 없었습니다.
이 토론을 찾는 데 시간이 오래 걸렸습니다. 그 당시 나는 PyPy에 있지 않았지만 건강이 갑자기 갑자기 멈추기 전까지 psyco와 2 년 간의 관계를 가졌습니다. 나는 현재 다시 활성화되어 대안적인 접근법을 설계하고 있습니다-EuroPython 2012에서이를 제시 할 것입니다.
Andrews 진술의 대부분은 맞습니다. 약간의 추가 사항 :
인터프리터 루프를 최적화했기 때문에 스택리스는 10 년 전 CPython보다 훨씬 빠릅니다. 당시 귀도는 그럴 준비가되어 있지 않았습니다. 몇 년 후 사람들은 비슷한 최적화와 훨씬 더 나은 최적화를 수행하여 스택리스를 예상대로 조금 느리게 만듭니다.
포함에 : 글쎄, 처음에 나는 매우 압박하고 Stackless가 갈 길이라고 확신했다. 나중에, 거의 포함될 수 있었을 때, 나는 그것에 대한 관심을 잃었고, 부분적으로 좌절하지 않고 부분적으로 Stackless를 제어하기 위해 이런 식으로 유지하는 것을 선호했습니다.
"다른 구현은 할 수 없다"와 같은 주장은이 주장이 사용될 수있는 다른 예들이 있기 때문에 항상 저에게 불쾌감을 느꼈습니다. 나는 그 사실을 잊어 버리고 Guido와 좋은 우정을 유지하면서 나 자신의 배포판을 가지고 있다고 생각했다.
한편 상황이 다시 바뀌고 있습니다. 나는 PyPy와 Stackless를 확장으로 작업하고 있습니다.
건배-크리스
올바르게 기억한다면 Stackless는 공식 CPython에 포함될 예정이지만 stackless의 저자는 CPython 사람들에게 그렇게하지 말라고 지시했습니다. 프로젝트는 더욱 성숙했다.
나는 또한 여기에 대한 답변에 관심이 있습니다. 나는 Stackless로 조금 연주했으며 표준 Python에 대한 견고한 추가 기능 인 것처럼 보입니다.
PEP 219는 Python이 다른 스택으로 변경하려는 경우 C 코드에서 Python 코드를 호출 할 때 발생할 수있는 잠재적 인 어려움을 언급합니다. 이것을 감지하고 방지하는 방법이 필요합니다 (C 스택을 휴지통에 버리지 않도록). 나는 이것이 다루기 쉽다고 생각하기 때문에 왜 Stackless가 독자적으로서야하는지 궁금합니다.