Discussion :

[hotcryx]

@Pyramidev: cython et cpython s'allient.

'Cython is a compiled language that generates CPython extension modules.'

Python doit rester simple d'apprentissage et éviter tous les problèmes d'accolades...
Par contre comme tu le dis, des sur ensembles, paradigme peuvent naître et cohexister.

[VinsS]

Il n'y a pas de variable en Python elles ne sauraient donc être typées.

Dans un cas comme a = 42, Python crée une instance du type int avec la valeur 42 ensuite il prend un post-it écrit un a dessus et colle cette étiquette sur l'instance qu'il vient de créer.

Maintenant si l'on fait b = 42 Python se souvient avoir déjà créé cela, il se contente donc de créer un nouveau post-it avec un b et le collera sur notre premier objet.

Ensuite si l'on fait a += 2, comme les entiers sont imutables, Python crée donc une nouvelle instance de type int avec la valeur 42 + 2 prend l'étiquette a déjà collée sur le premier int et la colle sur le nouvel objet.

Mais il en sera de même si l'on fait a = "texte" l'étiquette a étant neutre (non typée) elle pourra donc être utilisée sur une string ou un tuple, une liste, etc.

Lorsqu' un objet n'a plus d'étiquette il sera détruit par le garbage collector.

Pour être plus complet l'exemple de a = 42 n'est pas tout à fait exact, Python, lors de son démarrage crée immédiatement tout une série d'entiers (de -x à +255 si je ne m'abuse) et donc il réutilise évidement ceux qu'il a créé.

Pour savoir combien d'étiquette possède déjà un objet on utilise getrefcount()

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
>>> import sys
>>> sys.getrefcount(42)
8
>>> a = 42
>>> sys.getrefcount(42)
9
>>> del a
>>> sys.getrefcount(42)
8

[Pyramidev]

Il n'y a pas de variable en Python elles ne sauraient donc être typées.

Dans les exemples de ton message, a et b sont des variables.

Elles peuvent être typées statiquement avec des annotations de type. Un outil comme mypy permet alors de vérifier si le typage est respecté, directement en lisant le code, sans l'exécuter.

Par exemple, le code suivant s'exécute correctement, mais est rejeté par mypy :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
a : int = 42
b : int = 42
a += 2
a = "texte" # Erreur selon mypy : "texte" est de type str alors que a est de type int.

Dans un cas comme a = 42, Python crée une instance du type int avec la valeur 42 ensuite il prend un post-it écrit un a dessus et colle cette étiquette sur l'instance qu'il vient de créer.

Maintenant si l'on fait b = 42 Python se souvient avoir déjà créé cela, il se contente donc de créer un nouveau post-it avec un b et le collera sur notre premier objet.

Attention : cette optimisation n'est pas garantie et dépend de l'implémentation.

Extrait de The Python Language Reference :
« after a = 1; b = 1, a and b may or may not refer to the same object with the value one, depending on the implementation »

Lorsqu' un objet n'a plus d'étiquette il sera détruit par le garbage collector.

Pour compléter tes dires, dans l'implémentation actuelle de CPython, il sera généralement détruit tout de suite. Mais, dans d'autres implémentations (ex : PyPy), la destruction peut être retardée.

Extrait de The Python Language Reference :
« CPython implementation detail: CPython currently uses a reference-counting scheme with (optional) delayed detection of cyclically linked garbage, which collects most objects as soon as they become unreachable, but is not guaranteed to collect garbage containing circular references. See the documentation of the gc module for information on controlling the collection of cyclic garbage. Other implementations act differently and CPython may change. Do not depend on immediate finalization of objects when they become unreachable (so you should always close files explicitly). »

[hotcryx]

Un langage sans variable, ça doit être vachement rapide

Il y a bien des variables en python, sinon tu ne pourrais retrouver leurs valeurs.

Regarde la méthode Type().

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
a = 1
print(type(a))
>> class: 'int'
 
b = "s"
print(type(b))
>> class: 'str'

[VinsS]

Un langage sans variable, ça doit être vachement rapide

Il y a bien des variables en python, sinon tu ne pourrais retrouver leurs valeurs.
...

J'ai trouvé ceci, il explique la même chose que moi mais il y a des dessins en plus. Je sais que cela en aide certains.

[Bill Fassinou]

Guido Van Rossum, le créateur de Python, rend en partie responsables les médias sociaux
de sa démission de la direction du projet

En juillet 2018, après presque 30 ans à superviser le développement de Python, Guido Van Rossum, son créateur, avait annoncé son désir de se retirer du processus décisionnel à la Fondation Python. « Je voudrais me retirer entièrement du processus de décision », dit-il. Mais « Je serai encore là pendant un certain temps en tant que développeur de base ordinaire, et je serai toujours disponible pour encadrer les gens, peut-être plus disponible ».

Dans un entretien avec Swapnil Bhartiya, le fondateur de TFIR, un blog, Guido Van Rossum parle de l'origine du langage et de la raison pour laquelle il s'est retiré de la direction du projet qu'il a créé. En 2018 quand il annonçait sa démission, il laissait voir de possibles soucis de santé. « Je ne suis plus jeune ... (Je vais vous épargner la liste des problèmes médicaux) ». Alors, « je me retire de manière permanente de mon rôle de BDFL (Benevolent Dictator For Life), et vous serez tous seuls ». Pour rappel, le Benevolent Dictator for Life, littéralement « Dictateur bienveillant à vie », est le surnom donné à une personne respectée de la communauté de développement open source qui définit des orientations générales d'un projet donné.

Alors qu'il venait de valider la 572e proposition d'amélioration de Python, il a décidé d'arrêter de prendre part au processus de validations de ces PEP. Dans un mail adressé à la communauté, le BDFL a déclaré : « maintenant que la PEP 572 est acceptée, je ne veux plus avoir à me battre autant pour une proposition de modification, surtout si autant de gens méprisent ma décision. Je voudrais me retirer complètement du processus de décision. Je serai toujours là pendant un moment en tant que développeur ordinaire, et je serai toujours disponible pour encadrer des personnes - peut-être davantage. Mais je me donne essentiellement des vacances permanentes en tant que BDFL, et vous serez tous seuls. Après tout, cela devait finir par arriver - il y a toujours ce bus qui se cache au coin de la rue, et je ne rajeunis pas ... (je vous épargne la liste des problèmes médicaux) ».

Il avait même refusé de désigner un successeur : « je ne vais pas nommer un successeur », avait-il dit. Dans l'interview, Van Rossum souligne qu'il reste l'un des développeurs principaux et déclare qu'une nouvelle gouvernance sera mise en place. « Nous allons mettre en place une nouvelle forme de gouvernance. Nous n'avons pas encore décidé de ce que ce sera. Nous avons actuellement environ cinq propositions différentes pour de nouveaux systèmes de gouvernance et il y aura un vote à ce sujet parmi les principaux développeurs, puis un autre qui déterminera précisément qui va former le leadership », a-t-il dit.

Rappelons qu'à sa démission en 2018, au cours des cinq mois qui ont suivi, la communauté Python avait adopté un nouveau modèle de gouvernance, le PEP 8016, qui proposait « un modèle de gouvernance Python basé sur un modèle de conseil de direction. Le conseil a un large pouvoir qu’il cherche à exercer le plus rarement possible; au lieu de cela, il utilise ce pouvoir pour établir des processus standard, comme ceux proposés dans les autres PEP de la série 801x. Cela correspond à la philosophie générale selon laquelle il est préférable de scinder de gros changements en une série de petits changements pouvant être examinés indépendamment: au lieu d'essayer de tout faire dans un PPE, nous nous concentrons sur la fourniture d'une base minimale, mais solide pour de futures décisions de gouvernance ».

Pour revenir aux raisons de sa démission, Van Rossum dit lors de l'entretien que ce qui a conduit à sa démission est une forme de remise en question de ses décisions sur les médias sociaux. « Pour moi personnellement, les médias sociaux ont certainement provoqué un stress supplémentaire et je n'aimais pas le fait que les développeurs principaux postaient des tweets dans lesquels ils remettaient en question mon autorité ou la sagesse de mes décisions, plutôt que de me le dire en face et d'avoir un débat honnête à propos de certaines choses ... », dit-il.

« Je suis tout à fait convaincu que les développeurs principaux les plus expérimentés que nous avons actuellement, ainsi que les nouveaux développeurs principaux que nous avons, seront ensemble en mesure de résister à tout type de tempête susceptible de survenir à la manière de Python. Oui, j'ai démissionné du titre tout à coup, mais il y avait déjà beaucoup de responsabilités que j'avais déjà complètement déléguées. Je veux dire, je touche à peine la base de code, j'ai à peine passé en revue les soumissions », ajoute-t-il.

Source : Billet de blog

Et vous ?

Que pensez-vous des raisons de sa démission ?

Voir aussi

Le créateur de Python se retire du processus décisionnel relatif au langage, qu'est-ce que cela signifie pour l'avenir de Python ?

La communauté Python adopte un nouveau modèle de gouvernance 5 mois après le départ volontaire du créateur du langage qui en était le décisionnaire

Guido van Rossum envisage de mettre fin au support de Python 2.7 le 1er janvier 2020 plus de mises à jour ou correctifs de sécurité après cette date

[jmbain]

[QUOTE=k304315;10361838]Python est un langage très intéressant, mais ses divergences par rapport au langage "ordinaire" issue du C (java, php, c++, ...) notamment en matière syntaxique rendent son utilisation pas très efficace sur de gros projets.

Il faut argumenter et donner des détails factuels.
Un gros projet, c'est quoi ? Quel gros projet ?
Qu'est-ce que ça veut dire "divergences syntaxiques" ? Tout langage qui n'est pas un avatar du C est-il non efficace ? Pourquoi ?

Le plus beau troll de l'année, je crois...
Si vous êtes aussi imprécis que cela sur vos projets, j'aimerais voir la tête du code...

[Patrick Ruiz]

Guido Van Rossum, le créateur de Python, se retire du Conseil de direction du langage pour s’adonner à des activités qu’il considère plus amusantes :
Programmer (en) et contribuer à Python

Le vote relatif à l’élection des membres du Conseil de direction du langage Python au titre de l’année qui pointe à l’horizon (2020) était programmé pour la période du 1er décembre au 16 décembre 2019. Compte tenu de son aura au sein de cette communauté, Guido Van Rossum aurait pu se présenter à nouveau comme candidat, mais le créateur du langage Python s’y est refusé.

Dans une publication parue sur la liste de diffusion dédiée au langage, il explique sa décision. De façon brossée, il y a qu’après tant d’années, Guido est resté un gros amoureux de la programmation informatique. En fait, c’est de l’activité de codage qu’il tire le plus de plaisir.

« J'y ai encore réfléchi. J'apprécie l'idée que vous souhaitiez que je fasse partie du comité de direction pendant un certain temps encore. Mais, il me semble que nous avons beaucoup d'excellents candidats et après une brève discussion avec les responsables actuels, j'ai décidé de me retirer. Ce qui explique en partie cette décision est qu’en fin de compte, le poste de membre du conseil de direction du langage m’apparaît plus comme une corvée qu’un plaisir et une des choses que j'essaie d'accomplir dans ma vie après mon départ de Dropbox est de prendre du plaisir Pour moi, qui dit plaisir parle (entre autres) de programmer en Python et de contribuer au langage. […] », précise-t-il.

Cette annonce fait en effet suite à sa décision de prendre sa retraite. En effet, Guido Van Rossum, 63 ans a écrit et contribué à une routine glob() pour le système d’exploitation Unix BSD en 1986 et a aussi aidé à développer le langage de programmation ABC au milieu des années 1980. À l’époque, il travaillait au sein de l’institut de recherche Centrum Wiskunde & Informatica (CWI) aux Pays-Bas. De même, il a travaillé pour la National Institute of Standards and Technology (NIST) des États-Unis et la Corporation for National Research Initiatives (CNRI). En 1991, il publie la première version du langage Python dont il est le créateur. Il est également à l’origine de Grail, un des premiers navigateurs Web écrit en Python et a engagé des discussions sur le standard HTML. De 2000 à 2003, il a travaillé pour Zope corporation. En 2003, van Rossum a quitté Zope for Elemental Security. De 2005 à décembre 2012, il a travaillé chez Google, où il a passé la moitié de son temps à développer le langage Python. C’est après 6 années passées à travailler chez Dropbox (à partir de janvier 2013) qu’il fait savoir qu’il met un terme à son périple.

En fait, Guido Van Rossum est dans ce processus personnel de retrait des sphères de décision du langage Python depuis plus de 2 ans. Dans la communauté open source, le titre de Benevolent Dictator For Life (BDFL) est attribué à un individu respecté qui définit les orientations générales d'un projet donné. En juillet 2018, après presque 30 années passées au sein des sphères de décision du langage Python, Guido Van Rossum, annonce qu’il se retire de manière permanente de son rôle de BDFL.

Guido van Rossum sera toujours là, mais plus comme membre des sphères de décision du langage. C’est du moins ce que suggère sa plus récente sortie : « Je lirai et répondrai au courrier, je passerai parfois en revue les requêtes et participerai aux discussions relatives au langage. Si le nouveau comité de direction me demande d'agir comme BDFL délégué pour une proposition d'amélioration du langage, je l'envisagerai et s'il y a des questions à mon endroit, j'essaierai d'y répondre. Je n'agirai tout simplement plus en tant que membre officiel du Conseil de direction. Je suis sûr qu'un comité de direction sans moi fera très bien l'affaire. »

L’une des raisons les plus profondes du retrait de Guido Van Rossum des sphères de décision du langage aurait à voir avec des frictions. En effet, suite à sa décision de retrait du poste de BDFL, Guido Van Rossum souligne que « des développeurs principaux postaient des tweets dans lesquels ils remettaient en question son autorité ou la sagesse de ses décisions, plutôt que de lui dire en face et d'avoir un débat honnête à propos de certains aspects. »

Source : PEP8101, Position de Guido Van Rossum

Et vous ?

Que pensez-vous du positionnement de Guido Van Rossum ?

Voir aussi :

La communauté Python adopte un nouveau modèle de gouvernance 5 mois après le départ volontaire du créateur du langage qui en était le décisionnaire
Guido van Rossum envisage de mettre fin au support de Python 2.7 le 1er janvier 2020 plus de mises à jour ou correctifs de sécurité après cette date

[floyer]

Un langage sans variable, ça doit être vachement rapide

Il y a Haskell où il n’y a que des constantes - qui ne « varient » pas. Elle peuvent être créée par « let c=42 in ... » ou des paramètres d’une fonction qui peuvent prendre plusieurs valeurs selon l’appel de la fonction, mais cette dernière ne pourra pas changer son paramètre à moins de s’appeler elle même avec une autre valeur.

Ceci-dit, il est possible de construire un opérateur (que l’on appelle typiquement « >>= ») qui émule des fonctions qui modifie une variable.

[defZero]

Il y a Haskell où il n’y a que des constantes - qui ne « varient » pas. Elle peuvent être créée par « let c=42 in ... » ou des paramètres d’une fonction qui peuvent prendre plusieurs valeurs selon l’appel de la fonction, mais cette dernière ne pourra pas changer son paramètre à moins de s’appeler elle même avec une autre valeur.

Ceci-dit, il est possible de construire un opérateur (que l’on appelle typiquement « >>= ») qui émule des fonctions qui modifie une variable.

@floyer

"let c = 42 in ..." c'est plutôt de l'OCaml il me semble.
Dans un langage fonctionnel pure (et donc ni OCaml ni les LISP), ont ne parle même pas de variable, mais de "binding".
Et c'est vrai pour Haskell il s’agira de matching, appel de fonction et de l'opérateur dédier ">>=" (bind, un des trois opérateur de monade).
En même temps, puisque tout est expression, ça limite l'utilité de la chose.

[Pyramidev]

"let c = 42 in ..." c'est plutôt de l'OCaml il me semble.

Je n'ai pas étudié OCaml, mais let c = 42 in est valide en Haskell.
Exemple de programme Haskell :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
main = let c = 42 in
       putStrLn $ "The answer is " ++ show c ++ "."

Pour l'exécuter en ligne : https://rextester.com/l/haskell_online_compiler

[Invité]

En même temps, puisque tout est expression, ça limite l'utilité de la chose.

On peut même dire que ce n'est pas du tout une limite. Ca rend les variables inutiles et ça évite plein de problèmes (side-effects, variables globales...).

[floyer]

La construction let a=42 in ... est de même nature en Haskell et en OCaml. Il est question de créer une constante (ou binding, qu’importe le terme). La différence de OCaml est que l’on peut aussi écrire let a=ref 42 in ... si on veut faire varier quelque chose. (Mais techniquement a sera toujours la même référence, seul !a, la valeur référencée variera).

Pour revenir à Python, je trouve surprenant l’expression selon laquelle il n’y a pas de variable en Python. Si j’écris a=42, a pourra être utilisé à la place de 42 et être changé. Cela caractérise une variable et qu’importe si en interne on ait un objet commun mutualisé ou un entier dédié à la variable. Si j’écris a=table[42]; b=table[42] avec une table d’objets, j’aurais deux variables qui pointent sur le même objet quelque soit le langage, cela n’enlèverait rien au caractère variable de a et b.

[Biribibi]

"let c = 42 in ..." c'est plutôt de l'OCaml il me semble.
Dans un langage fonctionnel pure (et donc ni OCaml ni les LISP), ont ne parle même pas de variable, mais de "binding".
Et c'est vrai pour Haskell il s’agira de matching, appel de fonction et de l'opérateur dédier ">>=" (bind, un des trois opérateur de monade).
En même temps, puisque tout est expression, ça limite l'utilité de la chose.

Euh non, en Haskell, on parle aussi de variables, comme en lambda-calcul de manière générale.
On ne peut pas parler non plus de constantes car elles "varient" en fonction des arguments données à la fonction même si elles restent immutables.
Un binding, c'est l'action d'associer une expression à une variable. Typiquement, la syntaxe let x = ... in

Il existe un style de programmation qui permet de s'abstraire des variables (enfin, des arguments de fonctions plutôt), ça s'appelle le point-free style
https://wiki.haskell.org/Pointfree
mais poussé à l'extrème, ça donne des trucs illisibles