앞으로 몇 년 동안 계속 실행될 코드 작성

프로그래밍 언어가 변경되었습니다. 라이브러리가 변경됩니다. 5 년, 10 년 또는 20 년 전의 일부 코드는 계속 실행되어 예상 결과를 생성 할 수 있지만 2 년의 일부 코드는 구문 오류로 실패 할 수 있습니다. 언어가 진화하기 때문에 (적어도 대부분의 경우) 이것은 부분적으로 불가피하다. 개발자는 코드를 관리 할 책임이 있습니다. 그러나 때로는 프로덕션 코드에서 안정성이 중요한 요구 사항이므로 코드를 언어 변경에 매년 적용 할 필요없이 코드를 10 년 동안 실행해야합니다. 또는 과학적 데이터 분석과 같은 작은 스크립트를 사용하여 몇 년 동안 만지지 않은 후에 다시 방문해야 할 수도 있습니다. 예를 들어, 기상청에서는 속도가 빠르지 않은 부분에도 많은 Fortran 코드가 작동하며 코드 안정성이 그 이유 중 하나입니다. 나는’ 불안정성에 대한 두려움은 파이썬으로 옮겨가는 것에 대한 객체 중 하나입니다 (물론 언어 관성 제외. 오래된 코드에 의존하지 않는 새로운 코드에서만 가능합니다). 물론 안정적인 코드를위한 한 가지 전략은 전체 운영 체제를 동결하는 것입니다. 그러나 이것이 항상 실현 가능한 것은 아닙니다.

예를 들어 Python을 사용하고 있지만 문제는 특히 Python에만 국한되지 않습니다.

파이썬 호환성 문제에 관한 문서

Python의 경우 이전 버전과 호환되지 않는 변경에 대한 정책을 간략하게 설명하는 여러 문서가 있습니다.

PEP-5

PEP 5 에 따르면 :

Python의 과도기 버전의 릴리스와 이전 버전과 호환되지 않는 버전의 릴리스 사이에 최소 1 년의 전환 기간이 있어야합니다. 사용자는 최소 1 년 동안 프로그램을 테스트하고 더 이상 사용되지 않는 구문 사용에서 대체 프로그램으로 마이그레이션해야합니다.

개인적으로 1 년은 다소 짧습니다. 그것은 내가 약간의 코드를 작성할 수 있다는 것을 의미하며, 지금으로부터 1 년 반 후에는 더 이상 실행되지 않을 것입니다.

PEP 291

PEP 291 에는 이전 버전과의 호환성을 유지하기 위해 피해야 할 사항에 대한 불완전한 지침 목록이 포함되어 있습니다. 그러나 Python 2.x에만 관련됩니다. Python 2.7은 2.x 시리즈의 최종 릴리스이고 Python 2.7은 버그 수정 전용이므로이 PEP는 이제 역사적인 관심사입니다.

PEP 387

이전 버전과 호환되지 않는 변경 사항에 대해서는 PEP 387 도 있습니다 . PEP 387은 공식 정책이 아닌 초안입니다. 2009 년 6 월, 이것은 Python-ideas mailing-list 에서 논의되었습니다 . 토론의 일부는 개발자가 언어 변경에 대해 강력한 코드를 작성하는 방법에 중점을 두었습니다. 한 게시물 에는 하지 말아야 할 것에 대한 조언이 나와 있습니다 .

이것과 함께 아마도 대부분의 경우에 참으로 추측 할 수있는 몇 가지 규칙이 있습니다 :로 시작하는 것을 호출 "_"하지 말고, 원숭이 패치를하지 말고, 자신이 아닌 클래스의 객체에 동적 클래스 대체를 사용하지 마십시오 상속 깊이 계층 (예 : no ".__bases__[0].__bases__[0]") 에 의존하지 말고 DeprecationWarnings를 생성하지 않고 테스트를 실행하고 다른 라이브러리에서 상속되는 클래스에 속성을 추가 할 때 네임 스페이스 충돌 가능성을 염두에 두십시오. 나는이 모든 것들이 한곳에 쓰여 있다고 생각하지는 않습니다.

또한 “광산 필드”(새로운 기능이 변경 될 수 있음) 및 “냉동 영역”(실제로 판매되지 않은 API는 변경되지 않음)에 대한 몇 가지 사항이있었습니다. Antoine Pitrou 인용 :

“냉동 영역”은 부정적 (명시 적 “광장”)이 아니라 긍정적 (명시 적 공개 API 및 명시 적으로 보장 된 행동)으로 정의되어야한다고 생각합니다. 그렇지 않으면, 우리는 지뢰밭에 중요한 것들을 넣는 것을 잊어 버리고 나중에 그 것들을 거꾸로 호환되지 않는 방식으로 바꿔야 할 때 물릴 것입니다.

이 글에서 어떤 결론도 나오지 않지만, 내가 찾고있는 핵심에 가깝습니다. 스레드는 거의 4 년이되었으므로 상황이 변경되었거나 개선되었을 수 있습니다. 어떤 종류의 코드가 살아남을 가능성이 있으며 어떤 코드가 더 취약합니까?

포팅 지침

위에서 설명한 문서 외에도 각 Python 버전에는 포팅 지침 ( Python 3.2 로 포팅 , Python 3.3으로 포팅 등)이 제공됩니다.

유용한 호환성

PEP 3151 은 유용한 호환성 개념을 소개했습니다 . 내 말로는, 이것은 코드가 신중하게 작성된 경우에만 언어 개발자가 호환성을 유지하기 위해주의해야한다는 생각으로 귀결됩니다. 실제로 유용한 호환성을 정의하지는 않지만 위의 PEP 387 토론에서 인용 한 아이디어와 비슷하다고 생각합니다.

프로그래머의 관점에서

프로그래머로서, 나는 미래에 파이썬이 변할 것이며, 사람들, 특히 나 자신은 1 년, 2 년, 또는 3 개의 부 버전의 파이썬 버전에서 몇 년 후부터 내 코드를 실행하려고 시도한다는 것을 알고 있습니다. 모든 것이 호환되지는 않으며 실제로 실패 할 코드를 쉽게 만들 수 있습니다 (한 번 코드를 언급 한 적이 있음 if sys.version[:3] != '2.3': print 'Wrong version, exiting'). 내가 찾고 있는 것은 향후에도 코드가 변경되지 않을 가능성을 높이기 위해해야 할 일과 하지 말아야 할 일 에 대한 일련의 지침입니다 .

그러한 지침이 있습니까? 앞으로도 계속 실행될 Python 코드를 작성하려면 어떻게해야합니까?

내 질문은 파이썬 코어, 표준 라이브러리뿐만 아니라 일반적으로 사용되는 애드온 라이브러리, 특히 numpy, scipy와 관련이 matplotlib있습니다.

편집 : 지금까지 두 가지 답변은 python2 대 python3과 관련이 있습니다. 이것은 내가 의미하는 것이 아닙니다. Python2에서 Python3으로 마이그레이션하는 도구에 대해 알고 있습니다. 내 질문은 아직 언어 변경에 관한 것 입니다. 보다 안정적인 코딩 지침을 찾는 데 수정 구슬 보다 더 나은 방법을 사용할 수 있습니다 . 예를 들면 다음과 같습니다.

• import modulefrom module import *후자는 module하나 이상의 새로운 함수 / 클래스 가 커지면 코드를 깨뜨릴 수 있기 때문에 보다 미래 지향적 입니다.

• 문서화되지 않은 것은 아직 안정되지 않은 표시 일 수 있기 때문에 문서화되지 않은 방법을 사용하는 것은 문서화 된 방법을 사용하는 것보다 미래에 덜 적합 할 수 있습니다.

내가 따르는 그런 실용적인 코딩 조언입니다. 현재 → 미래에 관한 것이므로 Python2는 더 이상 변경되지 않으므로 Python3으로 제한 할 수 있습니다.

답변