Discussion:Python (langage)

Paradigmes

Python est multi-paradigmatique : Il permet la programmation: Du point de vue de la structuration

• Objet
• procedural
• impérative
• fonctionnelle
• logique

Du point de vue du typage:

• typage faible par defaut
• typage fort au besoin (API trait)

Placer Python dans un seul de ces types de programmation relève de la méconnaissance du langage.

Cela signifie quelque chose ce que vous dites là ou est-ce juste pour le plaisir ?

Ca correspond probablement à une ancienne version de l'article qui ne mentionnait qu'un seul paradigme pour python. --Piglop 20 septembre 2006 à 12:15 (CEST)

indiquer que python possède un typage fort me parait bizarre car c'est ce que la plpart des langages bas niveaux possède, il faudrait plutôt indiquer qu'il possède un typage faible, ou indiquer les 2, ou ne pas en parler. --CRicky 3 octobre 2006 à 14:50 (CEST)

C'est faux! Python a un typage INDUIT et DYNAMYQUE mais FORT. --Bogdahn 2 mai 2007 à 15:25 (CEST)

---

Bonjour,

je suis vraiment étonné de voir Python classé dans les "langages impératifs" alors que Python est totalement objet : tout y est objet, même si la syntaxe n'oblige pas le programmeur à se couler dans un moule objet.

Lançons par exemple une session interactive Python :

$ python
Python 2.4 (#2, Jan 20 2005, 12:30:47)
[GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print dir(5)
['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__', 
'__delattr__', '__div__', '__divmod__', '__doc__', '__float__', 
'__floordiv__', '__getattribute__', '__getnewargs__', '__hash__', '__hex__', 
'__init__', '__int__', '__invert__', '__long__', '__lshift__', '__mod__', 
'__mul__', '__neg__', '__new__', '__nonzero__', '__oct__', '__or__', 
'__pos__', '__pow__', '__radd__', '__rand__', '__rdiv__', '__rdivmod__', 
'__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rlshift__', 
'__rmod__', '__rmul__', '__ror__', '__rpow__', '__rrshift__', '__rshift__', 
'__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__str__', '__sub__', 
'__truediv__', '__xor__']
>>> 5 .__neg__()
-5

(NB: c'est pénible de devoir ajouter une espace au début de chaque ligne pour citer du code...)

On voit que le nombre 5 est un objet muni d'un certain nombre de méthodes (que la fonction dir() permet d'afficher), et que je peux appliquer à ce nombre la méthode __neg__ qui permet de retourner l'opposé du nombre.

D'autre part, je suis très étonné de lire que "La syntaxe de Python est inspirée du langage C", alors que l'exemple cité juste au-dessus prouve totalement le contraire. La syntaxe de Python est, à ma connaissance, issue des tests réalisés autour du langage ABC, qui était destiné à rendre l'apprentissage de l'informatique le plus aisé possible. Une des grandes conclusions fut que moins l'univers lexico-syntaxique est compliqué, plus l'apprentissage est facile pour les débutants car on peut se concentrer sur les concepts. De ce point de vue, Perl est beaucoup plus proche de C que ne l'est Python.

Je terminerai en citant le Zen de Python :

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

--Antoine 29 jan 2005 à 18:10 (CET)

Bonjour,

je suis tout à fait d'accord avec les remarques précédentes. Le fait de lier la syntaxe de python avec celle de C me semble vraiment inadéquate.

En ce qui concerne la notion d'objet, j'aime la boutade faite à ce sujet sur la page de Perl (langage) même si je considère python plus objet que perl.

cordialement

Fabrice

Réédition plus ou moins totale de l'article

L'article me semble plutôt bordélique. Ne devrait-il pas être réécrit de façon à adopter une organisation plus... évidente, qui détaillerait au passage Python de façon plus abordable par le néophyte (c'est quand même un langage excellent pour l'apprentissage) ? iPoulet (non inscrit)

+1 Aurélien 14 février 2006 à 22:38 (CET)

Alors on fait quoi ? IPoulet 15 février 2006 à 21:45 (CET)

Si tu veux réecrire l'article tu devrais peut etre travailler sur une page de brouillon, par exemple Discuter:Python (langage)/Brouillon. Et transferer le contenu dans l'article une fois fini. Moi je n'ai pas les connaissances pour le réecrire, mais si tu a besoin d'aide pour la vérification/relecture je peux donner un coup de main. Dr gonzo 15 février 2006 à 22:11 (CET)

En fait j'ai vraiment pas le temps de m'en occuper seul IPoulet 28 février 2006 à 12:33 (CET)

reponse au 21 Avril 2006 par Zorg724 : Ok, restructuration en cours de réalisation (cf:Références de sociétés utilisant Python : pourquoi Python ?). Python est devenu un standard affirmé, il est temps de montrer comment il a conquis le monde du logiciel concretement où et avec quels moyens ...

j'aime bien python (et je gagne ma vie en programmant avec) mais ce chapitre de propagande n'a rien à faire dans wikipédia. Il faut faire quelque chose ou bien j'enlève. Aurélien 11 avril 2006 à 19:43 (CEST)

Pas d'objection au retrait des passages de propagande, encore que la frontiere entre l'information et la propagande se mesure à l'aune de la connaissance que l'on a de la réalité. Consultant aupres de nombreuses entreprises, j'observe l'usage systématique de Python, bien au dela de l'usage d'un langage de script classique: applications internes bureautiques, drivers, AGL, agent de system, plateforme de dev WEB ... La description des modules Python en regard des couches logicielles est totalement justifié. La comparaison de portabilité avec JAVA est aussi une information objective disponible sur le site Python.org. Par ailleurs, la description de l'architecture logicielle et l'usage de python décrit se base sur http://www.python.org/about/success/ dont j'ai étudié les pages pendant 1 bon mois . Zorg724

Je viens de lire l'article (en cherchant si Python était réflexif) et voyant l'état dans lequel il est (apparemment je ne suis pas le seul à penser qu'il a besoin d'un remaniement), je me propose de le mettre à jour. Plus précisément, je me propose pour fournir une "version 2" de cet article prennant en compte les remarques (pertinentes jusque là, on est sauvés) formulées ici. Je soumettrai évidemment mes ébauches, une fois que j'aurai amélioré ma connaissance du langage.

Je sens la force du bac à sable en moi, espérons qu'elle me permettra d'être le plus objectif possible.

Esa 29 septembre 2006 à 12:07 (CEST)

D'accord avec le chapitre 'Références de sociétés utilisant Python ', il montre bien l'usage des modules de Python pour chaque couche logicielle. Une encyclopédie est faite pour etre vivante, et il est bon de décrire la réalité industrielle et scientifique de Python. Nous, on développe pour notre boite des appli utilitaires (IHM spécifique, pilotage d'equipement) et Pyhton suffit largement à couvrir notre besoin (sauf utilisation de SWIG/C à quelque endroit) Laurent.

Pour ceux qui douterait de l'usage de Python dans le monde (en France on a encore bq de retard), lire l'usage de Bruce Eckel, de la societe Rational Discovery LLC (Boost.Python) : http://www.boost.org/libs/python/doc/projects.html

• Responsable technique chez Thales, je remercie la nouvelle formulation de l'article, assez objective. Elle indique correctement l'usage des différents modules, l'étendu dans l'industrie -avec un grand retard en France comme toujours - . Bon travail. (René P.)

Un p'tit chouia trop

Est-ce qui y aurait pas un petit chouia trop de listings dans cet article? Et la liste des liens externes, en english d'ailleurs. Jsuis français moi! Alcalazar 23 mai 2006 à 13:14 (CEST)

Neutralité?

Le début de cet article ressemble plus à un éloge du langage qu'à un article encyclopédique. Beaucoup d'affirmations sans fondement et de qualificatifs discutables.

« La maitrise d’un langage de script est devenu un impératif pour les entreprises comme pour ceux dont l'informatique n'est pas le coeur de métier. »

L'informatique n'est pas le coeur de metier de toutes les entreprises. Enormement d'entreprises (dans l'informatique ou non) fonctionnent parfaitement bien sans meme connaitre l'existence des langages de script.

« Python est devenu le langage incontournable »

Python fait partie des langages très présents dans l'industrie mais n'est aucunement incontournable.

Note: à voir, il faudrait des exemples montrant comment python est utilisé dans des outils standards comme linux ou même google. Utilise-t-on python lorsqu'on installe linux ou qu'on fait une requête google, on qu'un sauvegarde une base de données ? Si oui, alors oui python est incontournable.

« sa portabilité encore plus grande que JAVA »

Une source ou une justification quelconque serait la bienvenue.

Note: voir la liste des ports sur l'article ou sur www.python.org ; ça et le fait qu'il suffit de compiler les sources pour obtenir un port me semblent assez comme justification.

« une productivité hors pair grâce à des frameWork alternatifs à J2EE ou .NET »

Hors pair? Un élément quelconque qui nous aiderait à nous en convaincre?

« Les performances sont au rendez-vous »

Très evasif.

Note: D'accord, c'est à préciser. Un benchmark serait bien.

« En outre, Python, de par son incroyable souplesse paradigmatique »

Incroyable n'est pas un qualificatif qu'on devrait trouver dans une encyclopédie.

« Python tend à devenir le langage de commande universel au coeur du génie-logiciel »

S'en suit une liste de possibilités qu'offre Python, mais aucun élément ne montre qu'il tend à devenir universel. Note: voir la note sur 'incontournable'

« la puissance inégalée en méta-programmation de Python »

Inégalée?

« l'incroyable liste des modules python »

Incroyable?

La suite de l'article est nettement plus neutre. Je suggère d'ajouter Python à la liste des articles non neutres. Piglop 11 juin 2006 à 11:52 (CEST)

Correction de l'article

J'aicommencé une correction de l'article. Mais celle-ci n'est absolument pas complète et je pense que j'aurias bien du mal à y arriver tout seul. Donc si quelques bonnes âmes souhaitent s'y mettre, je leur serai reconnaissant.

Voici en gros ce que je pense qu'il faille faire:

• Prendre en compte les remarques de la page de discussion, je l'ai trouvent presque toutes bonnes. Notamment, l'article est bourré de superlatifs qui n'ont rien à faire dans une encyclopédie et qui dévalorisent l'article lui-même.
• Python n'est pas un langage tout objet, Smalltalk est tout objet (enfin, je crois). Par exemple, les structures de contrôle en Python n'ont aucun sens sur le plan de la programmation orientée objet (ce ne sont pas des objets ou des envoient de messages, comme en Smalltalk). Les objets en Python ne respectent pas complètement le principe d'encapsulation.

J'ai corrigé l'exemple qui l'évoquait. Piglop 12 juin 2006 à 22:44 (CEST)

• Les exemples me paraissent nombreux. Peut-être faudrait-il créer une nouvelle page?

Déplacés dans Python, Exemples. On peut eventuellement en remettre quelques uns, mais je connais pas assez le langage pour savoir lesquels sont pertinents. Piglop 12 juin 2006 à 22:44 (CEST)

• J'ai l'impression que certaines informations sont devenues obsolètes à l'heure actuelle.
• Parler du en:Duck typing qui est le modèle de typage en Python.
• Il manque les métaclasses, les décorateurs, les list comprehension, les générateurs, les futures coroutines.
• Il faudrait aussi décrire les types de base et les structures de contrôle (if, for, while, ...), même les articles connexes n'en parlent pas.

--Kerflyn 12 juin 2006 à 08:17 (CEST)

J'ai mis la page à recycler. Je crois effectivement qu'il faudrait mettre les exemples ailleurs ou en supprimer une partie. Ils sont beaucoup trop nombreux.

Idem pour les sociétés, les couches ou les plateformes. Ca devrait etre plus synthétique. Peut etre aussi pour les liens externes.

Piglop 12 juin 2006 à 17:59 (CEST)

J'ai fait pas mal de modifications et de retraits d'informations. N'hésitez pas à ré-augmenter la version actuelle de l'article même avec des choses que j'ai enlevées, si vous estimez que ça vaut le coup. Du coup j'ai également enlevé le bandeau "à recycler". Gh 7 octobre 2006 à 17:38 (CEST)

Autre correction

«  intégration de scripts dans les logiciels (voir Gimp, Inkscape, Blender) »

Au début de l'article on dit que Python s'intègre dans le cycle de vie du logiciel. On cite Gimp, Inkscape et Blender comme des scripts, alors qu'ils sont des outils graphiques. Je pense qu'il faut remplacer ces exemples.

J'avais lu la phrase différemment... Pour moi elle signifiait que des scripts python étaient intégrés à des logiciels, en donnant pour exemples (certes uniquement des outils graphiques) Gimp, Inkscape et Blender. Esa 29 septembre 2006 à 11:58 (CEST)

Intervention sur l'article

Activation du lien sur les fonctions lambda en le redirigeant vers le lambda-calcul.

--Morshwan 22 novembre 2006 à 21:34 (CET)

L'utilisation de python dans xulrunner

Pour ce qui est des interfaces de Python, je pense qu'il serait utile de noter la futur possibilité d'utilisation de ce langage avec la "plateforme" xulrunner. Mais j'avoue que mes connaissances sont limités sur le sujet. A bon entendeur...

Suppression des sous articles

Bonjour,

Je pense qu'il faudrait supprimer les articles Python, Bibliothèques et Python, Exemples. Ils ne sont que des énumérations et n'ont rien d'encyclopédique. Ils ne respectent pas non plus les conventions sur les titres. On peut (par ordre de préférence personnelle) :

• les transferer sur wikilivres
• les supprimer
• les transferer dans Python (langage)

Qu'en pensez-vous ? --Piglop 5 février 2007 à 12:35 (CET)

Je les ai transferés sur wikibooks : b:Le langage de programmation Python. --Piglop 24 février 2007 à 10:56 (CET)

Remarque

Avis aux fans de Python: Avez-vous remarqué le jeu de mot entre le 'idle' pour lancer Python sous Linux et Eric Idle, membre des Monty Python???193.55.130.205 6 mars 2007 à 11:18 (CET)

Non, pas du tout. --haypo 5 mars 2007 à 16:56 (CET)

Héhé, je vais pouvoir me la péter à la machine à café ! Arronax · ^discuter 25 mars 2007 à 18:36 (CEST)

C'est surement une des raisons du nom d'un des principaux IDE python : Eric http://www.die-offenbachs.de/detlev/eric.html --Bogdahn 4 mai 2007 à 14:07 (CEST)

Deuxième remarque: L'exemple C me semble mal choisi. Au lieu de

// Fonction factorielle en C

int factorielle(int x) 
{      
    if (x == 0)                    
        return 1;                   
    else
        return x * factorielle(x-1);
}

on aurait plutôt

int factorielle(int x) 
{      
    if (x == 0)                    
        return 1;
    return x * factorielle(x-1);
}

voire

int factorielle(int x) 
{      
    return (x == 0) ? 1 : x * factorielle(x-1);
}

ce qui éviterait des warnings sur certains compilateurs. Potemkine (d) 30 septembre 2009 à 15:24 (CEST)

Influencé par ?

Sur la page on lit que Python est influencé par Haskell et Lisp. Ce n'est pas un peu fort ?

Disclaimer : je ne connais pas du tout le Python, mon propos est donc à prendre avec des pincettes.

Pour ce qui est du Lisp (disclaimer : je ne connais pas trop le lisp), il me semble que les points forts du Lisp sont sa syntaxe très flexible (ou plutôt inexistante), et son mécanisme de quotations et de macros. Aucun de ses points ne me semble avoir été repris en Python.

Pour ce qui est du Haskell, c'est un langage fonctionnel pur, typé statiquement, avec un système de types très riche. Rien à voir avec le Python, donc, à part à la rigueur le fait que l'indentation soit significative; ça reste un détail de syntaxe relativement mineur et ça ne mérite pas une affiliation, à mon avis.

Je sais qu'il existe vaguement des fonctions map, filter et cie, et une gestion des lambdas, en Python, on peut donc comprendre la présence de "fonctionnel" dans la liste des paradigmes supportés (même si elle me paraît personnellement un peu abusive). Je crois que ça ne justifie pas pour autant de mettre tout un tas de langages (dont les créateurs se retourneraient probablement dans leur tombe (ou leur lit) à l'idée d'être liés au Python) dans la liste des langages ayant eu une grande influence. Il me semble par ailleurs que ces fonctionnalités devraient être supprimées de python 3000 (source) (mais la situation a peut-être évolué depuis). Comme le créateur du langage le dis lui-même (ici), la tail-recursion n'est pas bien vue dans ce langage.

Je pense donc qu'il faudrait retirer Lisp et Haskell de la liste des langages ayant influencés le Python.

Bluestorm 3 juin 2007 à 13:02 (CEST)

Développement de Python , Python 3000

Bonjour, je traduis le passage de l'article anglais sur Python 3000 et le développement de Python. N'hésitez pas à relire ce travail et à la modifier si vous pensez qu'il n'est pas correct. De même, peut être que son positionnement sur la page n'est pas optimal. Merci beaucoup, cordialement.Okiokiyuki (d) 1 mars 2008 à 16:13 (CET)

c'est sympa de faire ce travail, mais en effet : le passage est mal placé (vers la fin de l'article ce serait mieux), et certaines phrases sont incompréhensibles. Aurélien (d) 1 mars 2008 à 21:53 (CET)

Voila, j'ai oté les traductions littérales un peu lourde et j'ai replacé cette section à la fin de la page. Okiokiyuki (d) 8 mars 2008 à 11:31 (CET)

"Similarité" avec les autres langages

il est ainsi similaire à Perl, Ruby, Scheme, Smalltalk et Tcl.

Scheme ? Comparer Python avec un langage purement fonctionnel et dérivé de Lisp, ça me parait étrange. D'ailleurs cette phrase sous-entends que Perl et Scheme seraient similaires entre eux, ce qui n'est pas du tout le cas, à ce que je sache. Il serait peut-être plus juste de dire que Python hérite de ces divers langages.

---

Je ne parle pas scheme et lisp, mais python est tout a fait utilisable en fonctionnel pure, ce qui le range autant dans ce paradygme fonctionel que ces deux langage, notemment par ce que certaines syntaxes sont directement reprise de ces language (lambda si je ne m'abuse, les list comprenension aussi (exemple: [ i*i for i in range(j) ] ) --tshirtman

Langage interprété ou compilé ?

Je cite l'article : Python est un langage de programmation interprété multi-paradigme. La frontière entre langages interprétés ou compilés est parfois assez floue mais moi je rangerais Python dans les langages compilés ! D'ailleurs quels langages (dans leurs implémentations courantes) sont encore interprétés de nos jours ? Ce n'est pas parce qu'il n'est pas requis une exécution explicite d'un compilateur qu'un langage n'est pas compilé... --OPi (d) 29 octobre 2010 à 16:04 (CEST)

Python est un langage de script interprété.

Un langage compilé est un langage qui est convertit en code machine avant ou pendant l'exécution (JIT).

Python interprète le code. Même s'il s'exécute dans une machine virtuelle exécutant du bytecode, il n'y a aucune translation en code machine.

--Rapha222 (d) 31 octobre 2010 à 15:29 (CET)

Pour être vraiment rigoureux, un langage n'est jamais intrinsèquement interprété ou compilé, puisque cela dépend des outils que l'on utilise pour assurer l'exécution du code, et non du langage lui-même.

Concernant Python en particulier, l'implémentation CPython effectue une compilation en bytecode (« compilation » n'implique pas « code natif », juste « traduction ») et interprète le bytecode. D'autres implémentations comme Pypy ou Unladen Swallow utilisent un JIT et compilent en code natif à l'exécution. Cython compile le Python en partie en C, puis en code natif, tout en gardant une partie du code en bytecode interprété. Shed Skin compile le Python en C++ puis en code natif.

J'ai retiré le mot « interprété » qui n'a pas sa place en intro ; il pourrait être mentionné dans l'historique ou dans une section dédiée aux différentes implémentations.

Amicalement — Arkanosis ^✉ 31 octobre 2010 à 15:52 (CET)

Remarque

la syntaxe de print dans presque tout les exemples est print() comme en python 3.x, mais dans les exemples de la partie générateurs, c'est la syntaxe antérieure qui est utilisée, peut-être faudrait-il que ce soit la même partout. Jean 5 5 (d) 29 novembre 2011 à 12:32 (CET)

M'en suis occupé --OPi (d) 29 novembre 2011 à 20:29 (CET)

Pas de surcharge statique ?

Je suis nouveau dans l'univers python, et dans la programmation objet aussi -mais je sors d'une formation sur le sujet, et sursaute sur cette affirmation :

«  Les classes Python supportent l'héritage multiple ; il n'y a pas de surcharge statique comme en C++... »

J'ai eu un doute, puis suis allé voir sur d'autres pages, dont http://fr.wikipedia.org/wiki/Surcharge_des_opérateurs, ce qui m'a rassuré -python fait bien partie des langages qui acceptent la surchage statique d'opérateurs. Je ne me sens pas owner de l'article, je vous laisse le modifier ?

--Greggywiki (d) 18 février 2012 à 07:21 (CET)

J'ai une source, je m'en occupe... JackPotte ($♠) 18 février 2012 à 09:07 (CET)

À moi de sursauter . C'est un non-sens : il ne peut pas y avoir de surcharge statique en Python vu qu'il n'y a même pas de typage statique. D'ailleurs le module en question le précise bien : il s'agit d'une surcharge dynamique.

Amicalement — Arkanosis ^✉ 18 février 2012 à 13:54 (CET)

D'ailleurs, overload semble n'être qu'une PEP… Je vérifierai plus tard, mais il me semble bien qu'il n'y a pas de surcharge du tout en Python. — Arkanosis ^✉ 18 février 2012 à 14:03 (CET)

Je confirme, c'est n'est qu'une PEP : le module overload n'existe ni en Python 2 ni en Python 3. J'ai rétabli le texte original, car il n'y a effectivement pas de surcharge en Python (ni statique, ni dynamique). J'ai par ailleurs corrigé quelques phrases de l'article, qui confondaient surcharge, définition et redéfinition. Greggywiki, je me demande si ce n'est pas la confusion que tu as faite (ou qu'ont faite les personnes qui t'ont formé) : Python permet de définir (define) un ensemble pré-défini d'opérateurs, et éventuellement de les redéfinir (override) dans les classes filles comme n'importe quelle méthode, mais pas de surcharger (overload) une fonction ou une méthode (en particulier, pas les opérateurs). L'article Surcharge des opérateurs (d · h · j · ↵) est à revoir complètement, car il mélange ces notions.

Amicalement — Arkanosis ^✉ 18 février 2012 à 17:01 (CET)

Controverse sur le droit des marques

Si cette histoire n'est pas une blague, ça vaudrait peut-être le coup de le rajouter dans l'historique ? Ambigraphe, le 11 mai 2013 à 23:25 (CEST)

Non, ce n'est pas une blague. Ça c'est terminé à l'amiable, cf. le blog de la PSF. Ça mérite peut-être effectivement une petite mention.

Amicalement — Arkanosis ^✉ 11 mai 2013 à 23:42 (CEST)

Historique : logiciels propriétaires ?

Je me suis permis d'ajouter une "référence nécessaire" dans la partie historique, étant donné qu'il ne me semble pas que Van Rossum ai quitté le CNRI pour participer à des projets propriétaires. Si l'on en croit son résumé en tout cas (http://www.python.org/~guido/Resume.html). --Noelmace (discuter) 5 décembre 2013 à 17:43 (CET)

Bon, j'ai directement supprimé le paragraphe en fait, car il n'y avait aucune source pour l'ensemble, et la suite me semblait fausse également, concernant la licence : Python était sous licence compatible GPL avant 2000, et n'est redevenue compatible qu'à partir de 2001 grâce à la PSF (et non au CNRI), si on en croit ce document http://docs.python.org/2/license.html --Noelmace (discuter) 5 décembre 2013 à 18:13 (CET)

Commentaire du lecteur : Ajout d'une rubrique...

94.124.157.253 a publié ce commentaire le 29 août 2013 (voir tous les retours).

Ajout d'une rubrique "Python et le web" (scripts python pour le web, création de pages et autre comportements).

Avez-vous des remarques à formuler ?

Litlok (m'écrire) 20 février 2014 à 13:32 (CET)

Ajout d'une section ou sous section ou paragraphe Controverses

Avec la venue de PEP 572, Guido a cessé son rôle de Benevolent Dictator For Life. La version 3.8 de python risque ainsi de changer la direction du langage. Il me semble qu'un paragraphe sur ceci soit nécessaire. — Le message qui précède, non signé, a été déposé par l'IP 213.179.113.164 (discuter), le 2 octobre 2020 à 00:05 (CEST)