IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 , par Patrick Ruiz

100PARTAGES

13  0 
Guido Van Rossum, le créateur de Python, se retire du processus décisionnel relatif au langage
qu'est-ce que cela signifie pour le futur de Python ?

Après presque 30 ans à superviser le développement de Python, Guido Van Rossum, son créateur, a 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 ».


Il faut le dire, l'annonce de la mise en retrait pendant une période indéterminée de M. Guido du processus de décision à la Fondation Python vient après la finalisation du programme PEP 572 et du constat selon lequel beaucoup de personnes mépriseraient ses décisions. Rappelons qu'un PEP est une proposition d'amélioration du langage Python (Python Enhancement Proposal en anglais).

A côté de cela, les propos de M. Guido laissent 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 [Dictateur bienveillant pour la vie ou Benevolent Dictator For Life en anglais], et vous serez tous seuls ».

En tout cas, peu importe la raison, elle ne semble pas du tout intéresser la communauté Python. L'idée de savoir que M. Guido se retire du processus de décision nourrit beaucoup de développeurs Python d'inquiétudes. D'autant plus encore que M. Guido s'est refusé de désigner un successeur : « je ne vais pas nommer un successeur », a-t-il dit.

M. Guido pense que les vrais problèmes auxquels Python pourrait être confronté à l'avenir seraient : comment les PEP seront-ils décidés et comment les nouveaux développeurs seront-ils introduits ? Et si ces problèmes se produisaient, M. Guido rappelle que Python a un code de conduite communautaire.

Source : Liste de diffusion de Python

Et vous ?

Qu'en pensez-vous ? Qu'est-ce que cela signifie pour le futur de Python ?
Craignez-vous que le retrait de Guido Van Rossum entraîne des prises de décision incohérentes comme on l'a vu ces dernières années avec Java ?

Voir aussi :

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
Python 2.7.11 est disponible avec des correctifs de bogues, mais sans nouvelles fonctionnalités
RHEL : Red Hat compte remplacer Python 2 par Python 3, dans la prochaine version majeure de sa distribution Linux
Vous avez lu gratuitement 1 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de floyer
Membre éclairé https://www.developpez.com
Le 28/12/2019 à 22:18
Citation Envoyé par hotcryx Voir le message
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.
0  0 
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 29/12/2019 à 0:56
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.
0  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 29/12/2019 à 2:02
Citation Envoyé par defZero Voir le message
"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
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
0  0 
Avatar de
https://www.developpez.com
Le 29/12/2019 à 10:25
Citation Envoyé par defZero Voir le message
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...).
0  0 
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 29/12/2019 à 12:03
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.
0  0 
Avatar de Biribibi
Membre habitué https://www.developpez.com
Le 29/12/2019 à 14:21
Citation Envoyé par defZero Voir le message
"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
0  0