Написання коду, який триватиме відтепер років
Змінюються мови програмування. Змінюються бібліотеки. Деякий код від 5, 10 або навіть 20 років тому все ще може працювати і давати очікувані результати, тоді як деякий код за 2 роки може вийти з ладу з синтаксичною помилкою. Частково це неминуче, оскільки мови розвиваються (принаймні, більшість). Розробники несуть відповідальність за збереження свого коду. Але іноді стабільність є важливою вимогою у виробничому коді, і код повинен просто працювати протягом 10 років, не вимагаючи того, щоб хтось перебирав код щороку, щоб адаптувати його до мовних змін. Або у мене можуть бути невеликі сценарії, наприклад, для наукового аналізу даних, які мені потрібно переглянути, після того, як їх не торкаються роками. Наприклад, у метеорологічних кабінетах є багато функціональних кодів Фортран навіть для нешвидкісних деталей, і стабільність коду є однією з причин. Я ' Ви чули, що страх перед нестабільністю є одним із об'єктів, які вони мають проти переходу на Python (окрім мовної інерції, звичайно, можливий лише новий код, не залежний від старого коду). Звичайно, одна стратегія стабільного коду - заморозити всю операційну систему. Але це не завжди можливо.
Я використовую Python як, наприклад, але проблема не обмежується зокрема Python.
Документи з питань сумісності Python
У випадку з Python існує декілька документів, які окреслюють політику щодо невідповідних змін.
PEP-5
Відповідно до PEP 5 :
Між випуском перехідної версії Python та випуском назад несумісної версії повинен бути принаймні річний перехідний період. Користувачі матимуть щонайменше рік для тестування своїх програм та перенесення їх із використання застарілої конструкції на альтернативну.
Особисто я вважаю, що один рік досить короткий. Це означає, що я можу написати якийсь код, і через півтора року він більше не працюватиме.
PEP 291
PEP 291 містить неповний перелік настанов речей, яких слід уникати, щоб зберегти відсталу сумісність. Однак це стосується лише Python 2.x. Оскільки Python 2.7 є остаточним випуском у серії 2.x, а Python 2.7 - лише виправлення, цей PEP зараз представляє лише історичний інтерес.
PEP 387
Існує також PEP 387 щодо невідповідних змін. PEP 387 - це проект, а не офіційна політика. У червні 2009 року це обговорювалося у списку розсилки Python-ідеї . Частина дискусії була присвячена тому, як розробники можуть писати код, який є надійним щодо мовних змін. В одному дописі були перелічені поради щодо того, що не робити :
Поряд з цим існує декілька правил, які ви можете зробити висновки, які, мабуть, вірні більшу частину часу: не називайте речі, починаючи з
"_"цього, не мавпуйте нічого, не виправляйте нічого, не використовуйте динамічну заміну класів на об'єкти з інших класів, ніж ваш власний , не залежайте від глибини ієрархій успадкування (наприклад, ні".__bases__[0].__bases__[0]"), переконайтеся, що ваші тести виконуються без створення будь-яких попереджувальних попереджень, пам’ятайте про можливі конфлікти в просторі імен, додаючи атрибути до класів, які успадковують з інших бібліотек. Я не думаю, що всі ці речі записані в одному місці.
Крім того, були деякі пункти щодо "шахтних полів" (нові можливості, можливо, зміниться) та "заморожених ділянок" (дуже продані API практично гарантовано не змінюються). Цитуючи Антуана Пітру :
Я думаю, що "заморожену область" слід визначати позитивно (явні публічні API та явно гарантована поведінка), а не негативно (явне "поле шахти"). Інакше ми забудемо помістити деякі важливі речі на мінне поле і пізніше покусаємо, коли нам потрібно змінити ці речі назад-несумісним способом.
Здається, не існує жодного висновку з цієї теми, але він наближається до основи того, що я шукаю. Нитці майже чотири роки, тому, можливо, ситуація змінилася або покращилася. Який код, ймовірно, збережеться, а який код більш крихкий?
Настанови щодо перенесення
Окрім вищезазначених документів, кожна версія Python має вказівки щодо перенесення : перенесення на Python 3.2 , перенесення на Python 3.3 тощо.
Корисна сумісність
PEP 3151 ознайомив мене з концепцією корисної сумісності . З моїх власних слів, це зводиться до думки, що лише якщо код ретельно написаний мовою, розробникам потрібно бути обережними для збереження сумісності. Це насправді не визначає корисну сумісність , але я думаю, що це схоже на ідеї, які я цитував з обговорення PEP 387 вище.
З точки зору програмістів
Як програміст, я знаю, що Python зміниться в майбутньому і що люди - особливо я сам - спробують запустити мій код, можливо, через кілька років у версії Python, що становить одну, дві чи, можливо, три незначні версії. Не все буде сумісним, і насправді легко придумати код, який не вдасться (я колись стикався із зазначенням коду if sys.version[:3] != '2.3': print 'Wrong version, exiting'). Що я шукаю - це набір вказівок щодо того, що робити, а що не робити, щоб підвищити шанси на те, що мій код все ще залишиться незмінним у майбутньому.
Чи є такі настанови? Як написати код Python, який все ще буде працювати в майбутньому?
Моє питання відноситься як до ядра Python, в стандартній бібліотеці, а й часто використовувані додатки бібліотек, зокрема numpy, scipy, matplotlib.
EDIT : Поки дві відповіді стосуються python2 проти python3. Це я не маю на увазі. Я знаю про інструменти для міграції з Python2 на Python3. Моє запитання стосується мовних змін, які ще не відбудуться . Ми можемо зробити краще, ніж кришталевий куля, знайти більш стабільні вказівки щодо кодування. Наприклад:
import moduleє більш захищеним від майбутньогоfrom module import *, тому що останній може порушити код, якщоmoduleзростає одна чи кілька нових функцій / класів.Використання незадокументованих методів може бути менш надійним у майбутньому, ніж використання документально підтверджених методів, оскільки щось без документації може бути ознакою того, що щось ще не є стабільним.
Саме такі практичні поради з кодування я дотримуюся. Оскільки мова йде про теперішнє → майбутнє, ми можемо обмежитися Python3, оскільки Python2 більше не збирається змінюватися.