Je publie cette réponse tardive principalement parce que Google aime cette question.
Je pense que la question et le contexte devraient vraiment porter sur le flux de travail, et non sur les outils. La philosophie générale est toujours "Utiliser le bon outil pour le travail". Mais avant cela, il y a une chose que beaucoup oublient souvent lorsqu'ils se perdent dans les outils : "Faites le travail."
Lorsque j'ai un problème qui n'est pas complètement défini, je commence presque toujours par Bash. J'ai résolu des problèmes épineux dans de grands scripts Bash qui sont à la fois lisibles et faciles à maintenir.
Mais à partir de quand le problème commence-t-il à dépasser ce qu'il faut demander à Bash ? J'ai quelques contrôles que j'utilise pour me donner des avertissements :
- Est-ce que je regrette que Bash ne dispose pas de tableaux en 2D (ou plus) ? Si oui, il est temps de réaliser que Bash n'est pas un grand langage de traitement de données.
- Est-ce que je fais plus de travail de préparation de données pour d'autres utilitaires que je ne fais fonctionner ces utilitaires ? Si oui, il est temps de réaliser que Bash n'est pas un excellent langage de traitement des données.
- Mon script devient-il tout simplement trop gros à gérer ? Si oui, il est important de réaliser que si Bash peut importer des bibliothèques script, il ne dispose pas d'un système de paquets comme les autres langages. C'est vraiment un langage "roll your own" comparé à la plupart des autres. Là encore, il dispose d'une énorme quantité de fonctionnalités intégrées (certains disent trop...).
Et la liste est encore longue. En fin de compte, lorsque vous travaillez plus dur pour faire fonctionner vos scripts que pour ajouter des fonctionnalités, il est temps de quitter Bash.
Supposons que vous ayez décidé de transférer votre travail vers Python. Si vos scripts Bash sont propres, la conversion initiale est assez simple. Il existe même plusieurs convertisseurs/traducteurs qui effectuent le premier passage pour vous.
La question suivante est : à quoi renoncez-vous en passant à Python ?
-
Tous les appels à des utilitaires externes doivent être enveloppés dans quelque chose de l'option subprocess
(ou équivalent). Il y a plusieurs façons de faire cela, et jusqu'à la version 3.7, il fallait faire des efforts pour y arriver (3.7 improved subprocess.run()
pour traiter tous les cas courants de manière autonome).
-
Étonnamment, Python n'a pas d'utilitaire non bloquant standard indépendant de la plate-forme (avec délai d'attente) pour interroger le clavier (stdin). L'outil Bash read
est un outil génial pour une interaction simple avec l'utilisateur. Mon utilisation la plus courante est d'afficher un spinner jusqu'à ce que l'utilisateur appuie sur une touche, tout en exécutant une fonction d'interrogation (à chaque étape du spinner) pour m'assurer que les choses fonctionnent toujours bien. Il s'agit d'un problème plus difficile qu'il n'y paraît à première vue, aussi je me contente souvent de faire un appel à Bash : Coûteux, mais il fait précisément ce dont j'ai besoin.
-
Si vous développez sur un système embarqué ou avec des contraintes de mémoire, l'empreinte mémoire de Python peut être plusieurs fois supérieure à celle de Bash (en fonction de la tâche à accomplir). De plus, il y a presque toujours une instance de Bash déjà en mémoire, ce qui n'est pas forcément le cas pour Python.
-
Pour les scripts qui s'exécutent une fois et se terminent rapidement, le temps de démarrage de Python peut être beaucoup plus long que celui de Bash. Mais si le script contient des calculs importants, Python prend rapidement le dessus.
-
Python possède le système de paquets le plus complet de la planète. Lorsque Bash devient un tant soit peu complexe, Python dispose probablement d'un paquetage qui transforme des pans entiers de Bash en un seul appel. Cependant, trouver le(s) bon(s) paquet(s) à utiliser est la partie la plus importante et la plus intimidante pour devenir un Pythonista. Heureusement, Google et StackExchange sont vos amis.
2 votes
Python est drastiquement plus rapide sur le traitement de texte, qui est une opération courante. Si j'effectue la même recherche 10000 fois sur chaque langue, sur Bash il faut 1m24s, sur Python 636ms. Cela s'explique par le fait que Bash utilise un sous-processus pour chaque opération du traitement de texte, ce qui est lent à créer.