Pourquoi il n'y a pas de ++ et -- les opérateurs en Python?

Pourquoi il n'y a pas de ++ et -- opérateurs en Python?

Related post - le Comportement d'incrémentation et de décrémentation les opérateurs en Python

InformationsquelleAutor Leonid | 2010-09-06

operators python

432

Ce n'est pas parce que ça n'a pas de sens; il est parfaitement logique pour définir "x++" comme "x += 1, l'évaluation de la précédente liaison de x".

Si vous voulez savoir la raison originale, vous devrez soit wade à travers le vieux Python, les listes de diffusion ou de demander à quelqu'un qui était là (eg. Guido), mais il est assez facile de justifier après coup:

Simple d'incrémentation et de décrémentation ne sont pas nécessaire, car, comme dans bien d'autres langues. Vous n'écrivez pas des choses comme for(int i = 0; i < 10; ++i) en Python très souvent; au lieu de cela vous faites des choses comme for i in range(0, 10).

Puisqu'il n'est pas nécessaire presque aussi souvent, il y a beaucoup moins de raison de lui donner sa propre syntaxe particulière; quand vous en avez besoin pour incrémenter, += est généralement très bien.

Ce n'est pas une décision si elle a un sens, ou s'il peut être fait--il le fait, et il peut. C'est une question de savoir si la prestation est intéressant d'ajouter à la base de la syntaxe de la langue. Rappelez-vous, c'est quatre opérateurs--postinc, postdec, preinc, predec, et chacun de ces aura besoin d'avoir sa propre classe surcharges; ils ont tous besoin d'être spécifié, et testé; il ajoute des opcodes de la langue (ce qui implique une plus grande, et donc plus lent, moteur VM); chaque classe qui prend en charge une logique d'incrément aurait besoin pour les mettre en œuvre (sur le haut de += et -=).

C'est tout redondante avec += et -=, de sorte qu'il deviendrait une perte nette.
- Il est souvent utile d'utiliser quelque chose comme tableau[i++], ce qui n'est pas bien placé, fait avec +=/-=.
- Ce n'est pas un modèle courant en Python.
- Car qui sera à l'intérieur d'une boucle, vous pourriez aussi bien de la boucle sur les i directement - si vous avez réellement besoin, et ne pouvez pas par exemple utiliser array.append()
- Je vois le plus grand souci de lisibilité et de prévisibilité. De retour dans mon C jours, j'ai vu plus qu'assez de bugs provenant de malentendus à propos de la distinction entre i++ et ++i...
- Je crois que dans le "C" du monde, il est le plus utilisé efficacement (pas plus souvent) avec des pointeurs. Il y a une correspondance directe pour certains jeux d'instructions qui prennent en charge pré - ou de post-incrémentation de l'adresse de registres - M68K vient à l'esprit comme l'un des premiers partisans de cette. Depuis il n'y a pas de pointeurs en Python il est redondant.
- Ajoutant à justifier après-coup: sur un projet sur lequel je travail, je l'ai rencontré (plus que n'importe qui dans leur vie) une bonne quantité de code C++ qui souffrent de problèmes avec ++ et -- être utilisé d'une manière qui favorise indéfini ou non précisé comportement. Ils rendent possible l'écriture compliquée, difficile-à-correctement-analyser le code.
- Dégroupage quelque chose comme return a[i++] est vraiment laid. Vous ne pouvez pas remplacer directement pour i+=1 ou i=i+1 et doit changer un certain nombre de lignes de code.
- Je ne sais pas si vous avez compris la réponse. Le point est que, contrairement au C, vous n'avez pas besoin d'incrémenter par un dans Python très souvent. Si vous trouvez que vous êtes en train de faire tout le temps, vous pourriez ne pas être en utilisant le langage encore (pour, xrange, énumérer, etc.).
- Glenn, je ne suis pas sûr que vous avez compris mon commentaire. Si vous utilisez xrange, enumerate, for, etc si vous ne savez pas à l'avance le nombre d'éléments à traiter, vous pourriez ne pas être de programmation correctement.
- Désolé, cela n'a aucun sens. Vous n'avez pas besoin de post-incrémentation d'écrire "pour le point de some_list", ou dans la plupart des autres cas, vous devez généralement dans C.
- Je prétends que la array[i++] est moins douloureux de perdre de array[i]++ -- le premier pourrait probablement être fait ailleurs dans votre boucle, mais ce dernier nécessite la création d'un jetable variable temp et au moins deux lignes de code supplémentaires.
- 1 seront les mêmes, non?
- Il n'y a aucune raison qu'ils auraient besoin d'autres opcodes.
- à l'intérieur de itérateur return self.vertices[self.current++] - serait sympa.
- Je sais que c'est un vieux thread, mais la situation où vous êtes en utilisant une instruction foreach pour parcourir une collection et ne sont donc pas fourni d'indices, et, par conséquent, doit fournir vous-même si vous en avez besoin - est incroyablement commun et ++i ou i++ est largement utilisé façon de résoudre ce problème. Cette situation est particulièrement fréquente lorsque vous avez besoin pour faire de chaque membre d'une non-ordonnée unique. Le travail autour de ce python fournit est d'énumérer, et je ne vois pas ce qui a été décrit assez dans ce fil.
InformationsquelleAutor Glenn Maynard
82

Cette réponse originale à cette question que j'ai écrit est un mythe du folklore, de l'informatique,: démenti par Dennis Ritchie comme "historiquement impossible", comme indiqué dans les lettres à la rédaction de les Communications de l'ACM juillet 2012 doi:10.1145/2209249.2209251

Le C incrémentation/décrémentation les opérateurs ont été inventé à une époque où le compilateur C n'était pas très intelligent, et les auteurs ont voulu être en mesure de préciser l'intention directe d'un langage machine de l'opérateur doit être utilisé qui a sauvé une poignée de cycles pour un compilateur, ce qui pourrait faire un
```
load memory
load 1
add
store memory
```
au lieu de
```
inc memory 
```
et le PDP-11 de même pris en charge "autoincrement" et "autoincrement différé" instructions correspondant à *++p et *p++, respectivement. Voir la section 5.3 de le manuel si terriblement curieux.

Que les compilateurs sont assez intelligents pour gérer le haut niveau d'optimisation des astuces construit dans la syntaxe du C, ils sont juste un syntaxiques commodité maintenant.

Python n'a pas des astuces pour transmettre les intentions de l'assembleur, car il n'a pas l'utilisation d'un.
- Javascript a ++. Je ne pense pas que c'est un "truc de transmettre les intentions de l'assembleur." De Plus, Python n'ont bytecode. Donc, je pense que la raison est autre chose.
- Cette "donner des trucs pour le compilateur d'affaires" est en effet un mythe. Franchement, c'est un muet outre, à toute langue, et qu'il viole la suite de deux préceptes: 1. Vous n'avez pas de code pour que l'ordinateur puisse lire, vous code pour un autre ingénieur à lire. Et 2. Vous n'avez pas de code pour un ingénieur compétent pour lire, vous code pour un ingénieur compétent pour lire tout épuisé à 3h du matin et sauta sur la caféine.
- Pour être juste, lors du codage sur 10 à 30 caractères par seconde, demi-duplex télétype, vous code de sorte que vous pouvez clés avant la semaine prochaine.
- Unix et C vu l'essentiel de leur développement initial sur PDP-11, qui a utilisé incroyablement lent téléscripteurs pour la communication de l'utilisateur. Pendant que vous êtes morts droit que aujourd'hui codage de la machine est surtout ridicule, à l'époque, il était l'Homme/Machine, l'interface qui a été le goulot d'étranglement. Il est difficile d'imaginer le travail que lentement si vous n'avez jamais eu de.
InformationsquelleAutor msw
63

J'ai toujours supposé qu'il avait à faire avec cette ligne de la zen de python:

Il devrait y avoir un — et de préférence seulement un moyen évident de le faire.

x++ et x+=1 faire exactement la même chose, donc il n'y a pas de raison d'avoir les deux.
- one-- est égal à zéro ?
- one-- est une dans la phrase, mais zéro immédiatement après. Donc, ce "koan' également des conseils qui incrémentation/décrémentation les opérateurs ne sont pas évidentes.
- Un tiret cadratin est généralement écrit en caractères ascii de deux traits d'union, mais @VictorK l'explication est plus amusant.
- Si x++ et x+=1 faire la même chose, pouvez-vous me dire les valeurs de (x++) et (x+=1) ? Je pense que la dernière n'a pas de valeur en python -- ou plutôt, en demandant un donnerait une erreur de syntaxe. Je voudrais tenir compte d'un sous-ensemble de types à l'intérieur d'une boucle for. x++ serait de faire le tour bien.
- mais +=2
- Si vous supprimez +=, alors vous ne pouvez pas faire des choses comme x += 10. += est un cas plus général d' ++
- Aussi: "Explicite est mieux que l'implicite".
- En fait, "un--" est une dans la phrase, mais MOINS un par la suite. Parce que ça arrive deux fois. Encore plus non évidentes 🙂 Bien, la seconde pourrait être predecrementing "évident"...
- Certainement pas le même, parce que x+=1 n'est PAS une expression, c'est une déclaration - et il n'a pas d'évaluer quoi que ce soit. Vous ne pouvez pas faire des trucs comme: "rangée[col++] = a; ligne[col++] = b'. Sans parler de la pré-inc et post-inc trucs que c++ a des.
- Ce ne sont pas les mêmes... comment puis-je faire "si un++ == 3" à l'aide de += ?
- veuillez préciser. Je comprends que nous parlons de python, mais a=x++; et a=(x++); des cours de rendement exactement le même résultat en C.
- wow... (il y a longtemps, maintenant..) je voulais dire que Uri dit, ci-dessus.
- À propos de x+=1 ne sont pas une expression? Python, peut-être. Mais dans les deux C et C++, je crois que toutes les missions, même les étranges composés, sont des expressions. C'est ce qui donne a=b=c; travail en premier lieu dans ces langues (avec le regroupement de la droite vers la gauche).
- x++ et x+=1 ne sont pas la même chose.
- Si vous supprimez +=, alors vous pouvez faire des choses comme x += 10 encore. Vous pouvez faire x = x + 10.
- Par cette logique, += ne devrait pas exister, parce que vous pouvez simplement utiliser x = x + n. Mais += est plus pratique. De même, ++ est un plus pratique pour l'ajout d'1.
InformationsquelleAutor GSto
36

Bien sûr, on pourrait dire "Guido juste décidé de cette façon", mais je pense que la question est vraiment sur les raisons de cette décision. Je pense qu'il y a plusieurs raisons:
- Elle mêle l'ensemble des déclarations et des expressions, ce qui n'est pas une bonne pratique. Voir http://norvig.com/python-iaq.html
- Il encourage généralement les gens à écrire moins de code lisible
- Supplémentaire de complexité dans la langue de la mise en œuvre, ce qui est inutile en Python, comme déjà mentionné
- Content que quelqu'un mentionne enfin la déclaration vs expression aspect. En C, l'affectation est une expression et donc il l' ++ opérateur. En Python affectation est une déclaration, de sorte si il a eu un ++, il aurait probablement besoin d'être une instruction d'affectation, trop (et encore moins utile ou nécessaire).
- D'accord - s'ils ont été énoncés, puis, à un minimum, il serait devenu tout à fait dénué de sens de parler de la différence entre le post - et pré - opérateurs.
InformationsquelleAutor EMP
16

Parce que, en Python, les entiers sont immuables (int) + = retourne en fait un objet différent).

Aussi, avec ++/-- vous avez besoin de s'inquiéter à propos de la pré - rapport à la post - incrémentation/décrémentation, et il prend seulement un de plus de touches pour écrire x+=1. En d'autres mots, il évite les risques de confusion au détriment de très peu de gain.
- ints sont immuables C ainsi. Si vous ne le pensez pas, essayez d'obtenir votre compilateur C pour générer du code pour 42++... quelque Chose comme ceci (la modification d'une constante littérale) est possible, dans certains vieux compilateurs Fortran (ou alors j'ai lu): Toutes les futures utilisations de ce littérale dans l'exécution du programme serait alors vraiment avoir une valeur différente. Heureux de débogage!
- La droite. 42 est un littéral constant. Les constantes sont (ou au moins doit) être immuable. Cela ne signifie pas que C ints en général sont immuables. Un int en C simplement désigne un lieu de mémoire. Et les bits qui est un endroit très mutable. Vous pouvez, par exemple, créer une référence d'un int et changer le référent de cette référence. Ce changement est visible dans toutes les références (y compris l'original int variable) à cet endroit. Le même ne tient pas pour un Python objet integer.
- x+=1 ne se termine pas devenir inc mem. Python exécute un appel de fonction pour ajouter 1 à une variable, c'est pathétique.
InformationsquelleAutor Nathan Davis
12

De la clarté!

Python est l'un des beaucoup de choses sur clarté et pas programmeur est susceptible de deviner correctement le sens de --a à moins qu'il a appris une langue ayant que de construire.

Python est également beaucoup sur en évitant les constructions qui invitent les erreurs et la ++ opérateurs sont connus pour être riches sources de défauts.
Ces deux raisons sont suffisantes pour ne pas avoir ces opérateurs en Python.

La décision que Python utilise l'indentation pour marquer les blocs plutôt
que syntaxique des moyens comme une forme de début/fin de bracketing
ou obligatoire de la marque de fin est basé en grande partie sur les mêmes considérations.

Pour illustration, un coup d'oeil à la discussion autour de l'introduction d'un opérateur conditionnel (dans C: cond ? resultif : resultelse) en Python en 2005.
Lisez au moins les premier message et la décision message de discussion (qui avait plusieurs précurseurs sur le même sujet par le passé).

Trivia:
Le PEP fréquemment mentionnés ci-dessus est le "Python Proposition d'Extension" PEP 308. LC signifie compréhension de liste, GE moyen générateur d'expression (et ne vous inquiétez pas si ceux que vous confondez, ils n'en sont pas les quelques compliqué spots de Python).

InformationsquelleAutor Lutz Prechelt
9

C'était juste conçues de cette manière. D'incrémentation et de décrémentation les opérateurs sont juste des raccourcis pour x = x + 1. Python a généralement adopté une stratégie de conception qui réduit le nombre de solutions de rechange de l'exécution d'une opération. Augmentée d'affectation est la chose la plus proche pour incrémenter/décrémenter les opérateurs en Python, et ils n'étaient pas encore ajouté jusqu'à ce que Python 2.0.
- Ouais mate, comme, vous pouvez le remplacer return a[i++] avec return a[i=i+1].
InformationsquelleAutor Reed Copsey
8

Ma compréhension de pourquoi python n'a pas ++ opérateur est la suivante: Lorsque vous écrivez ce en python a=b=c=1, vous obtiendrez trois variables (étiquettes) pointant sur le même objet (la valeur 1). Vous pouvez le vérifier en utilisant l'id d'une fonction qui retourne un objet de la mémoire à l'adresse:
```
In [19]: id(a)
Out[19]: 34019256

In [20]: id(b)
Out[20]: 34019256

In [21]: id(c)
Out[21]: 34019256
```
Tous les trois variables (étiquettes) pointent vers le même objet. Maintenant incrémenter une variable, et de voir comment il affecte des adresses de mémoire:
```
In [22] a = a + 1

In [23]: id(a)
Out[23]: 34019232

In [24]: id(b)
Out[24]: 34019256

In [25]: id(c)
Out[25]: 34019256
```
Vous pouvez voir que la variable a maintenant pointe vers un autre objet que les variables b et c. Parce que vous avez utilisé a = a + 1 il est explicitement précisé. En d'autres termes vous attribuer complètement un autre objet de l'étiquette a. Imaginez que vous pouvez écrire a++ il suggère que vous n'avez pas l'affecter à la variable a nouvel objet, mais ratter incrément de l'ancien. Tout ça est à mon humble avis de la minimisation de confusion. Pour mieux comprendre voir comment python variables travaux:

En Python, pourquoi une fonction de modifier certains des arguments qu'elle est perçue par l'appelant, mais pas d'autres?

Est Python en appel par valeur ou en appel par référence? Ni.

Python passage par valeur ou par référence?

Est Python par référence ou par valeur?

Python: Comment puis-je passer une variable par référence?

La compréhension de Python variables et Gestion de la Mémoire

L'émulation de passer par valeur, le comportement en python

Python fonctions d'appel par référence

Code Comme un Pythonista: Idiomatiques Python

InformationsquelleAutor Wakan Tanka
7

Je suis très nouveau à python, mais je soupçonne que la raison est en raison de l'accent mis entre changeant et immuable objets à l'intérieur de la langue. Maintenant, je sais que x++ peut facilement être interprété comme x = x + 1, mais on dirait que vous êtes incrémentation en place un objet qui pourrait être immuable.

Juste mon sentiment/sensation/intuition.
- Dans cet aspect, x++ est plus proche de x += 1 que de x = x + 1, ces deux de faire une différence, ainsi que sur les objets mutables.
InformationsquelleAutor mkoistinen
4

D'abord, Python n'est qu'indirectement influencé par C; elle est fortement influencée par ABC, qui apparemment, n'a pas de ces opérateurs, de sorte qu'il ne devrait pas être une grande surprise de ne pas trouver dans Python soit.

Deuxièmement, comme d'autres l'ont dit, d'incrémentation et de décrémentation sont pris en charge par += et -= déjà.

Troisième, un support complet pour un ++ et -- opérateur set comprend habituellement les soutenir à la fois le préfixe et le suffixe de versions. En C et C++, cela peut conduire à toutes sortes de "lovely" constructions qui semblent (pour moi) à l'encontre de l'esprit de simplicité et de droite audace que Python embrasse.

Par exemple, tandis que le C déclaration while(*t++ = *s++); peut sembler simple et élégant pour un programmeur expérimenté, quelqu'un apprentissage, c'est tout sauf simple. Jeter dans un mélange de préfixe et le suffixe incréments et décréments, et même de nombreux pros auront à s'arrêter et à réfléchir un peu.

InformationsquelleAutor wberry
3

Je crois qu'il découle du Python credo qui "explicite est mieux que l'implicite".
- Eh bien, vous n'avez pas l'écrire explicitement "début" et "fin" des déclarations en Python, droit? Même si je suis d'accord avec l'énoncé, je pense qu'il y a des limites à cela. Alors on peut dire sur le fait que les limites, je pense que nous convenons tous qu'il y a une ligne, ce qui est impossible à traverser. Et comme il y a beaucoup d'opinions et de justifications sur cette décision, je ne pense pas que c'était un choix évident. Au moins, je ne peux pas trouver une source, où il est explicitement indiqué
InformationsquelleAutor Sepheus
3

Cela peut être parce que @GlennMaynard est à la recherche à l'affaire, comme dans la comparaison avec d'autres langues, mais en Python, vous faites les choses de la façon python. Ce n'est pas un "pourquoi" question. C'est là, et vous pouvez faire des choses pour le même effet avec x+=. Dans Le Zen de Python, il est donné: "il ne devrait être qu'une façon de résoudre un problème." Plusieurs choix sont grands à l'art (liberté d'expression), mais moche dans l'ingénierie.

InformationsquelleAutor Nihal Sahu
2

La ++ classe d'opérateurs sont des expressions avec des effets secondaires. C'est quelque chose de généralement pas trouvé dans Python.

Pour la même raison, une cession n'est pas une expression en Python, empêchant ainsi la commune if (a = f(...)) { /* using a here */} idiome.

Enfin je soupçonne qu'il y a de l'opérateur ne sont pas très compatibles avec les Pythons de référence de la sémantique. Rappelez-vous, Python n'a pas de variables (ou pointeurs) avec la sémantique connue à partir de C/C++.
- rien n'empêche d'appeler une fonction avec un effet secondaire à un test / expression / compréhension de liste: f(a) où a est une liste de certains immuable de l'objet.
InformationsquelleAutor Ber
1

Peut-être une meilleure question serait de se demander pourquoi ces opérateurs existent dans C. K&R appels d'incrémentation et de décrémentation les opérateurs inhabituelle (Section 2.8 page 46). L'Introduction qualifie de "plus concis et souvent plus efficace". J'imagine que le fait que ces opérations viennent toujours dans la manipulation du pointeur a également joué un rôle dans leur introduction.
En Python, il a probablement été décidé qu'il n'a pas de sens pour essayer d'optimiser incréments (en fait, je viens de faire un test en C, et il semble que le gcc-assembly généré utilise addl au lieu de ttc dans les deux cas) et il n'est pas de l'arithmétique des pointeurs; de sorte qu'il aurait été juste Un Moyen de Plus pour le Faire et nous savons Python déteste ça.

InformationsquelleAutor Ludovico Fischer
1

ce que j'ai compris de sorte que vous ne pense pas que la valeur en mémoire est changé.
en c lorsque vous faites x++ la valeur de x dans les changements de la mémoire.
mais en python, tous les numéros sont immuables donc l'adresse que x a fait en tant que a toujours pas x x+1. lorsque vous écrivez x++ on pourrait penser que x change ce qui se passe vraiment, c'est que x refrence est changé à un emplacement de mémoire où x+1 est stocké ou à recréer cet emplacement si la biche n'existe pas.
- Donc, ce qui rend cette ++ et différent de += 1?
InformationsquelleAutor rafi wiener
1

Pour terminer déjà de bonnes réponses sur cette page:

Supposons que nous décidons de le faire, préfixe (++i) qui briserait l'unaire opérateurs + et -.

Aujourd'hui, les préfixant par ++ ou -- ne fait rien, car il permet de unaire opérateur plus de deux fois (ne fait rien) ou unaire moins deux fois (deux fois: annule lui-même)
```
>>> i=12
>>> ++i
12
>>> --i
12
```
Donc, potentiellement briser cette logique.

InformationsquelleAutor Jean-François Fabre
0

Je pense que cela concerne les concepts de la mutabilité et de l'immuabilité des objets. 2,3,4,5 sont immuables en python. Reportez-vous à l'image ci-dessous. 2 a fixé id jusqu'à ce python processus.

x++ s'entend essentiellement une incrémentation comme le C. En C, x++ effectue en place par incréments. Donc, x=3 et x++ serait incrément de 3 dans la mémoire à 4, contrairement à python 3 existera encore en mémoire.

Donc en python, vous n'avez pas besoin de recréer une valeur dans la mémoire. Cela peut conduire à l'optimisation des performances.

C'est un pressentiment de réponse.

InformationsquelleAutor Pikesh Prasoon
0

Je sais que c'est un vieux thread, mais dans la plupart des cas d'utilisation de ++je n'est pas couvert, soit manuellement l'indexation de jeux quand il n'y a pas fourni d'indices. Cette situation est pourquoi python fournit enumerate()

Exemple : Dans une langue donnée, lorsque vous utilisez une construction comme foreach pour parcourir un ensemble - pour le bien de l'exemple, nous allons même jusqu'à dire que c'est un non-ordonnée ensemble et vous avez besoin d'un index unique pour tout leur dire à part, dire
```
i = 0
stuff = {'a': 'b', 'c': 'd', 'e': 'f'}
uniquestuff = {}
for key, val in stuff.items() :
  uniquestuff[key] = '{0}{1}'.format(val, i)
  i += 1
```
Dans ce cas, python fournit une méthode enumerate, par exemple
```
for i, (key, val) in enumerate(stuff.items()) :
```
InformationsquelleAutor Jessica Pennell
0

D'autres réponses ont décrit pourquoi il n'est pas nécessaire pour les itérateurs, mais il est parfois utile lors de l'affectation pour augmentation de la variable en ligne, vous pouvez obtenir le même effet à l'aide de n-uplets et l'affectation multiple:

b = ++a devient:
```
a,b = (a+1,a+1)
```
et b = a++ devient:
```
a,b = a+1, a
```
Python 3.8 présente l'affectation := opérateur, nous permettant ainsi de réaliserfoo(++a) avec
```
foo(a:=a+1)
```
foo(a++) est toujours insaisissable si.

InformationsquelleAutor JeffUK

Vous devez vous connecter pour publier un commentaire.

De la clarté!