3.1. 테스트 모둠이 있나요?

 import test.autotest

 import autotest

주의: 만약 "make test"가 실패한다고 해서, 단순히 그 출력을 뉴스그룹에 편지하지 마세요 -- 이것으로는 그 프로그램을 디버그하기 위한 충분한 정보가 되지 않습니다. 대신에, 어떤 테스트가 실패하는지 알아 내세요, 그리고 그 테스트를 수동으로 상호대화 모드에서 실행하세요. 예를 들어, "make test"가 test_spam이 실패했다고 보고하면, 이것을 상호대화적으로 점검하세요:

 import test.test_spam

http://sourceforge.net/tracker/?func=add&group_id=5470&atid=105470

3.2. 그 테스트 모둠을 실행할 때, 나는 부동소수점 연산에 관한 불평을 듣습니다, 그렇지만 부동소수점 연산을 다룰 때는 잘 못된 어떤 것도 발견할 수 없습니다.

3.3. 설정 스크립트를 재실행하고 난 후의 링크 에러.

3.4. 스크립트로 (그 스크립트의 이름 뒤에) 건네진 선택사항들에 관하여 파이썬 인터프리터가 불평합니다.

        #! /usr/local/bin/python --

        python -- script.py [options]

3.5. SGI에 대한 구축을 하는 중에, glmodule.c를 생성하기 위하여 파이썬을 실행하였지만, 파이썬은 구축되지 않았거나 혹은 설치되지 않았습니다.

3.6. 저는 VPATH를 사용합니다 그러나 어떤 목표들은 소스 디렉토리에 구축됩니다.

3.7. GNU의 readline 라이브러리와 링크 또는 구축곤란.

#readline readline.c -lreadline -ltermcap

주석을 제거 하세요. 환경설정 선택사항인 --with-readline은, 적어도 파이썬 2.0에서는 더이상 지원되지 않습니다. readline 라이브러리를 사용하고 구축하는데 대한 약간의 힌트를 들자면: SGI IRIX 5에서는, 다음과 같이 rldefs.h에 추가 하셔도 좋습니다:

        #ifndef sigmask
        #define sigmask(sig) (1L << ((sig)-1))
        #endif

3.8. 오래된 리눅스 1.x 버전에서 소켓 I/O에 문제.

3.9. Ultrix에서 프로토타입의 문제.

3.10.플랫폼 X에서 파이썬을 구축하는데 따르는 다른 문제들.

  http://sourceforge.net/tracker/?group_id=5470&atid=105470

많은 경우에, 우리는 같은 하드웨어 혹은 운영체제에 접근할 수는 없습니다, 그러므로 제발, 여러분이 소스포지 계정을 가지고 계시면, 여러분의 보고서를 다 채워 넣으시기 전에 로그인을 하세요, 혹은 계정이 없으시다면, 전자 우편 주소를 포함하셔서 여러분에게 추가 질문을 할수 있도록 해 주세요. 소스포지에 처음 로그인 하시게 되면 여러분의 보고서에 대하여 연구한 갱신사항이 여러분에게 보내질 것입니다.

3.11. 리눅스에서 동적 적재를 설정하는 법.

3.12. 리눅스 2.0에서 공유 모듈을 얻을 수 없습니다 (Slackware96)?

이렇게 수정한 후에 파이썬을 재구축하려고 시도하기 전에, config.cache 파일을 rm으로 삭제하고 나서, 아마도 환경설정 스크립트를 재실행할 필요가 있을 것입니다.

3.13. 리눅스에서 공유 모듈을 만들 때의 문제.

  *shared*  

3.14. 리눅스에서 쓰레드를 사용하는 법.

[앤디 더스트만(Andy Dustman)] glibc 시스템 (즉. RedHat 5.0+)에 대해서 말하자면, LinuxThreads 는 폐기되고 POSIX 쓰레드 (-lpthread)가 대신하게 되었습니다. 이전의 RedHat으로부터 업그레이드 하셨다면, LinuxThreads를 "rpm -e linuxthreads linuxthreads-devel"으로 제거하세요. 그리고 --with-thread를 위와 같이 재설정하십시오.

3.15. C++ 코드를 담고 있는 공유 라이브러리와 링크할 때 에러 발생.

3.16. 삭제됨 **

3.17. 삭제됨. *

3.18. _tkinter 모듈에 대한 컴파일 혹은 링크 에러

(또한 주의하실 것은 패치되지 않은 파이썬 1.5.1을 Tcl/Tk 7.6/4.2 이전에 대하여 컴파일 하시면, Tcl_Finalize에 관한 에러를 맞이합니다. 다음의 1.5.1 패치 페이지 http://www.python.org/1.5/patches-1.5.1/를 참조하세요.)

3.19. Tcl/Tk를 위해 파이썬을 설정하고 구축하였지만 "import Tkinter"가 실패합니다.

3.20. Tk가 DEC Alpha에서 정확하게 동작하지 않습니다.

Tcl/Tk를 위한 64-bit 버그수정 버전이 있습니다; 다음을 참조하세요

	http://grail.cnri.reston.va.us/grail/info/patches/tk64bit.txt

3.21. 약간의 일반적인 시스템 호출을 포식스 모듈에서 발견할 수 없습니다.

3.22. 윈도우에서, ImportError: No module named string.

set PYTHONPATH=c:\python;c:\python\lib;c:\python\scripts

(파이썬이 c:\python에 설치되어 있다고 가정합니다)

3.23. gl 모듈을 사용할 때 SGI에 관하여 핵심코드 덤프.

3.24. 윈도우에서 DLL을 구축하는 동안에 "Initializer not a constant" 에러 발생

이것은 MSVC아래에서 DLL을 구축할 때 일어납니다. 이것에 접근하는 방법은 두가지가 있습니다: 그 모듈을 C++로 컴파일 하거나, 혹은 코드를 다음과 같이 변경하는 것입니다:

  statichere PyTypeObject bstreamtype = {
      PyObject_HEAD_INIT(NULL) /* must be set by init function */
      0,
      "bstream",
      sizeof(bstreamobject),

  ...

  void
  initbstream()
  {
      /* Patch object type */
      bstreamtype.ob_type = &PyType_Type;
      Py_InitModule("bstream", functions);
      ...
  }

3.25. 파이프 혹은 파일로 방향전환된 출력이 리눅스에서 사라집니다.

    % python script.py
    ...some output...
    % python script.py >file
    % cat file
    % # no output
    % python script.py | cat
    % # no output
    %

적어도 한개의 보고가 있다면 (더 새로운 버전으로) 리눅스와 파이썬을 재 설치하고 이 문제를 제거했다고 합니다; 그래서 이것이 아마도 해결책이 아닐까 합니다.

3.26. libc 5.4를 가진 리눅스에서 모든 곳에서 구문 에러

   File "<stdin>", line 1
       import sys
          ^
   Syntax Error: "invalid syntax"

[Martin v. Loewis의 답변으로부터 인용]

추가 [Andreas Jung으로부터 인용]: libc 5.4.x으로 업그레이드하였고, 그래도 문제가 지속되면, 구형 버전의 libc를 위한 라이브러리 경로를 점검하세요. 거기에 있는 libs와 header 파일로 libc를 깨끗하게 갱신하세요. 그리고 나서 모두 다 재컴파일하세요.

3.27. 리눅스에서 Tkinter를 사용할 때 XIO에서 충돌

  >>> from Tkinter import *
  >>> root = Tk()
  XIO:  fatal IO error 0 (Unknown error) on X server ":0.0"
        after 45 requests (40 known processed) with 1 events remaining.

(Disclaimer: this is from memory.)

3.28. Tkinter가 작동하는지 어떻게 테스트 할 수 있나요?

  python
  >>> import _tkinter
  >>> import Tkinter
  >>> Tkinter._test()

첫 번째 서술문(import _tkinter)이 실패하면, 여러분의 파이썬 설치가 아마도 Tcl/Tk를 지원하도록 설정되지 않은 것입니다. 유닉스에서, Tcl/Tk를 설치하였다면, _tkinter 모듈과 TKPATH 환경 변수를 사용가능하도록 Modules/Setup을 편집한 후에 파이썬을 재구축하여야 합니다.

Tcl/Tk 버전 번호 불일치 혹은 TCL_LIBRARY없음 또는 TK_LIBRARY 환경 변수들에 관한 불평들을 만나게 될 수도 있습니다. 이러한 것들은 Tcl/Tk 설치 문제와 관련이 있습니다.

흔한 문제는 설치된 Tcl/Tk 라이브러리의 버전과 일치하지 않는 tcl.h와 tk.h 버전을 설치하는 것입니다; 이것은 보통 연결자 에러를 야기하거나 혹은 (동적 적재를 사용할 때) 공유 라이브러리를 적재하는 동안에 '심볼 없음' 불평으로 결론지어집니다.

3.29. 파이썬 인터프리터의 상호대화 모드에서 함수/변수 이름 완성을 수행하도록 할 방법이 있나요?

유닉스에서, readline 모듈을 가능하도록 하셨다면 (즉. 이맥스-스타일의 명령어 라인 편집과 bash-스타일의 명령기억이 작동한다면), 문서화되지 않은 표준 라이브러리 모듈 "rlcompleter"를 수입함으로써 이것을 추가할 수 있습니다. 간단한 식별자를 채워 넣으면, __main__에 있는 키워드, 내장 그리고 전역변수들을 채워줍니다; NAME.NAME...을 완성할 때, 그 표현식을 마지막 점까지 평가하여(!) 그 속성들을 채워넣습니다.

이런식으로, "import string"을, "string."이라고 타자하고, 완성 키를 두번 누르면, 그 문자열 모듈이 정의한 이름들의 목록을 볼 수 있습니다.

팁: 탭 키를 완성 키로 사용하려면, 다음과 같이 호출하세요

    readline.parse_and_bind("tab: complete")

주의 (더 자세히 알려면 rlcompleter.py를 위한 문서화 문자열(docstring)을 참조하세요):

* 만약 __getattr__ 낚아채기를 가지고 있는 객체가 발견된다면 NAME.NAME... 형태를 평가하는 것은 임의적인 어플리케이션을 실행되어야 할 코드로 정의하여 버릴 수도 있습니다. 왜냐하면 이 사양을 가능하게 하는 것은 어플리케이션 (혹은 사용자)의 책임이기 때문인데, 이것은 허용할 만한 위험이라고 생각합니다. 더욱 복잡한 표현식 (예를들어, 함수 호출이나 연산을 지표화하는 것들)은 평가되지 않습니다.

* GNU readline는 또한 내장 함수 input()과 raw_input()에 의해서 사용됩니다, 그리하여 이것들은 또한 그 완성사용 때문에 혜택을 받기도/고통을 받기도 합니다. 분명히 상호대화적인 어플리케이션은 자신만의 완성 기능을 지정하고 모든 입력에 대하여 raw_input()을 사용함으로써 혜택을 받을 수 있습니다.

* 표준입력이 tty 장치가 아니라면, GNU readline은 절대로 사용되지 않습니다, 그리고 이 모듈은 (그리고 readline 모듈)은 조용하게 작동하지 않습니다.

3.30. 왜 파이썬 인터프리터는 공유 라이브러리처럼 구축되지 않았나요? *

이것을 다른 모든 플랫폼에서 작동하도록 하는 것은 정말 악몽입니다. 공유 라이브러리의 이식성은 고통입니다. 네 물론, GNU의 libtool에 관하여 알고 있습니다 -- 그러나 그것은 파일 이름의 관례 등등을 사용하기를 요구하고, 지금 사용하고 있는 모든 makefile과 설정도구들을 완전하게 그리고 철저하게 재작성 하도록 요구할 것입니다.

실제적으로, 파이썬을 내장한 어플리케이션은 없습니다 -- 더욱 더 일반적인 것은 파이썬 확장을 보유하는 것이고, 이미 공유 라이브러리입니다. 또한, 엄격한 내장자들은 때때로 그들이 사용하고 있는 파이썬 버전과 설정에 관하여 전적인 통제를 원합니다. 그래서 어쨋든 표준 공유 라이브러리를 사용하기를 원하지 않을 것입니다. 그래서 많은 어플이 파이썬을 내장할 때 공간을 절약한다는 동기가 이론적으로는 좋지만, 실제적으로 그 만큼 많이 절약해 줄지는 의문입니다. (그러므로 저는 공유 라이브러리를 만드는 것에 중요성을 두지 않습니다.)

리눅스 시스템을 위해서는, libpython1.5.so를 만드는 가장 간단한 방법은 다음과 같습니다 (출처는 Minotaur 프로젝트 웹페이지 http://www.equi4.com/minotaur/minotaur.html 입니다.):

  make distclean
  ./configure
  make OPT="-fpic -O2"
  mkdir .extract
  (cd .extract; ar xv ../libpython1.5.a)
  gcc -shared -o libpython1.5.so .extract/*.o
  rm -rf .extract

3.31. GCC로 Solaris 2.6 (SunOS 5.6)에서 구축할 수 없습니다

 In file included from /usr/include/sys/stream.h:26,
                  from /usr/include/netinet/in.h:38,
                  from /usr/include/netdb.h:96,
                  from ./socketmodule.c:121:
 /usr/include/sys/model.h:32: #error "No DATAMODEL_NATIVE specified"

3.32. "make clean"을 실행하면 잇달으는 구축을 실패하게 하는 문제있는 파일들이 남는 것 같습니다.

기쁜마음으로 구축하고 설정한 후에 "make clean"을 사용하여 source/build 디렉토리의 크기를 줄이세요. 이미 파이썬을 구축하기를 시도해 보았고 다시 시작하고자 한다면, "make clobber"를 사용하여야만 합니다. 그것은 "make clean"을 하여주고 또한 이전의 구축으로부터 부분적으로 구축된 파이썬 라이브러리와 같은 파일들을 제거합니다.

3.33. 버그 보고와 패치를 제출하기

버그: http://sourceforge.net/tracker/?group_id=5470&atid=105470

패치: http://sourceforge.net/tracker/?group_id=5470&atid=305470

소스포지에 계정을 가지고 계시다면, 버그 보고를 제출하시기 전에 먼저 로그인 하시길 바랍니다; 이렇게 하시면 뒤-따르는 문제들이 발생하였을 때 우리가 여러분의 보고에 관하여 더 쉽게 여러분에게 접근할 수 있을 것입니다. 또한 여러분의 버그에 관한 작업과 동시에 소스포지가 갱신사항을 여러분에게 보내줄 수 있을 것입니다. 소스포지에 계정이 없으시다면, 여러분의 이름과 전자우편 주소를 보고서의 한 부분에 남겨주시길 부탁드립니다.

3.34. 파이썬 1.5.2, 솔라리스 7, 그리고 gcc 2.95.2아래에서 공유 라이브러리를 적재할 수 없습니다

 symbol PyExc_RuntimeError: referenced symbol not found

파이썬 1.5.2, 솔라리스 7, 그리고 gcc 2.95.2아래에서 환경설정 스크립트에 문제가 있습니다. 환경설정은 make 변수에 LINKFORSHARED=-Xlinker-export-dynamic으로 설정되어야 하는데.

Modules/Makefile에서,

수동으로 이 라인을 Modules/Makefile에 삽입하세요. 이것으로 파이썬이 공유 라이브러리 확장을 적재하도록 구축할 수 있습니다 (xxx.so).

3.35. 회귀 테스트에서, test___all__이 성능최적화 모듈에서 실패합니다. 무엇이 문제인가요?

current/lib/profile-calibration.html

그러면 그 회귀 테스트 "test___all__"은 파이썬의 소스 디렉토리에서 "make test"를 사용하지 않고 수동으로 그 회귀 테스트를 실행하였음에도 불구하고 실패할 가능성이 있습니다. 이러한 일은 측정될 성능최적화 모듈을 담고 있는 디렉토리를 포함하도록 PYTHONPATH 환경변수를 설정하게 되면 일어납니다. 아마도 그 성능최적화기를 구형 버전의 프로파일 모듈을 사용하여 측정하셨을 텐데, 그 모듈에는 __all__ 값이 정의되어 있지 않으며, 파이썬 2.1. 버전부로 추가되었습니다.

그 문제는 해결될 수 있는데 그 구형 성능최적화 측정 모듈을 제거하고 최근의 버전을 사용하셔서 새로이 측정하는 것입니다. 일반적으로, 파이썬의 각 버전에 대하여 재-측정할 필요가 있읍니다, 왜냐하면 성능의 특징은 성능최적화에 영향을 주게되면 미묘하게 변경될 수 있기 때문입니다.