Expérience des «nouveaux crochets d'importation PEP-302» de Python [fermé]

Je suis l'un des développeurs de Ruby (CRuby). Nous travaillons sur la version 2.0 de Ruby (prévue pour 2012 / février).

Python a "PEP302: Nouveaux crochets d'importation" (2003):

Ce PEP propose d’ajouter un nouvel ensemble de points d’accès à l’importation offrant une meilleure personnalisation du mécanisme d’importation Python. Contrairement au hook d’ importation actuel , un hook de style nouveau peut être injecté dans le schéma existant, ce qui permet un contrôle plus fin du mode de recherche des modules et de leur chargement.

Nous envisageons d'introduire une fonctionnalité similaire à PEP302 dans Ruby 2.0 (CRuby 2.0). Je veux faire une proposition qui peut persuader Matz. Actuellement, CRuby peut charger des scripts de manière standard uniquement à partir de systèmes de fichiers.

Si vous avez une expérience ou une considération à propos du PEP 302, veuillez le partager.

Exemple:

1. C'est une bonne spécification. Pas besoin de le changer.
2. C'est presque bien, mais il a ce problème ...
3. Si je pouvais revenir à 2003, je modifierais les spécifications en ...

Je suis le responsable du module runpy de Python et l'un des responsables du système d'importation actuel. Bien que notre système d'importation soit extrêmement flexible, je vous conseillerais de ne pas l'adopter en gros sans faire quelques ajustements - en raison de problèmes de compatibilité, il y a beaucoup de choses qui sont plus délicates qu'elles ne l'auraient autrement été.

Une chose qui fait mal avec PEP 302 en Python est le temps qu’il nous a fallu pour convertir le système d’importation principal pour l’utiliser. Pendant une bonne partie de la décennie, tous les utilisateurs complexes utilisant des crochets d'importation ont été bloqués pour implémenter deux éléments: l'un manipulant des chargeurs conformes PEP 302 (tels que les importations zip) et l'autre gérant le mécanisme d'importation basé sur un système de fichiers standard. Ce n'est que dans la prochaine version 3.3 que la gestion des chargeurs PEP 302 se chargera également de la gestion des modules importés via le mécanisme d'importation de système de fichiers standard. Essayez de ne pas répéter cette erreur si vous pouvez éventuellement l'éviter.

PEP 420 (implémenté pour Python 3.3) apporte quelques ajouts au protocole afin de permettre aux importateurs de contribuer des portions à des packages d’espaces de noms. Il corrige également un problème de dénomination dans la définition de l'API du Finder (remplacer efficacement le "find_module" mal nommé par le "find_loader" plus précis). Espérons que tout ceci devrait être documenté plus clairement dans les spécifications de langage d’ici à ce que 3.3rc1 arrive dans quelques semaines.

Un autre problème notable est que l’approche documentée spécifiquement dans le PEP 302 comporte beaucoup trop d’états globaux de processus. Ne nous suivez pas dans cette voie. Essayez d'encapsuler l'état dans un modèle d'objet plus cohérent afin de faciliter l'importation sélective d'autres modules. peut être utile).

PEP 406 (http://www.python.org/dev/peps/pep-0406/) discute d’une possible évolution rétrocompatible de l’approche de Python avec une meilleure encapsulation d’états. Si vous avez un modèle d'état encapsulé depuis le début, vous pouvez alors définir vos API en conséquence et éviter que les importateurs et les chargeurs accèdent à l'état global (au lieu de recevoir une référence au moteur actif).

Une autre pièce manquante du PEP 302 est la possibilité de demander à un importateur un itérateur sur les modules fournis par cet importateur (cela est nécessaire pour des choses telles que les utilitaires de gel et les utilitaires de documentation automatiques qui extraient des docstrings). Comme il est incroyablement utile, vous feriez mieux de le normaliser dès le départ: http://docs.python.org/dev/library/pkgutil#pkgutil.iter_modules (nous allons probablement élever celui-ci à un format formellement spécifié). API en Python 3.4)

Et mon dernier commentaire est que vous devriez examiner de près la répartition des responsabilités entre le système d'importation et les objets du chargeur. En particulier, envisagez de scinder l'API "load_module" en étapes "init_module" et "exec_module" distinctes. Cela devrait vous permettre de minimiser le degré auquel les chargeurs doivent interagir directement avec l'état d'importation.

PEP 302 et importlib sont un excellent point de départ pour un système d’importation plus flexible, mais nous avons certainement commis des erreurs qui méritent d’être évitées.

À côté de ncoghlan, je suis l'autre responsable du système d'importation de Python et l'auteur de son implémentation actuelle, importlib (http://docs.python.org/dev/py3k/library/importlib.html). Tout ce que Nick a dit, je suis d’accord avec, alors je veux juste ajouter quelques informations supplémentaires.

Premièrement, ne vous fiez pas trop à PEP 302 directement, mais plutôt à ce que importlib fournit en termes de classes de base abstraites, etc. Pour des raisons de compatibilité ascendante, les choses devaient être compatibles avec PEP 302, mais je devais ajouter certains de mes propres API afin de finir de compléter le support pour une véritable flexibilité.

Un autre point important est que vous accordez aux développeurs deux éléments de flexibilité. L'un est la possibilité de stocker le code autrement que directement sur le système de fichiers sous forme de fichiers individuels (j'appelle cela le back-end de stockage pour les importations), par exemple, cela permet au code de vivre dans un fichier zip, une base de données sqlite, etc. L’autre support consiste à permettre au contrôle de pré-ou post-traiter le code d’une certaine manière, par exemple Quixote (https://www.mems-exchange.org/software/quixote/) et son utilisation alternative de littéraux chaîne non affectés à une variable serait beaucoup plus facile à supporter.

Bien que ce dernier soit rarement nécessaire, vous devez vous soucier du soutien dans le premier cas. Et c'est là que vous vous retrouvez pratiquement en train de redéfinir les API d'interaction de système de fichiers. Étant donné que certaines personnes ont besoin d'actifs stockés sous forme de fichiers avec leur code, vous devez fournir un bon moyen de lire des fichiers, de découvrir des fichiers, etc. Nous devons toujours implémenter la partie de l'API permettant de découvrir quels fichiers de données sont disponibles, de les lister, etc. .

Mais vous avez également besoin d’API spécifiques au code. Comme Nick l'a mentionné, vous avez finalement besoin d'API pour découvrir les modules qu'un paquet contient, etc., qui ne sont pas spécifiques à un fichier. Il existe cette étrange dualité de disposer d'API pour traiter des modules dans lesquels vous avez extrait le concept de fichiers, mais vous devez alors fournir des API pour accéder à des données d'actif de type fichier. Et dès que vous essayez d'implémenter l'un par rapport à l'autre pour éviter les doublons, les eaux deviennent vraiment troubles (les utilisateurs finissent par se fier à la structuration attendue du chemin des fichiers, etc. sans prêter attention au fait que le chemin peut ne pas être un vrai chemin. parce qu’il s’agit d’un fichier zip contenant du code et pas seulement un fichier). IOW, vous finirez par devoir mettre en œuvre deux API similaires, mais vous en bénéficierez mieux à long terme.

Comme Nick l'a dit, notre solution est un bon point de départ, mais ce n'est pas ce que je ferais aujourd'hui si je concevais l'API à partir de zéro.

PEP 302 vous permet de vous connecter au mécanisme d'importation Python, ce qui signifie que vous pouvez importer du code à partir d'autres sources telles que des bases de données, des fichiers zip, etc.

Dans l'implémentation Python des importations, il existe une longue histoire de complexité qui ne sera bientôt simplifiée que par l'introduction d'une implémentation Python d'importation.

Je conseillerais de réfléchir longuement aux cas de coin. Ensuite, vous aurez probablement une implémentation utile.