저의 인생을 바꿔 준 분에 대해 이야기하고 싶음. Flask mega tutorial을 통해 첫 웹사이트를 만들었고, 런칭 직전 Flask에서 깨진 파일을 처리하는 중요한 부분에서 막혔는데, 질문을 했더니 Stack Overflow 답변으로 해결해서 바로 사이트에 반영해 버림. 그 이후 사이트가 엄청 퍼졌음. 참고용으로 답변 링크를 남겨둠 stackoverflow link
Flask와는 상관 없지만, 새로운 Flask 로고는 정말 마음에 안 듦. 이전 로고는 빈티지하고 손수 만든 듯한 느낌이 있었는데, 새 로고는 마치 고등학생이 WordArt로 장난삼아 만든 작품 같음. 이전 로고, 새 로고
혹시 네가 만든 사이트가 yout.com 인가 질문하고 싶음. 아직도 Flask를 쓰고 있는지 궁금함
"멈추지" 않길 바란다는 의견을 보며, Donald Knuth가 변화보다는 지속적으로 동일한 결과를 내는 시스템을 더 중시한다는 부분이 신선하게 느껴짐. 모든 게 몇 년만 지나면 구식이 되는 세상에서, 뭔가 OOO가 새로 나왔다고 무조건 바꿔야 하는 강박은 병 같다는 생각임. 우리가 정말 100년 쓸 코드를 쓸 수 없을 이유가 없음. 코드는 결국 수학임. 수천 년 전 발명된 다항식 쓰면 촌스러운 사람 취급받지 않는 것처럼, 검증된 것에 머무르는 자세도 필요하다고 봄. 매번 새 버전, 새 도구에만 집착하지 않아도 됨. 바꿀 이유 없는 코드를 쓰는 사람들이 진짜 기여하는 분들이라고 생각함
πthon 관련 농담에 놀랍게 잘 어울리는 상황이라는 코멘트
Python 뉴스가 나올 때마다, 2025년에도 PyPy가 여전히 별도의 노선이라는 사실이 아쉬움. GIL 없는 Python이 someday GIL 없는 C FFI까지 가능하게 해줄지 궁금함. 그건 Python에 정말 큰 도움이 될 거라고 생각함
C FFI는 예전부터 GIL을 수동 해제할 수 있었기 때문에, 그 의미가 뭔지 정확히 궁금함
C 언어에서 출발해 여러 컴파일러 구현으로 다양한 방언이 탄생하는 게 건강한 생태계라고 생각함. 실험과 발전을 촉진하기 때문. PyPy와 CPython의 차이도 크지 않다고 여기며 호환성도 높음 pypy 호환 안내
freethreading이 바로 그 목적임. 아직 여러 C FFI 라이브러리가 GIL 없이 동작하도록 바뀌지 않아서, 기본값으로 freethreading을 쓸 수 없다고 알고 있음
Python이 실험적 JIT을 추가하여 PyPy에 한 발짝 더 다가간 셈임. 앞으로 새로운 JIT을 직접 만들지 PyPy를 합칠지는 모르겠지만, PyPy에서 많은 것을 배웠다고 믿음
이런 문제(별도 구현 체계를 합치는 것)가 바뀔 수 있다고 보는지 묻고 싶음. Python이 우연히 성능에 악영향을 끼치는 또 다른 브레이킹 체인지를 도입하는 시나리오는 넓은 범위의 사용자들에게 해가 될 것임. Python 조직이 과연 그걸 바랄까 의문임
PyPy가 멀티스레드 코드에서도 free threaded CPython보다 더 빠르다는 점이 흥미로움
non-GIL로 전환이 매우 매끄럽게 진행된 것이 눈에 띔. 2→3 버전 때랑 비교하면 이번 전환은 정말 대단함. 표준 속도에 금방 도달한 점도 기대가 크며, 비호환 요소들도 곧 사라질 수 있을 거라 희망함
벤치마크를 빠르게 직접 해보고 싶다면 fast_langton_ant 리포를 추천함. "python3 server.py -s 10000000 -n" 식으로 실행하면 됨
접히는 댓글(fold comment) 기능이 karma나 다른 옵션에 따라 적용되는지 궁금함. Miguel이 도와준 에피소드가 가장 인기 있는 글이라 인상 깊었지만, 본문과 관련된 이야기만 보고 싶을 때 접기 기능이 없다는 걸 처음 깨달았음
단순한 반복문과 정수 연산만 사용하는 벤치마크로 Python의 현실적인 사용을 평가하기엔 무리라고 생각함. 해시맵이나 문자열 처리가 더 실제 코드에 가까움. 많은 Python 사용자는 숫자 연산은 외부 라이브러리에 맡김
벤치마크는 모두 특정 기준으로 측정하게 설계되기 마련임. 본인이 글에서 목표를 설명했으니 궁금하면 참고하길 추천함
더 철저히 분석하는 글이었다면 좋겠지만, 그래도 내 실제 사용에는 이런 벤치마크가 더 잘 맞음. 나의 경우 대부분 몬테카를로 시뮬레이션 또는 간단한 과학계산을 다양한 문제에 반복해서 만듦. 일회성 시뮬레이션에 굳이 빠른 알고리즘이나 익숙하지 않은 라이브러리를 쓰지 않음. 가끔 10분이나 걸려도 상관없음(예, scipy, numpy는 주로 쓰긴 함). 반복 가정 변경을 자주 하다보니 최대한 단순하게 접근함. 가독성과 즉석 코드가 중요하고, 최적화가 잘 안 되어도 상관 없음(예: 피보나치, 버블 소트, 중첩 for문처럼). 만약 진짜 성능이 필요할 땐 cpp/zmp/pybind/numba로 내용을 직접 구현함
FastAPI 엔드포인트 호출이나 numpy 계산 같이 대중적인 예제를 벤치마크에 포함시키는 게 현실적인 Python사용에 더 가까움. 이런 부분이 순수 python코드가 아닐 수 있지만, 실제로 많은 사람들이 Python을 그렇게 씀
tight loop와 int연산만으로 벤치마크하는 것이 얼마나 현실적인지 의문임
새로운 실험적 tail call 인터프리터(옵션 --with-tail-call-interp)가 벤치마크에 포함됐는지 궁금함 tail-call-interp 공식 문서. 테스트 결과에서 언급이 없어 아마 포함이 안 된 것 같다고 추측함. tail call interpreter가 기존 다른 구현과 얼마나 차이나는지 비교해보고 싶음
본인이 사용한 Python 빌드는 tail call 기능이 켜진 상태(옵션 --with-tail-call-interp)였음. 최적화가 재귀 tail call에도 적용되는지 확실하진 않지만, 적용됐다면 Fibonacci 테스트에서 성능 향상을 봤어야 함
Hacker News 의견
저의 인생을 바꿔 준 분에 대해 이야기하고 싶음. Flask mega tutorial을 통해 첫 웹사이트를 만들었고, 런칭 직전 Flask에서 깨진 파일을 처리하는 중요한 부분에서 막혔는데, 질문을 했더니 Stack Overflow 답변으로 해결해서 바로 사이트에 반영해 버림. 그 이후 사이트가 엄청 퍼졌음. 참고용으로 답변 링크를 남겨둠 stackoverflow link
Flask와는 상관 없지만, 새로운 Flask 로고는 정말 마음에 안 듦. 이전 로고는 빈티지하고 손수 만든 듯한 느낌이 있었는데, 새 로고는 마치 고등학생이 WordArt로 장난삼아 만든 작품 같음. 이전 로고, 새 로고
혹시 네가 만든 사이트가 yout.com 인가 질문하고 싶음. 아직도 Flask를 쓰고 있는지 궁금함
한번쯤 다시 vibe coding을 하며 microphonetest.com 사이트가 부활하면 정말 좋겠음
벤치마크를 짤 때 루프 안에서 시간을 측정해서 합산하는 식으로 하지 않길 권장함. 전체 루프의 실행 시간을 측정한 후 반복 수로 나누는 게 좋음. 시간 측정 자체에서 생기는 지터로 결과가 왜곡될 수 있음
Python이 3.14 버전에서 TeX처럼 고정될까봐 걱정됨 Reddit 링크
"멈추지" 않길 바란다는 의견을 보며, Donald Knuth가 변화보다는 지속적으로 동일한 결과를 내는 시스템을 더 중시한다는 부분이 신선하게 느껴짐. 모든 게 몇 년만 지나면 구식이 되는 세상에서, 뭔가 OOO가 새로 나왔다고 무조건 바꿔야 하는 강박은 병 같다는 생각임. 우리가 정말 100년 쓸 코드를 쓸 수 없을 이유가 없음. 코드는 결국 수학임. 수천 년 전 발명된 다항식 쓰면 촌스러운 사람 취급받지 않는 것처럼, 검증된 것에 머무르는 자세도 필요하다고 봄. 매번 새 버전, 새 도구에만 집착하지 않아도 됨. 바꿀 이유 없는 코드를 쓰는 사람들이 진짜 기여하는 분들이라고 생각함
πthon 관련 농담에 놀랍게 잘 어울리는 상황이라는 코멘트
Python 뉴스가 나올 때마다, 2025년에도 PyPy가 여전히 별도의 노선이라는 사실이 아쉬움. GIL 없는 Python이 someday GIL 없는 C FFI까지 가능하게 해줄지 궁금함. 그건 Python에 정말 큰 도움이 될 거라고 생각함
C FFI는 예전부터 GIL을 수동 해제할 수 있었기 때문에, 그 의미가 뭔지 정확히 궁금함
C 언어에서 출발해 여러 컴파일러 구현으로 다양한 방언이 탄생하는 게 건강한 생태계라고 생각함. 실험과 발전을 촉진하기 때문. PyPy와 CPython의 차이도 크지 않다고 여기며 호환성도 높음 pypy 호환 안내
freethreading이 바로 그 목적임. 아직 여러 C FFI 라이브러리가 GIL 없이 동작하도록 바뀌지 않아서, 기본값으로 freethreading을 쓸 수 없다고 알고 있음
Python이 실험적 JIT을 추가하여 PyPy에 한 발짝 더 다가간 셈임. 앞으로 새로운 JIT을 직접 만들지 PyPy를 합칠지는 모르겠지만, PyPy에서 많은 것을 배웠다고 믿음
이런 문제(별도 구현 체계를 합치는 것)가 바뀔 수 있다고 보는지 묻고 싶음. Python이 우연히 성능에 악영향을 끼치는 또 다른 브레이킹 체인지를 도입하는 시나리오는 넓은 범위의 사용자들에게 해가 될 것임. Python 조직이 과연 그걸 바랄까 의문임
PyPy가 멀티스레드 코드에서도 free threaded CPython보다 더 빠르다는 점이 흥미로움
non-GIL로 전환이 매우 매끄럽게 진행된 것이 눈에 띔. 2→3 버전 때랑 비교하면 이번 전환은 정말 대단함. 표준 속도에 금방 도달한 점도 기대가 크며, 비호환 요소들도 곧 사라질 수 있을 거라 희망함
벤치마크를 빠르게 직접 해보고 싶다면 fast_langton_ant 리포를 추천함. "python3 server.py -s 10000000 -n" 식으로 실행하면 됨
접히는 댓글(fold comment) 기능이 karma나 다른 옵션에 따라 적용되는지 궁금함. Miguel이 도와준 에피소드가 가장 인기 있는 글이라 인상 깊었지만, 본문과 관련된 이야기만 보고 싶을 때 접기 기능이 없다는 걸 처음 깨달았음
단순한 반복문과 정수 연산만 사용하는 벤치마크로 Python의 현실적인 사용을 평가하기엔 무리라고 생각함. 해시맵이나 문자열 처리가 더 실제 코드에 가까움. 많은 Python 사용자는 숫자 연산은 외부 라이브러리에 맡김
벤치마크는 모두 특정 기준으로 측정하게 설계되기 마련임. 본인이 글에서 목표를 설명했으니 궁금하면 참고하길 추천함
더 철저히 분석하는 글이었다면 좋겠지만, 그래도 내 실제 사용에는 이런 벤치마크가 더 잘 맞음. 나의 경우 대부분 몬테카를로 시뮬레이션 또는 간단한 과학계산을 다양한 문제에 반복해서 만듦. 일회성 시뮬레이션에 굳이 빠른 알고리즘이나 익숙하지 않은 라이브러리를 쓰지 않음. 가끔 10분이나 걸려도 상관없음(예, scipy, numpy는 주로 쓰긴 함). 반복 가정 변경을 자주 하다보니 최대한 단순하게 접근함. 가독성과 즉석 코드가 중요하고, 최적화가 잘 안 되어도 상관 없음(예: 피보나치, 버블 소트, 중첩 for문처럼). 만약 진짜 성능이 필요할 땐 cpp/zmp/pybind/numba로 내용을 직접 구현함
FastAPI 엔드포인트 호출이나 numpy 계산 같이 대중적인 예제를 벤치마크에 포함시키는 게 현실적인 Python사용에 더 가까움. 이런 부분이 순수 python코드가 아닐 수 있지만, 실제로 많은 사람들이 Python을 그렇게 씀
tight loop와 int연산만으로 벤치마크하는 것이 얼마나 현실적인지 의문임
새로운 실험적 tail call 인터프리터(옵션 --with-tail-call-interp)가 벤치마크에 포함됐는지 궁금함 tail-call-interp 공식 문서. 테스트 결과에서 언급이 없어 아마 포함이 안 된 것 같다고 추측함. tail call interpreter가 기존 다른 구현과 얼마나 차이나는지 비교해보고 싶음