J'ai créé un module dans Python qui fournit une douzaine de fonctionnalités. Bien que cela soit principalement utilisé de Python, il existe une bonne fraction d'utilisateurs hérités qui l'appelleront de Perl.
Quelle est la meilleure façon de faire un branchement de ce module? Mes pensées sont:
système
- Créez une sorte de serveur et gérer les appels RPC (par exemple, via JSON RPC)
Tout conseiller?
3 Réponses :
Un autre choix est d'inline Python directement dans votre script Perl, en utilisant Inline :: python .
Ceci peut être plus simple que d'autres solutions et nécessite uniquement un module supplémentaire.
Inline :: Python fonctionne assez bien, il peut y avoir une certaine étrangeté lors de la réussite de certains types de variables.
Merci. J'ai aimé toutes les réponses, mais cela semble très portable.
Fournissez les fonctionnalités comme des utilitaires de ligne de commande et apportez des appels système
fonctionne vraiment bien. Ceci est la façon dont les programmes tels que Python (et Perl) sont destinés à être utilisés.
Difficile de battre simple et bien testé, n'est-ce pas?
Sauf bien sûr, s'ils doivent être exécutés dans un environnement où le coût de démarrage d'un interprète python (nombre d'exécutions attendus) est trop élevé. Comme une application ou un serveur Web, comme exemple. La manière dont Perl est censée être utilisée de manière appropriée de la situation.
@DVK: Python peut être utilisé de différentes manières, également, chacune appropriée à différentes situations. Savez-vous quelle situation s'applique à cette question?
@ S.Lott - Je ne sais pas, mais je pense que vous ne le savez pas aussi, mais vous recommandez une solution sans expliquer explicitement quelles circonstances il convient. Et, pour être honnête, le fait que l'OP a mentionné un serveur avec des appels RPC incline un pour penser qu'il y avait probablement Quelques raisons la raison pour laquelle ils n'ont pas considéré la ligne de commande système () Appels pour être la solution extrême
@DVK: Mon point était que vous semblez trop critiques d'une solution valide sans une base réelle en fait. Vous pourriez - par exemple, demander des éclaircissements de la personne qui postive la question plutôt que de faire des hypothèses. Je trouve que beaucoup de gens ignorent le modèle de conception de la conception unix standard de beaucoup de processus coopérants. S'il s'agit d'un pipeline entre Perl et Python (où les deux processus fonctionnent pendant la durée du calcul), il n'y a presque pas de fourchette. Donc, je préférerais que vous soyez sur la dureté de vos critiques. Vous pouvez avoir raison. Mais aucun de nous ne le sais, n'est-ce pas?
@DVK: L'OP a également affiché la ligne de commande et les appels de système comme une option considérée, donc il semble qu'il n'avait pas dit cela (encore) pour des raisons de performance. Il est difficile de déboguer un appel système plutôt que de RPC ou de InLine :: python qui est sur la version 0.21 Toutes les choses étant égales et performances ne sont pas une contrainte. L'OP n'a pas posté la performance comme une préoccupation.
@ Arewk (et S.Lott) - le fait que l'OP n'a rien dit de la performance pourrait signifier qu'ils s'en foutent; ou qu'ils ne savent pas qu'il y a une pénalité de performance (tout le monde n'a pas rencontré cet piège particulier); Ou qu'ils ne connaissent pas tout à fait l'analyse complète des coûts / avantages des solutions possibles (ce dernier serait mon évaluation si je devais en choisir un). Mon point est que recommander la solution de ligne de commande sans fournir une telle analyse des coûts / avantages (et dans l'abcence de la preuve que l'OP était au courant) est un mauvais service potentiel à l'OP.
@ S.Lott - Désolé, je ne voulais pas avoir son sonner "dur" - J'essayais essentiellement d'améliorer / clarifier votre réponse en qualifiant plus de contexte approprié. Si je voulais être dur, ce serait un bowvote, pas un commentaire :) ... maintenant ... dire que Perl est signifiait à utiliser sur un système de ligne de commande à une personne qui a fait à la fois des serveurs Perl et Perl Développement Web pour vivre - c'est dur :)
@DVK: "Recommander la solution de ligne de commande sans fournir une telle analyse de coûts / avantages" s'il vous plaît. N'hésitez pas à poster une analyse coûts-avantages que vous voyez en forme. Je n'ai aucune idée de quelle base vous utiliserez, mais c'est à vous de répondre. Faites attention à la façon dont vous critiquez d'autres solutions simples, viables, viables et viables.
La performance n'est pas aussi importante dans mon cas à ce stade. Les scripts seront appelés quelques fois par jour et leur temps d'exécution sera considérablement nain le temps de démarrage. Discussion utile cependant.
À court terme La solution la plus facile est d'utiliser Inline :: Python. Suivi de près en appelant un script de ligne de commande.
à long terme, à l'aide d'un serveur pour fournir une fonctionnalité RPC ou simplement appeler un script de ligne de commande vous donnera la solution la plus future de la preuve.
Pourquoi?
Becuase de cette façon, vous n'êtes pas attaché à Perl ou à Python comme langue utilisée pour construire les systèmes qui consomment les services fournis par votre bibliothèque. L'une ou l'autre méthode crée une interface transparente et indépendante de la langue que vous pouvez utiliser avec tout environnement de développement que vous adoptez.
Selon vos besoins, toutes les options présentées peuvent être le "meilleur choix". Selon la manière dont vos besoins évoluent avec le temps, un choix différent peut être révélé comme "meilleur".
Mon approche consiste à poser quelques questions:
À quelle fréquence changez-vous des outils de développement? Vous avez changé de python de Perl. Avez-vous commencé avec TCL et allez-vous à Perl? Allez-vous passer à la nouvelle langue excitante x en 1, 5 ou 10 ans? Si vous modifiez des outils "souvent" (tout ce que cela signifie) souligner la compatibilité des outils croisés.
À quelle vitesse est assez rapide? Le temps de démarrage des solutions de ligne de commande est-elle correcte? Est-ce que Inline :: Python ralentit trop de choses (vous initialisez toujours un interprète Python, cela vient d'intégrer à votre interprète Perl)?
Sur la base des réponses à ces questions, je voudrais faire la chose la plus simple susceptible de fonctionner .
Je suppose que c'est que cela signifie pour: