Як дізнатися всі попередні версії python, з якими мій код сумісний

Я створив середній проект у python 2.7.3, що містить близько 100 модулів. Я хотів би з'ясувати, з якими попередніми версіями python (наприклад: 2.6.x, 2.7.x) мій код сумісний (перш ніж випустити мій проект у відкритому доступі). Що найпростіше знайти?

Рішення, які я знаю -

  1. Установити кілька версій python і перевірити їх у кожній версії. Але у мене ще немає тестових випадків, тому потрібно визначити їх першими.
  2. Прочитати та порівняти журнал змін у різних версіях python, які я хочу перевірити, і, відповідно, дізнатися.

Прохання надати кращі рішення.

2
Я думаю, вам доведеться порівнювати кожен модуль з окремою версією.
додано Автор Si8, джерело
@ user2246674 це нелегке завдання, оскільки є багато коду. Я вважаю, що спільнота python має кращий спосіб зробити це.
додано Автор Pushpak Dagade, джерело
@mgilson сер, я думаю, що я б насправді розглянути це. : D
додано Автор Pushpak Dagade, джерело
@mgilson сер, я чекав на якийсь інструмент (наприклад, 2to3), який вказує на регіони в моєму коді (як вбудована функція, конструктори класів), реалізація яких відрізняється між різними версіями python я хочу зробити сумісним з; а потім я міг би змінити ці регіональні коди, якщо потрібно. Але я думаю, що такий інструмент є занадто складним або занадто незначним для існування. Не зважай! Я думаю, що ваш шлях буде для мене нормальним. Дякую вам: D
додано Автор Pushpak Dagade, джерело
@mgilson сер, я чекав на якийсь інструмент (наприклад, 2to3), який вказує на регіони в моєму коді (як вбудована функція, конструктори класів), реалізація яких відрізняється між різними версіями python я хочу зробити сумісним з; а потім я міг би змінити ці регіональні коди, якщо потрібно. Але я думаю, що такий інструмент є занадто складним або занадто незначним для існування. Не зважай! Я думаю, що ваш шлях буде для мене нормальним. Дякую вам: D
додано Автор Pushpak Dagade, джерело
Варіант 3, розмістити код і стверджувати, що він працює з усіма версіями пітона. Зачекайте на повідомлення про помилки. Виправляйте звіти про помилки у версіях python, які вам цікаві, перегляньте попередні претензії, щоб виключити повідомлення про помилки, про які вас не цікавить.
додано Автор mgilson, джерело
@Guanidene - FWIW, ось що я роблю :-P ... Серйозно. (хоча я спеціально націлюю python2.6 і вгору і, як правило, все тестую з python2.7)
додано Автор mgilson, джерело

7 Відповіді

Я не знаю способу обійти це без деяких тестових випадків. Навіть якщо ваш код може працювати в старій версії python, немає гарантії, що він працює правильно без набору тестів, які достатньо перевіряють ваш код

2
додано

Набагато простіше з деякими тестами, але ручне тестування може дати вам розумну ідею.

Візьміть далеку назад версію, яку ви сподіваєтеся підтримати, (я б запропонував 2.5.x, але далі, якщо ви повинні - вручну протестувати з цією версією, зберігаючи нотатки про те, що ви робили, і особливо там, де це не вдається, якщо - потім або вирішити проблему, або виконати бінарний пошук, щоб побачити, з якої версії зникає точка (а) збою. Це може працювати ще краще, якщо ви починаєте з версії, яку ви впевнені, що не вийде, 2.0.

1
додано

Набагато простіше з деякими тестами, але ручне тестування може дати вам розумну ідею.

Візьміть далеку назад версію, яку ви сподіваєтеся підтримати, (я б запропонував 2.5.x, але далі, якщо ви повинні - вручну протестувати з цією версією, зберігаючи нотатки про те, що ви робили, і особливо там, де це не вдається, якщо - потім або вирішити проблему, або виконати бінарний пошук, щоб побачити, з якої версії зникає точка (а) збою. Це може працювати ще краще, якщо ви починаєте з версії, яку ви впевнені, що не вийде, 2.0.

1
додано

Ні, те, що ви називаєте, в значній мірі, як це робиться, хоча сторінки «Що нового» та власна документація можуть бути кориснішими, ніж повний список змін. Сумісність з такою величезною, рухається ціллю неможлива для автоматизації навіть частково. Це просто не стільки робота, скільки звучить, тому що:

  1. Деякі люди мають тестові пакети ;-)
  2. Вам не потрібно (як правило) розглядати випуски виправлення помилок (наприклад, 2.7.x для різних x). Можливо, ваш код потребує виправлення помилок, але, як правило, релізи .0 досить надійні, а код, сумісний з x.y.0, може працювати на будь-якій версії x.y.z.
  3. Завдяки політиці зворотної сумісності достатньо встановити мінімальну підтримувану версію, всі більш пізні версії (однієї й тієї ж основної версії) залишаться сумісними. Це не допоможе у вашому випадку, тому що 2.7 - це останній реліз 2.x коли-небудь, але якщо ви націлюєтеся, скажімо, 2.5, то зазвичай не потрібно перевіряти сумісність 2.6 або 2.7.
  4. Якщо ви тримаєте очі відкритими під час кодування, і маєте трохи досвіду, а також хорошу пам'ять, ви будете знати, що використовували деякі функції, які були введені в останній версії. Навіть якщо ви не знаєте, яку саме версію, ви можете швидко переглянути її в документації.
  5. Деякі люди беруть намір підтримувати певну версію і завжди пам'ятають про це під час розробки. Навіть якщо це буде працювати на інших версіях, вони вважатимуть його непідтримуваним і не претендують на сумісність.

Таким чином, ви можете або обмежитися 2.7 (це було три роки), або виконувати тести на старих версіях. Якщо ви просто бажаєте визначити чи є його сумісним, а які невідповідності існують і як їх можна виправити, ви можете:

  1. Пошук нових сторінок для нових функцій, найголовніше новий синтаксис, який ви використовували.
  2. Перевірте обмеження версій використовуваних бібліотек третіх сторін.
  3. Пошук у документації стандартних модулів бібліотеки, які використовуються для нової функціональності.
1
додано

Ні, те, що ви називаєте, в значній мірі, як це робиться, хоча сторінки «Що нового» та власна документація можуть бути кориснішими, ніж повний список змін. Сумісність з такою величезною, рухається ціллю неможлива для автоматизації навіть частково. Це просто не стільки робота, скільки звучить, тому що:

  1. Деякі люди мають тестові пакети ;-)
  2. Вам не потрібно (як правило) розглядати випуски виправлення помилок (наприклад, 2.7.x для різних x). Можливо, ваш код потребує виправлення помилок, але, як правило, релізи .0 досить надійні, а код, сумісний з x.y.0, може працювати на будь-якій версії x.y.z.
  3. Завдяки політиці зворотної сумісності достатньо встановити мінімальну підтримувану версію, всі більш пізні версії (однієї й тієї ж основної версії) залишаться сумісними. Це не допоможе у вашому випадку, тому що 2.7 - це останній реліз 2.x коли-небудь, але якщо ви націлюєтеся, скажімо, 2.5, то зазвичай не потрібно перевіряти сумісність 2.6 або 2.7.
  4. Якщо ви тримаєте очі відкритими під час кодування, і маєте трохи досвіду, а також хорошу пам'ять, ви будете знати, що використовували деякі функції, які були введені в останній версії. Навіть якщо ви не знаєте, яку саме версію, ви можете швидко переглянути її в документації.
  5. Деякі люди беруть намір підтримувати певну версію і завжди пам'ятають про це під час розробки. Навіть якщо це буде працювати на інших версіях, вони вважатимуть його непідтримуваним і не претендують на сумісність.

Таким чином, ви можете або обмежитися 2.7 (це було три роки), або виконувати тести на старих версіях. Якщо ви просто бажаєте визначити чи є його сумісним, а які невідповідності існують і як їх можна виправити, ви можете:

  1. Пошук нових сторінок для нових функцій, найголовніше новий синтаксис, який ви використовували.
  2. Перевірте обмеження версій використовуваних бібліотек третіх сторін.
  3. Пошук у документації стандартних модулів бібліотеки, які використовуються для нової функціональності.
1
додано

1) Якщо ви збираєтеся підтримувати сумісність з попередніми версіями, тестування - це шлях. Навіть якщо ваш код зараз сумісний, він може припинити бути таким у будь-який момент у майбутньому, якщо ви не звернете увагу.

2) If backwards compatibility is not an objective but just a "nice side-feature for those lucky enough", an easy way for OSS is to let users try it out, noting that "it was tested in but may work in previous ones as well". If there's anyone in your user base interested in running your code in an earlier version (and maintain compatibility with it), they'll probably give you feedback. If there isn't, why bother?

1
додано

1) Якщо ви збираєтеся підтримувати сумісність з попередніми версіями, тестування - це шлях. Навіть якщо ваш код зараз сумісний, він може припинити бути таким у будь-який момент у майбутньому, якщо ви не звернете увагу.

2) If backwards compatibility is not an objective but just a "nice side-feature for those lucky enough", an easy way for OSS is to let users try it out, noting that "it was tested in but may work in previous ones as well". If there's anyone in your user base interested in running your code in an earlier version (and maintain compatibility with it), they'll probably give you feedback. If there isn't, why bother?

1
додано
ІТ КПІ - Python
ІТ КПІ - Python
625 учасників

Канал обговорень про всякі штуки зі світу пайтону. Прохання: 0. мати повагу одне до одного; 1. не матюкатися в сторону людей; 2. не захламляти тред повідомленнями по одному слову;