Досвід Python "PEP-302 нових імпортних гачків" [закрито]

Я один із розробників Ruby (CRuby). Ми працюємо над релізом Ruby 2.0 (планується до випуску 2012 / лютий).

У Python є "PEP302: нові імпортні гачки" (2003):

Цей PEP пропонує додати новий набір гачків імпорту, які пропонують кращу налаштування механізму імпорту Python. На відміну від поточного гачка імпорту , в існуючу схему може бути введений новий гачок, що дозволяє чіткіше контролювати те, як знаходять модулі та як вони завантажуються.

Ми розглядаємо можливість введення функції Ruby 2.0 у Ruby 2.0 (CRuby 2.0). Я хочу зробити пропозицію, яка може переконати Маца. В даний час CRuby може завантажувати сценарії лише з файлових систем стандартним чином.

Якщо у вас є досвід чи роздуми щодо PEP 302, будь ласка, поділіться.

Приклад:

1. Це чудова специфіка. Не потрібно його міняти.
2. Це майже добре, але у нього є ця проблема ...
3. Якби я міг повернутися до 2003 року, то змінив би специфікацію на ...

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

Одне, що шкодить PEP 302 в Python, - це те, як довго нам знадобилося перетворити основну систему імпорту на її використання. Більшу частину десятиліття кожен, хто робив що-небудь складне з гачками імпорту, застряг, реалізуючи дві частини: одна обробка навантажувачів, сумісних з PEP 302 (наприклад, імпорт поштових індексів), а друга - обробка стандартного механізму імпорту на основі файлової системи. Лише в наступному 3.3, що обробка навантажувачів PEP 302 також подбає про обробку модулів, імпортованих через стандартний механізм імпорту файлової системи. Намагайтеся не повторювати цю помилку, якщо зможете її уникнути.

PEP 420 (реалізований для Python 3.3) вносить деякі доповнення до протоколу, щоб дозволити імпортерам внести частини до пакетів простору імен. Він також виправляє проблему з називанням у визначенні API Finder (ефективно замінюючи неправильно названий "find_module" на більш точний "find_loader"). Сподіваємось, це все буде чіткіше зафіксовано в мовній специфікації до моменту, коли 3.3rc1 розгортається за пару тижнів.

Ще одна помітна проблема полягає в тому, що підхід, зафіксований спеціально в PEP 302, має надто багато глобального стану. Не йдіть за нами по цьому шляху - спробуйте інкапсулювати стан у більш цілісну об'єктну модель, щоб було легше вибірково імпортувати інші модулі (модулі розширення C є основою зробити будь-яку таку капсуляцію повністю ефективною, але навіть деякий рівень інкапсуляції може бути корисним).

PEP 406 (http://www.python.org/dev/peps/pep-0406/) обговорює можливу назад сумісну еволюцію підходу Python із покращеним станом інкапсуляції. Якщо у вас є модель інкапсульованого стану з самого початку, тоді ви можете відповідно визначити свої API та уникати доступу імпортерів та навантажувачів до глобального стану (замість того, щоб передавати посилання на активний двигун).

Ще один недолік у PEP 302 - це можливість запитати імпортера щодо ітератора щодо модулів, наданих цим імпортером (це необхідно для таких речей, як утиліти заморожування та автоматичні утиліти документації, які витягують документи). Оскільки це неймовірно корисно, вам, мабуть, буде краще стандартизувати його з початку: http://docs.python.org/dev/library/pkgutil#pkgutil.iter_modules (ми, мабуть, нарешті піднесемо це до формально зазначеного API в Python 3.4)

І мій останній коментар: ви повинні уважно ознайомитися з розподілом відповідальності між системою імпорту та об'єктами завантажувача. Зокрема, розглянемо розбиття API "load_module" на окремі етапи "init_module" та "exec_module". Це повинно дозволити вам мінімізувати ступінь, в якій навантажувачі повинні безпосередньо взаємодіяти зі станом імпорту.

PEP 302 та importlib - це чудова відправна точка для більш гнучкої системи імпорту, але ми неодмінно помилилися, яких варто уникати.

Поруч з ncoghlan я - інший супровід системи імпорту Python і автор його поточної реалізації, importlib (http://docs.python.org/dev/py3k/library/importlib.html). Все, що Нік сказав, я згоден, тому просто хочу додати додаткову інформацію.

По-перше, не покладайтеся занадто сильно на PEP 302 безпосередньо, а натомість подивіться на те, що забезпечує importlib з точки зору абстрактних базових класів тощо. Для зворотної сумісності речі повинні бути сумісні з PEP 302, але мені довелося додати частину моїх власні API, щоб закінчити розробку підтримки для справжньої гнучкості.

Ще одним важливим моментом є те, що ви надаєте розробникам два фрагменти гнучкості. Перша - це можливість зберігати код іншим способом, ніж просто безпосередньо у файловій системі як окремі файли (я називаю це резервним файлом для імпорту), наприклад, це дозволяє коду жити у поштовому файлі, базі даних sqlite тощо Інша підтримка полягає в тому, щоб дозволити керувати кодом до або після процесу певним чином, наприклад, Кіхот (https://www.mems-exchange.org/software/quixote/) та його альтернативне використання рядкових літералів, які не призначені змінна була б набагато легшою для підтримки.

Хоча останній рідко потрібен, перший - це те, де вам потрібно переживати за підтримку. І саме тут ви практично переосмислюєте API взаємодії файлової системи. Оскільки деяким людям потрібні активи, що зберігаються у вигляді файлів із кодом, вам потрібно надати хороший спосіб для читання файлів, виявлення файлів тощо. Нам все ж потрібно реалізувати частину API для виявлення наявних файлів даних, перерахування їх тощо. .

Але тоді у вас також є потреба в API, які залежать від коду. Як згадував Нік, вам знадобиться API, щоб дізнатися, які модулі містить пакунок тощо, які не залежать від файлу. Існує ця дивна дуальність мати API для роботи з модулями, де ви вилучили концепцію файлів, але потім вам потрібно надати API для доступу до даних активів, схожих на файли. І як тільки ви намагаєтесь втілити одне в інше, щоб уникнути дублювання, води стають по-справжньому мутними (тобто люди в кінцевому підсумку покладаються на очікуване структурування файлового шляху тощо), не звертаючи уваги на те, що шлях може не бути справжнім шляхом тому що це для zipfile, що містить код, а не просто файл). IOW, вам в кінцевому підсумку доведеться реалізувати два подібних API, але вам буде краще для цього в перспективі.

Як сказав Нік, наше рішення є хорошою відправною точкою, але це не так, як я би це зробив сьогодні, якби я розробляв API з нуля.

PEP 302 дозволяє підключитися до механізму імпорту Python, це означає, що ви можете імпортувати код з інших джерел, таких як бази даних, поштові файли тощо.

У реалізації імпорту Python існує довга історія складності, яка лише скоро буде спрощена введенням імпорту Python імпорту.

Я б радив довго і наполегливо думати над кутовими справами. Тоді ви, ймовірно, отримаєте корисну реалізацію.