Quels sont les inconvénients de Python? [fermé]

Python semble faire fureur ces jours-ci, et non sans honte - car c’est vraiment un langage avec lequel on aime presque se faire donner un nouveau problème à résoudre. Mais, comme un homme sage a dit une fois (l'appeler un homme sage seulement parce que je n'ai aucune idée de qui a dit réellement, pas sûr qu'il était que sage du tout), de savoir vraiment une langue que ne sait pas seulement son syntaxe, design, etc., avantages mais aussi inconvénients. Aucune langue n'est parfaite, certaines sont simplement meilleures que d'autres.

Alors, quels seraient, à votre avis, les inconvénients objectifs de Python.

Remarque: je ne demande pas de comparaison de langage ici (ie C # est meilleur que Python parce que ... yadda yadda yadda) - plus d'un avis objectif (à un certain niveau) sur les fonctionnalités de langage mal conçues vous en manquez, et ainsi de suite. Si doit utiliser une autre langue à titre de comparaison, mais uniquement pour illustrer un point sur lequel il serait difficile de développer autrement (par exemple, pour faciliter la compréhension)

J'utilise assez régulièrement Python, et dans l'ensemble, je considère que c'est un très bon langage. Néanmoins, aucune langue n'est parfaite. Voici les inconvénients par ordre d'importance pour moi personnellement:

1. C'est lent. Je veux dire vraiment très lent. Bien souvent, cela n'a pas d'importance, mais cela signifie certainement que vous aurez besoin d'un autre langage pour les éléments critiques en termes de performances.

2. Les fonctions imbriquées sont un peu loufoques car vous ne pouvez pas modifier les variables dans la portée externe. Edit: J'utilise toujours Python 2 en raison de la prise en charge de la bibliothèque, et ce défaut de conception m'irrite énormément, mais apparemment, il a été corrigé dans Python 3 en raison de la déclaration non locale . Je ne peux pas attendre que les bibliothèques que j'utilise soient portées pour que cette faille puisse être envoyée au tas de cendres de l'histoire pour de bon.

3. Il manque quelques fonctionnalités qui peuvent être utiles au code générique / bibliothèque et IMHO est une simplicité prise à des extrêmes malsains. Les plus importants auxquels je puisse penser sont les types de valeurs définis par l'utilisateur (je suppose que ceux-ci peuvent être créés avec la magie de la métaclasse, mais je n'ai jamais essayé) et le paramètre de la fonction ref.

4. C'est loin du métal. Besoin d'écrire des primitives de threading ou du code du noyau ou quelque chose? Bonne chance.

5. Bien que mon incapacité à détecter les erreurs sémantiques dès le départ ne soit pas un inconvénient pour le dynamisme offert par Python, je souhaiterais qu'il existe un moyen de détecter les erreurs syntaxiques et les bêtises, telles que le typage incorrect des noms de variables sans avoir à exécuter le code.

6. La documentation n’est pas aussi performante que des langages tels que PHP et Java, qui ont de solides ressources en entreprise.

Je déteste le fait que Python ne puisse pas faire la distinction entre déclaration et utilisation d'une variable. Vous n'avez pas besoin de dactylographie statique pour y arriver. Ce serait bien d’avoir un moyen de dire «c’est une variable que j’ai délibérément déclarée, et j’ai l’ intention d’introduire un nouveau nom, ce n’est pas une faute de frappe».

De plus, j’utilise généralement les variables Python dans un style non inscriptible, c’est-à-dire que je considère les variables comme étant immuables et ne les modifie pas après leur première affectation. Grâce à des fonctionnalités telles que la compréhension de liste, cela est incroyablement facile et rend le flux de code plus facile à suivre.

Cependant, je ne peux pas documenter ce fait. Rien en Python ne m'empêche d'écraser ou de réutiliser des variables.

En résumé, je voudrais avoir deux mots-clés dans la langue: varet let. Si j'écris dans une variable non déclarée par l'un ou l'autre, Python devrait générer une erreur. De plus, letdéclare les variables en lecture seule, alors que les varvariables sont «normales».

Considérons cet exemple:

x = 42    # Error: Variable `x` undeclared

var x = 1 # OK: Declares `x` and assigns a value.
x = 42    # OK: `x` is declared and mutable.

var x = 2 # Error: Redeclaration of existing variable `x`

let y     # Error: Declaration of read-only variable `y` without value
let y = 5 # OK: Declares `y` as read-only and assigns a value.

y = 23    # Error: Variable `y` is read-only

Notez que les types sont toujours implicites (mais les letvariables sont typiquement statiques dans la mesure où elles ne peuvent pas être associées à une nouvelle valeur, alors que les varvariables peuvent toujours être typées de manière dynamique).

Enfin, tous les arguments de méthode doivent être automatiquement let, c'est-à-dire qu'ils doivent être en lecture seule. En général, il n'y a aucune bonne raison de modifier un paramètre, à l'exception de l'idiome suivant:

def foo(bar = None):
    if bar == None: bar = [1, 2, 3]

Cela pourrait être remplacé par un idiome légèrement différent:

def foo(bar = None):
    let mybar = bar or [1, 2, 3]

Mon principal reproche est le threading, qui n'est pas aussi performant dans de nombreuses circonstances (comparé à Java, C et autres) en raison du verrouillage global de l'interpréteur (voir la discussion "À l'intérieur du PILON GIL" (lien PDF) ).

Cependant, il existe une interface multiprocessus très facile à utiliser, mais elle sera plus lourde en mémoire pour le même nombre de processus que de threads, ou difficile si vous avez beaucoup de données partagées. L’avantage, cependant, est qu’une fois que vous avez un programme fonctionnant avec plusieurs processus, il peut s’adapter à plusieurs machines, ce qu’un programme threadé ne peut pas faire.

Je suis vraiment en désaccord sur la critique de la documentation, je pense que celle-ci est excellente et meilleure que la plupart, sinon toutes les langues principales.

Aussi, vous pouvez attraper de nombreux bugs d'exécution exécutant pylint .

On peut soutenir que le manque de typage statique, qui peut introduire certaines classes d’ erreurs d’ exécution , ne vaut pas la flexibilité supplémentaire offerte par le typage de canard.

Je pense que les parties orientées objet de Python sont un peu "verrouillées". Tout le besoin de passer explicitement "soi" à chaque méthode est un symptôme indiquant que sa composante POO n'a pas été expressément planifiée , pourrait-on dire; il montre également les règles de portée parfois verruqueuses de Python qui ont été critiquées dans une autre réponse.

Modifier:

Quand je dis que les parties orientées objet de Python se sentent «bloquées», je veux dire que, parfois, le côté POO se sent plutôt incohérent. Prenez Ruby, par exemple: En Ruby, tout est un objet et vous appelez une méthode en utilisant la obj.methodsyntaxe habituelle (à l'exception des opérateurs surchargés, bien sûr); en Python, tout est aussi un objet, mais certaines méthodes sont appelées comme une fonction; c'est-à-dire que vous surchargez __len__pour renvoyer une longueur, mais appelez-le en utilisant len(obj)le commun plus familier (et cohérent) obj.lengthdans d'autres langues. Je sais que cette décision de conception a des raisons, mais je ne les aime pas.

De plus, le modèle de programmation orientée objet de Python ne dispose d'aucune sorte de protection des données, c'est-à-dire qu'il n'y a pas de membres privés, protégés et publics; vous pouvez les imiter en utilisant _et __en face de méthodes, mais c'est un peu moche. De la même manière, Python ne comprend pas non plus correctement l'aspect de la programmation orientée objet qui consiste à transmettre les messages.

Ce que je n'aime pas chez Python:

1. Threading (je sais que cela a déjà été mentionné, mais mérite d'être mentionné dans tous les posts).
2. Pas de support pour les fonctions anonymes multilignes ( lambdane peut contenir qu'une seule expression).
3. Absence d'une fonction / classe de lecture d'entrée simple mais puissante (comme cinou scanfen C ++ et C ou Scanneren Java).
4. Toutes les chaînes ne sont pas unicode par défaut (mais corrigées dans Python 3).

Arguments par défaut avec des types de données mutables.

def foo(a, L = []):
    L.append(a)
    print L

>>> foo(1)
[1]
>>> foo(2)
[1, 2]

C'est généralement le résultat de quelques bugs subtils. Je pense qu'il serait préférable de créer un nouvel objet de liste chaque fois qu'un argument par défaut était requis (plutôt que de créer un seul objet à utiliser pour chaque appel de fonction).

Edit: Ce n'est pas un gros problème, mais quand quelque chose doit être mentionné dans la documentation, cela signifie généralement que c'est un problème. Cela ne devrait pas être nécessaire.

def foo(a, L = None):
    if L is None:
        L = []
    ...

Surtout quand cela aurait dû être la valeur par défaut. C'est juste un comportement étrange qui ne correspond pas à ce que vous attendez et qui n'est pas utile dans un grand nombre de circonstances.

Certaines des fonctionnalités de Python qui le rendent aussi flexible en tant que langage de développement sont également considérées comme des inconvénients majeurs par ceux utilisés pour l'analyse statique du "programme entier" réalisée par le processus de compilation et de liaison dans des langages tels que C ++ et Java.

• Déclaration implicite de variables locales

Les variables locales sont déclarées à l'aide de l'instruction d'affectation ordinaire. Cela signifie que les compilations de variables dans toute autre étendue nécessitent la saisie d'annotations explicites par le compilateur (déclarations globales et non locales pour les étendues externes, notation d'accès d'attributs pour les étendues d'exemple). Cela réduit considérablement la quantité de passe-partout nécessaire lors de la programmation, mais signifie que des outils d'analyse statique tiers (tels que pyflakes) sont nécessaires pour effectuer les contrôles gérés par le compilateur dans des langages nécessitant des déclarations de variables explicites.

• "Monkey patcher" est supporté

Le contenu des modules, des objets de classe et même de l'espace de noms intégré peut être modifié au moment de l'exécution. C'est extrêmement puissant, permettant de nombreuses techniques extrêmement utiles. Cependant, cette flexibilité signifie que Python n'offre pas certaines fonctionnalités communes aux langages OO à typage statique. Plus particulièrement, le paramètre "self" des méthodes d'instance est explicite plutôt qu'implicite (puisque les "méthodes" ne doivent pas être définies dans une classe, elles peuvent être ajoutées ultérieurement en modifiant la classe, ce qui signifie qu'elle n'est pas particulièrement pratique. de passer implicitement la référence d'instance) et les contrôles d'accès d'attribut ne peuvent pas être facilement appliqués, que le code soit ou non "à l'intérieur" ou "à l'extérieur" de la classe (car cette distinction n'existe que pendant l'exécution de la définition de la classe).

• Loin du métal

Ceci est également vrai de nombreux autres langages de haut niveau, mais Python a tendance à faire abstraction de la plupart des détails matériels. Les langages de programmation système tels que C et C ++ conviennent toujours beaucoup mieux à la gestion des accès matériels directs (cependant, Python communiquera volontiers avec ceux-ci via des modules d'extension CPython ou, de manière plus portable, via la ctypesbibliothèque).

1. Utilisation de l'indentation pour les blocs de code au lieu de {} / begin-end, peu importe.
2. Chaque nouvelle langue moderne a une portée lexicale appropriée, mais pas Python (voir ci-dessous).
3. Documentation chaotique (à comparer avec la documentation Perl5, qui est superbe).
4. Strait-jacket (il n'y a qu'une seule façon de le faire).

Exemple pour le cadrage brisé; transcription de la session d'interprétation:

>>> x=0
>>> def f():
...     x+=3
...     print x
... 
>>> f()
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 2, in f
UnboundLocalError: local variable 'x' referenced before assignment

globalet des nonlocalmots-clés ont été introduits pour patcher cette stupidité de conception.

Je trouve la combinaison de syntaxe orientée objet this.method()et procédurale / fonctionnelle de Python method(this)très dérangeante:

x = [0, 1, 2, 3, 4]
x.count(1)
len(x)
any(x)
x.reverse()
reversed(x)
x.sort()
sorted(x)

Cela est particulièrement grave car un grand nombre de fonctions (plutôt que de méthodes) sont simplement vidées dans l’ espace de noms global : méthodes relatives aux listes, chaînes, nombres, constructeurs, métaprogrammation, toutes mélangées dans une grande liste triée par ordre alphabétique.

À tout le moins, les langages fonctionnels comme F # ont toutes les fonctions correctement espacées dans les modules:

List.map(x)
List.reversed(x)
List.any(x)

Donc, ils ne sont pas tous ensemble. De plus, il s'agit d'une norme suivie dans toute la bibliothèque, donc au moins elle est cohérente.

Je comprends les raisons de faire la fonction fonction vs méthode , mais je pense toujours que c'est une mauvaise idée de les mélanger comme ça. Je serais beaucoup plus heureux si la méthode-syntaxe était suivie, du moins pour les opérations courantes:

x.count(1)
x.len()
x.any()
x.reverse()
x.reversed()
x.sort()
x.sorted()

Que les méthodes mutent ou non, les avoir comme méthodes sur l'objet présente plusieurs avantages:

• Emplacement unique pour rechercher les opérations "communes" sur un type de données: autres bibliothèques / etc. peuvent avoir d'autres choses fantaisistes à faire avec les types de données mais les opérations "par défaut" sont toutes dans les méthodes de l'objet.
• Pas besoin de continuer à répéter Modulelorsque vous appelez Module.method(x). En prenant l'exemple de la liste fonctionnelle ci-dessus, pourquoi dois-je continuer à répéter Listencore et encore? Il faut savoir que c'est un Listet je ne veux pas appeler la Navigation.map()fonction dessus! En utilisant la x.map()syntaxe, cela reste sec et toujours non ambigu.

Et bien sûr, cela présente des avantages par rapport à la manière de tout mettre en place dans un espace de noms global . Ce n'est pas que la manière actuelle est incapable de faire avancer les choses. C'est même assez concis ( len(lst)), puisque rien n'est espacé! Je comprends les avantages d'utiliser des fonctions (comportement par défaut, etc.) par rapport aux méthodes, mais je ne l'aime toujours pas.

C'est juste en désordre. Et dans les grands projets, le désordre est votre pire ennemi.

Manque d' homoiconicité .

Python a dû attendre 3.x pour ajouter un mot clé "avec". Dans n'importe quel langage homoiconique, il aurait pu être trivialement ajouté dans une bibliothèque.

La plupart des problèmes que j'ai vus dans les réponses sont de l'un des 3 types suivants:

1) Choses qui peuvent être corrigées avec un outillage (par exemple pyflakes) 2) Détails de mise en œuvre (GIL, performance) 3) Choses qui peuvent être corrigées avec des normes de codage (c.-à-d. Caractéristiques que les gens souhaiteraient ne pas avoir là)

La langue n ° 2 n’est pas un problème de langue, les questions n ° 1 et n ° 3 de l’OMI ne sont pas graves.

Le python est mon langage préféré car il est très expressif, mais vous empêche toujours de faire trop d’erreurs. J'ai encore quelques petites choses qui m'ennuient:

• Pas de vraies fonctions anonymes. Lambda peut être utilisé pour des fonctions à instruction unique, et l' withinstruction peut être utilisée pour beaucoup de choses pour lesquelles vous utiliseriez un bloc de code en Ruby. Mais dans certaines situations, cela rend les choses un peu plus maladroites qu’elles ne le devraient. (Loin d'être aussi maladroit que cela serait en Java, mais quand même ...)

• Une certaine confusion dans la relation entre les modules et les fichiers. Exécuter "python foo.py" à partir de la ligne de commande est différent de "import foo". Les importations relatives dans Python 2.x peuvent également causer des problèmes. Néanmoins, les modules de Python sont tellement meilleurs que les fonctionnalités correspondantes de C, C ++ et Ruby.

• Explicite self. Même si j'en comprends certaines des raisons et même si j'utilise Python quotidiennement, j'ai tendance à faire l'erreur de l'oublier. Un autre problème est qu’il devient un peu fastidieux de faire une classe d’un module. Le soi explicite est lié à la portée limitée dont d'autres se sont plaints. La plus petite portée en Python est la portée de la fonction. Si vous limitez vos fonctions, comme vous le devriez, ce n'est pas un problème en soi et IMO fournit souvent un code plus propre.

• Certaines fonctions globales, telles que lencelle que vous vous attendriez à être une méthode (qui est en réalité en coulisse).

• Indentation significative. Ce n’est pas l’idée elle-même, ce qui me semble formidable, mais comme c’est la seule chose qui empêche tant de gens d’essayer Python, il serait peut-être préférable que Python utilise des symboles de début / fin (facultatifs). En ignorant ces personnes, je pourrais totalement vivre avec une taille imposée pour l'indentation aussi.

• Qu'il ne s'agit pas du langage intégré des navigateurs Web, au lieu de JavaScript.

Parmi ces plaintes, ce n’est que la première qui me tient suffisamment à cœur et qui, à mon avis, devrait être ajoutée à la langue. Les autres sont plutôt mineurs, sauf le dernier, ce qui serait bien si cela se produisait!

Python n’est pas complètement mature: le langage Python 3.2 présente actuellement des problèmes de compatibilité avec la plupart des paquets actuellement distribués (ils sont généralement compatibles avec Python 2.5). C’est un gros inconvénient qui nécessite actuellement plus d’efforts de développement (trouver le paquet requis; vérifier la compatibilité; peser, choisir un paquet moins performant qui pourrait être plus compatible; prendre la meilleure version, la mettre à jour en 3.2, ce qui pourrait prendre plusieurs jours, puis commence à faire quelque chose d'utile).

Probablement à la mi-2012, ce sera moins un inconvénient.

Notez que je suppose que je me suis fait avoir par un fan-boy. Lors d'une discussion entre développeurs, notre équipe de développeurs de haut niveau est parvenue à la même conclusion.

La maturité dans un sens principal signifie qu'une équipe peut utiliser la technologie et être très rapidement opérationnelle sans risques cachés (y compris les problèmes de compatibilité). Les packages Python tiers et de nombreuses applications ne fonctionnent pas sous 3.2 pour la majorité des packages actuels. Cela crée plus de travail d'intégration, de test, de réimplémentation de la technologie elle-même au lieu de résoudre le problème actuel == une technologie moins mature.

Mise à jour pour juin 2013: Python 3 a toujours des problèmes de maturité. De temps en temps, un membre de l’équipe mentionnera un paquet nécessaire puis dira "sauf que ce n’est que pour la version 2.6" (dans certains cas, j’ai implémenté une solution de contournement via le socket localhost pour utiliser le package réservé à la version 2.6 avec 2.6, et le reste de nos outils restent avec 3.2). Même MoinMoin, le wiki pur-python, n’est pas écrit en Python 3.

La portée de Python est sérieusement brisée, ce qui rend la programmation orientée objet en Python très délicate.

Mes reproches à propos de Python:

• POOP boulonné (Voir la réponse de @ mipadi pour plus de précisions à ce sujet)
• Mise en œuvre brisée de lambdas
• Problèmes de portée
• Pas de collections persistantes dans la bibliothèque standard
• Mauvaise disponibilité des DSL intégrés

Les modificateurs d'accès en Python ne sont pas applicables. Il est donc difficile d'écrire du code bien structuré et modularisé.

Je suppose que cela fait partie de la portée brisée de @ Mason - un gros problème en général avec cette langue. Pour un code censé être lisible, il semble assez difficile de déterminer ce qui peut et devrait être dans la portée et quelle valeur sera à un moment donné - je pense actuellement à passer du langage Python à cause de ces inconvénients .

Ce n'est pas parce que "nous sommes tous des adultes consentants" que nous ne commettons pas d'erreurs et que nous ne travaillons pas mieux avec une structure solide, en particulier lorsque vous travaillez sur des projets complexes - l'indentation et les soulignés sans signification ne semblent pas suffisants .

1. La performance n’est pas bonne, mais elle s’améliore avec pypy,
2. Le GIL empêche l’utilisation du threading pour accélérer le code (bien qu’il s’agisse généralement d’une optimisation prématurée),
3. Ce n'est utile que pour la programmation d'applications,

Mais il a quelques fonctionnalités intéressantes:

1. C'est parfait pour RAD,
2. Il est facile de s’interfacer avec C (et pour que C intègre un interpréteur python),
3. C'est très lisible,
4. C'est facile à apprendre,
5. C'est bien documenté,
6. Les piles sont vraiment incluses, sa bibliothèque standard est énorme et pypi contient des modules pour pratiquement tout,
7. Il a une communauté en bonne santé.

Je préfère Python et le premier inconvénient qui me vient à l’esprit est de commenter une déclaration comme celle-ci: if myTest():vous devez modifier l’indentation de tout le bloc exécuté, ce qui n’aurait rien à voir avec C ou Java. En fait, en python au lieu de commenter une clause if, j'ai commencé à le commenter de la manière suivante: `si True: #myTest (), je n'aurai donc pas à changer le bloc de code suivant. Puisque Java et C ne s'appuient pas sur l'indentation, il est plus facile de commenter des déclarations avec C et Java.

L'envoi multiple ne s'intègre pas bien avec le système de type à envoi unique établi et n'est pas très performant.

Le chargement dynamique est un problème majeur sur les systèmes de fichiers parallèles où la sémantique de type POSIX provoque des ralentissements catastrophiques pour les opérations nécessitant beaucoup de métadonnées. J'ai des collègues qui ont brûlé un quart de million d'heures de base en obtenant simplement le chargement de Python (avec numpy, mpi4py, petsc4py et autres modules d'extension) sur des cœurs de 65k. (La simulation a fourni de nouveaux résultats scientifiques significatifs, donc cela en valait la peine, mais c'est un problème lorsque plus d'un baril de pétrole est brûlé pour charger Python une fois.) temps de chargement raisonnables à l’échelle, y compris le correctif de libc-rtld pour permettre dlopenun accès collectif au système de fichiers.

• un bon nombre de bibliothèques et de logiciels tiers très répandus et largement utilisés ne sont pas du tout pythoniques. Quelques exemples: soaplib, openerp, reportlab. La critique est hors du champ, elle existe, elle est largement utilisée, mais elle rend la culture python confuse (cela fait mal à la devise qui dit "Il devrait y avoir un - et de préférence un seul moyen - évident de le faire"). Les succès pythoniques connus (tels que django ou trac) semblent être l'exception.
• la profondeur potentiellement illimitée de l'abstraction de l'instance, classe, métaclasse est conceptuellement belle et unique. Mais pour le maîtriser, vous devez connaître en profondeur l'interprète (dans quel ordre le code python est interprété, etc.). Il n'est pas largement connu et utilisé (ou utilisé correctement), alors qu'une magie noire similaire, telle que les génériques C #, conceptuellement plus compliquée (IMHO) semble plus largement connue et utilisée, proportionnellement.
• Pour bien comprendre la mémoire et le modèle de thread, vous devez être assez expérimenté en python, car il n’existe pas de spécifications complètes. Vous savez simplement ce qui fonctionne, peut-être parce que vous avez lu les sources de l'interprète ou des bizarreries expérimentées et que vous avez découvert comment les résoudre. Par exemple, il n'y a que des références fortes ou faibles, pas les références douces et fantômes de Java. Java a un fil pour la récupération de place alors qu'il n'y a pas de réponse officielle sur le moment où la récupération de place a lieu en python; vous pouvez simplement observer que la récupération de place ne se produit pas si aucun code python n'est exécuté, et en conclure que cela se produit parfois lorsque vous essayez d'allouer de la mémoire. Cela peut être délicat lorsque vous ne savez pas pourquoi une ressource verrouillée n'a pas été publiée (mon expérience à ce sujet était mod_python dans freeswitch).

Quoi qu'il en soit, le python est ma langue principale depuis 4 ans maintenant. Etre fanboys, élitistes ou monomanes ne fait pas partie de la culture des pythons.

• Etrange POO:
  • len(s)à travers __len__(self)et autres "méthodes spéciales"
  • méthodes spéciales spéciales pouvant être dérivées d'autres méthodes spéciales ( __add__et __iadd__pour +et +=)
  • self comme premier paramètre de méthode
  • vous pouvez oublier d'appeler le constructeur de la classe de base
  • pas de modificateurs d'accès (privé, protégé ...)
• pas de définitions constantes
• aucune immuabilité pour les types personnalisés
• GIL
• performances médiocres qui conduisent à un mélange de Python et de C et à des problèmes de construction (recherche de librairies C, dépendances de plate-forme, etc.)
• mauvaise documentation, surtout dans les bibliothèques tierces
• incompatibilité entre Python 2.x et 3.x
• Outils d'analyse de code médiocres (comparés à ceux proposés pour les langages à typage statique tels que Java ou C #)

"Immutabilité" n'est pas exactement son point fort. Autant que je sache, les nombres, les n-uplets et les chaînes sont immuables, tout le reste (objets) est modifiable. Comparez cela à des langages fonctionnels comme Erlang ou Haskell où tout est immuable (du moins par défaut).

Cependant, Immutability brille vraiment avec la concurrence *, ce qui n'est pas non plus le point fort de Python, donc au moins c'est conséquent.

(* = Pour les nitpickers: je veux dire une concurrence simultanée, au moins partiellement parallèle. Je suppose que Python accepte les communications simultanées "à un seul thread", dans lesquelles l'immuabilité n'est pas aussi importante. super même sans concurrence.))

J'aimerais avoir explicitement des constructions parallèles. Le plus souvent, quand j'écris une liste de compréhension comme

[ f(x) for x in lots_of_sx ]

Je me fiche de l'ordre dans lequel les éléments seront traités. Parfois, je ne me soucie même pas de l'ordre dans lequel ils sont renvoyés.

Même si CPython ne peut pas le faire correctement lorsque mon f est pur Python, un comportement comme celui-ci pourrait être défini pour être utilisé par d'autres implémentations.

Python n’a pas d’optimisation de l’appel final, principalement pour des raisons philosophiques . Cela signifie que la récurrence de la queue sur des structures volumineuses peut coûter de la mémoire O (n) (en raison de la pile inutile qui est conservée) et vous obliger à réécrire la récursivité sous forme de boucle pour obtenir la mémoire O (1).