Selon Haypo, le changement majeur de Python3 est le passage intégral à Unicode : par défaut les fichiers sont ouverts en mode texte en Unicode, un script Python est en UTF-8 (Unicode), on peut utiliser des identifiants en Unicode (libre à vous d'écrire en japonais, français ou anglais, après ça dépend avec qui vous souhaitez travailler), et utilisation d'Unicode dans la grande majorité des modules (la bibliothèque standard).
Pour celles et ceux qui s'interrogeraient quelle version de la 2 (2.6) ou de la 3 (3.0) ils devraient choisir, il est préférable de commencer par la 2 car de nombreux modules additionnels sont directement disponibles et testés pour cette version. Ensuite avec l'outil 2to3, il est possible de tester son code avec la version supérieure. On peut noter que quelques améliorations prévues pour Python 3 ont été rétropropagées dans Python 2.6, permettant une transition plus facile.
Python 3.0 a pris beaucoup de retard sur son planning. L'équipe Python a préféré corriger tous les bugs plutôt que de sortir une version boguée qui dégoûterait les gens de Python 3.
NdM : Merci à Haypo pour son journal publié précédemment à ce sujet
Aller plus loin
- Documentation officielle (36 clics)
- Page des téléchargements (8 clics)
- Liste des nouveautés (40 clics)
- La nouvelle sur Slashdot (5 clics)
- 2to3 : traduction automatique de code (15 clics)
- Journal traitant de la RC2 (29 clics)
# Traduction
Posté par FreeFlight . Évalué à 10.
[^] # Re: Traduction
Posté par Rémi Birot-Delrue . Évalué à 4.
[^] # Re: Traduction
Posté par vincent_k (site web personnel) . Évalué à -10.
Il serait temps de passer à autre chose !
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pseudo dans les dépêches
Posté par Kerro . Évalué à 5.
Ben c'est raté :-)
[^] # Re: Pseudo dans les dépêches
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: Pseudo dans les dépêches
Posté par Kerro . Évalué à 2.
Enfin bon, il n'y a pas péril en la demeure :-)
# Tout les bugs ? vraiment ?
Posté par ribwund . Évalué à 4.
[^] # Re: Tout les bugs ? vraiment ?
Posté par Clément David (site web personnel) . Évalué à 3.
Il suffit d'utiliser le module fileinput [http://docs.python.org/3.0/library/fileinput.html] que l'on trouve dans la documentation de sys.argv [http://docs.python.org/3.0/library/sys.html?highlight=filein(...)].
La méthode fileinput.input [http://docs.python.org/3.0/library/fileinput.html#fileinput.(...)] permet d'ouvrir un flux (par défault le flux d'arguments) suivant un mode spécifié.
With mode you can specify which file mode will be passed to open(). It must be one of 'r', 'rU', 'U' and 'rb'.
La documentation de open [http://docs.python.org/3.0/library/functions.html#open] nous indique alors comment l'on configure l'ouverture d'un flux :
========= ===============================================================
Character Meaning
--------- ---------------------------------------------------------------
``'r'`` open for reading (default)
``'w'`` open for writing, truncating the file first
``'a'`` open for writing, appending to the end of the file if it exists
``'b'`` binary mode
``'t'`` text mode (default)
``'+'`` open a disk file for updating (reading and writing)
``'U'`` universal newline mode (for backwards compatibility; unneeded
for new code)
========= ===============================================================
Tu doit pouvoir alors convertir un flux de donné suivant un encodage spécifié (en l'occurrence celui du système).
PS: je n'ai pas fait de python depuis 1 ans
PS2: la documentation de python 3 est vraiment superbe
[^] # Re: Tout les bugs ? vraiment ?
Posté par ribwund . Évalué à 4.
$ ./python `printf '\xff'`
Could not convert argument 1 to string
tonfa@pirzuine:/tmp/Python-3.0$ PATH=`printf '\xff'`:$PATH ./python
Python 3.0 (r30:67503, Dec 6 2008, 11:42:46)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.environ['PATH']
Traceback (most recent call last):
File "", line 1, in
File "/tmp/Python-3.0/Lib/os.py", line 389, in __getitem__
return self.data[self.keymap(key)]
KeyError: 'PATH'
On ne peut pas passer des arguments, et les variables d'environnement qui ne peuvent pas être décodées sont virées.
Dans le cas au dessus, l'unicode est mal encodé mais les mêmes problèmes arrivent si tu lance ton programme avec LANG=C. Dans ce cas les arguments unicodes ne peuvent être lus, et si une variable d'environnement contient de l'unicode elle est supprimée.
[^] # Re: Tout les bugs ? vraiment ?
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Effectivement, ce point épineux a provoqué des discussions assez houleuses sur la liste de diffusion. Il y a trois choses : sys.argv, noms des fichiers, et les variables d'environnement. Pour l'instant, tout est accessible en Unicode.
Pour les fichiers, j'ai écrit un patch pour pouvoir utiliser des noms de fichier sous forme d'octets. Ce travail a pris plusieurs mois mais a été intégré pour la sortie de la version 3.0 finale.
Pour les variables d'environnement (comme PATH), c'est en cours de discussion. Je pense que la version 3.1 pourra accéder aux variables d'environnement en tant qu'octets. Pour sys.argv, personne ne s'en est plaint (pas de bug ouvert, je crois) :-) Sûrement qu'à terme, il existera aussi une méthode pour accéder à la version en octets.
La solution que je déteste et que plusieurs personnes essayent à chaque fois de pousser, est de stocker des octets dans Unicode en utilisant un encodage spécial (ex: utiliser une plage réservée d'Unicode). Mais je ne comprend pas l'intérêt car on revient au status pourri de Python2 qui mélange octets et caractères, source de nombreux bugs. En particulier, le texte Unicode n'est plus interopérable :-/
À long terme, tous les systèmes utiliseront Unicode. Pour information, Windows utilise UTF-16 partout depuis très longtemps (Windows 98 je crois). Le problème est lorsqu'on mélange de vieilles partitions encodés avec des encodages différents. Il vaut mieux tout mettre en UTF-8 pour des raisons de simplicité. Python3 fait un pari sur l'avenir.
Note : Sur un système sain (UTF-8 partout), Python3 fonctionne à merveille ! C'est très agréable d'avoir de l'Unicode partout !
[^] # Unicode et OS
Posté par Zenitram (site web personnel) . Évalué à 3.
Ca, je veux voir ;-).
Le moteur de Win9X (95, 98, Millenium) est en char uniquement (il y a un patch officiel pour le support d'UTF-16 toutefois, les applis Unicode peuvent alors communiquer avec Win9X en Unicode par le biais de cette couche qui fait la traduction, ça ralenti un peu mais ça va)
C'est à partir de Windows NT 4 que Microsoft est passé en UCS-2 (pas UTF-16) puis les versions 5.x (2006, XP pour les noms commerciaux) en UTF-16.
Note : Sur un système sain (UTF-8 partout), Python3 fonctionne à merveille ! C'est très agréable d'avoir de l'Unicode partout !
Ca, c'est clair, moi qui travaille avec une tonne de langues, sans Unicode ça serait horrible (déjà que le "legacy" est pas triste...).
Reste que le format d'enregistrement (UTF-8 dans un terminal et pour certaines API graphiques, UCS-4 pour d'autres API graphique, UCS-2/UTF-16 pour Windows) fait qu'on a quand même rajouté des trucs galères.
Moi-même hésite toujours dans mes programmes entre UCS-x et UTF-8, chacun ayant des avantages et inconvénients, malheureusement.
[^] # Re: Tout les bugs ? vraiment ?
Posté par ribwund . Évalué à 2.
À mon avis on en est très loin, les kernel hackers sont loin d'être convaincu par cette approche qui s'éloigne de la vision unix du FS (les noms de fichiers sont des bytes, seul '\0' et '/' sont interdits).
[^] # Re: Tout les bugs ? vraiment ?
Posté par Antoine . Évalué à 5.
Ce n'est pas forcément un problème, cela délègue juste la décision au niveau de l'userspace pour ce qui est de la façon d'interpréter les octets en question.
Bon, côté userspace on a les libc hackers et je ne suis pas sûr qu'ils soient plus compréhensifs :-)
# Super
Posté par vida18 . Évalué à 2.
[^] # Re: Super
Posté par Axone . Évalué à 8.
---> [ ]
# CLI et boîtes de dialogue
Posté par Christophe HENRY (site web personnel) . Évalué à 1.
Le genre de bibliothèque donnant la possibilité de faire afficher des boîtes de dialogue, confirmation, de choix, etc. sans devoir monter d'interface graphique.
[^] # Re: CLI et boîtes de dialogue
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Pour les modules écrit en pur Python, je trouve que la conversion est triviale ! L'outil 2to3 fait 90 à 100% du boulot. J'ai migré python-ptrace et Fusil (25.000 lignes de Python) en une après-midi.
[^] # Re: CLI et boîtes de dialogue
Posté par abramov_MS . Évalué à 2.
[^] # Re: CLI et boîtes de dialogue
Posté par Troy McClure (site web personnel) . Évalué à 3.
# Nouveautés
Posté par Victor STINNER (site web personnel) . Évalué à 4.
http://linuxfr.org/2008/10/02/24556.html
En plus de ça, je trouve que la liste des nouveautés 3.0 donnerait presque envie de faire une croix sur Python2 ! Je pense par exemple à l'annotation des fonctions ou aux arguments sous forme de mot-clé uniquement (« def pouet(*, cle=42): ... »). Il y a aussi la syntaxe {1, 2, 3} pour les ensembles (set), les « compréhensions de dictionnaires », etc.
[^] # Re: Nouveautés
Posté par abramov_MS . Évalué à 2.
[^] # Re: Nouveautés
Posté par Stephane Jeannenot . Évalué à 2.
PIL 1.1.6 fonctionne avec Python 2.6, même un paquet précompilé pour win existe : http://www.pythonware.com/products/pil/
Numpy : pas de paquet précompilé, cependant sous Linux je compile sans soucis l'extension qui a l'air de bien fonctionner pour mon utilisation
Scipy, pyQt4 : non testés
Quand à l'utilisation de ces extensions avec Python 3, laissons un peu de temps aux développeurs pour absorber les changements et nouveautés. Rien n'empêche de contribuer aussi rapports de bugs, corrections, etc ...
Pour les impatients, compiler l'interpréteur et les extensions nécessaires en attendant les paquets "tout prêts" ;)
# C'est l'histoire ...
Posté par Batchyx . Évalué à 1.
Il télécharga donc la dernière version, mais, malheur ! Cela ne marchait pas. Python renvoyait une erreur de syntaxe sur une bête ligne avec un print ...
C'est vrai qu'en allant sur le site et en cherchant ''téléchargement'', c'est très facile de prendre la version 3.0. Le texte il commence par parler de programmation, donc le mec qui veut que un interpréteur, il zappe...
Au final, il à posé des questions au développeur qui lui a gentiment indiqué que ses scripts ne marchent pas encore sur 3.0 ...
C'est dommage qu'il n'ai pas été prévu de bien distinguer un source 2.X d'un source 3.0 et c'est dommage...
[^] # Re: C'est l'histoire ...
Posté par Victor STINNER (site web personnel) . Évalué à 1.
[^] # Re: C'est l'histoire ...
Posté par yellowiscool . Évalué à 8.
Envoyé depuis mon lapin.
[^] # Re: C'est l'histoire ...
Posté par Larry Cow . Évalué à 2.
[^] # Re: C'est l'histoire ...
Posté par Batchyx . Évalué à 1.
Mais personne ne va s'amuser à utiliser py2exe avec un script à la con de 100 lignes qui sert à générer des headers C ou à faire d'autres trucs obscurs dans le but de compiler.
# Unicode partout
Posté par Wawet76 (site web personnel) . Évalué à 2.
Je vois d'ici le potentiel fabuleux de la variable « » (facilement accessible en bépo sur shift-espace).
[^] # Re: Unicode partout
Posté par Victor STINNER (site web personnel) . Évalué à 6.
File "", line 1
=1
^
SyntaxError: invalid character in identifier
Tous les caractères Unicode ne sont pas autorisés dans un identifiant.
http://docs.python.org/3.0/reference/lexical_analysis.html#i(...)
# Trollons peu trollons bien
Posté par Sébastien B. . Évalué à 3.
[^] # Re: Trollons peu trollons bien
Posté par dkremer . Évalué à 3.
La ligne de commande :
i=1 ; while [ "${i}" -ne "10" ] ; do echo $i ; python script_test_python_3.py ; python3 script_test_python_3.py ; i=$[${i}+1] ; doneLe code du script :
import time
a=time.time()
b=range(0,100)
c=[k**2 for k in b]
final = time.time() - a
print(final)
Les résultats (python 2.6 est en premier) :
1
0.000126838684082
0.000236034393311
2
0.000123023986816
0.000237226486206
3
0.000124931335449
0.000236988067627
4
0.000123977661133
0.000236034393311
5
0.000126123428345
0.000237941741943
6
0.000127077102661
0.000236988067627
7
0.000124931335449
0.000236988067627
8
0.000123977661133
0.000236988067627
9
0.000125885009766
0.000236034393311
Les deux version packagées dans ma distribution :
Python 3000 :
Nom : python3
Version : 3.0-3
URL : http://www.python.org
Licences : custom
Groupes : --
Fournit : --
Dépend de : bzip2 gdbm openssl>=0.9.8i zlib
Dépendances opt. : tk: for IDLE, pynche and modulator
Requis par : --
Incompatible avec : --
Remplace : --
Taille (installé) : 60488,00 K
Paqueteur : Allan McRae <allan@archlinux.org>
Architecture : i686
Compilé le : dim. 07 déc. 2008 05:55:39 CET
Installé le : dim. 07 déc. 2008 14:04:00 CET
Motif d'installation : Explicitement installé
Script d'installation : Non
Description : Next generation of the python high-level scripting language
Python 2.6 :
Nom : python
Version : 2.6-2
URL : http://www.python.org
Licences : custom
Groupes : --
Fournit : python-elementtree python-ctypes
Dépend de : db bzip2 gdbm openssl>=0.9.8d zlib
Dépendances opt. : tk: for IDLE, pynche and modulator
Requis par : boost gvim libieee1284 menumaker mercurial openoffice-base pil pycairo pygobject python-nose python-numeric vim
Incompatible avec : --
Remplace : python-elementtree python-ctypes
Taille (installé) : 62468,00 K
Paqueteur : Allan McRae <allan@archlinux.org>
Architecture : i686
Compilé le : lun. 27 oct. 2008 11:52:15 CET
Installé le : jeu. 06 nov. 2008 15:46:31 CET
Motif d'installation : Explicitement installé
Script d'installation : Non
Description : A high-level scripting language
Donc, je ne sais pas si c'est une bonne idée d'utiliser python 3 puisque le temps de calcul passe alors du simple au (quasi) double.
C'est grave non ? Et Guido van Rossum qui se plaignait que les autres langages de scripts devenaient des vraies poubelles et gagnait en lourdeur au fil de leur évolution ? Que se passe-t-il donc dans python 3 ?
[^] # Re: Trollons peu trollons bien
Posté par Stephane Jeannenot . Évalué à 3.
Kernel 2.6.18-6-k7
CPU : Athlon 1.2 GHz (*)
RAM : 512 Mo DDR
Python 2.6.1 et 3.0 compilés avec les options suivantes :
./configure --with-fpectl --with-wctype-functions --with-pymalloc --with-doc-strings --with-threads --with-signal-module --with-system-ffi --enable-ipv6
Compilateur (affiché dans la console interpréteur) :
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)]
Ensuite j'ai repris le test précédent, dont voici les résultats obtenus :
10 itérations : (moyennne, écart-type)
python 2.6.1 = ( 0.00012204382154655558 ; 4.133267903850333e-06 )
python 3.0 = ( 0.0001832379235161111 ; 1.0711521205702668e-05 )
10 échantillons c'est un peu faible, la tendance qui se dégage est que Python 3 est plus lent *sur ce test*, dans des conditions égales de compilation et d'exécution. Bien évidemment pour être affirmatif, il est nécessaire d'effectuer des tests de performances mettant en oeuvre des algorithmes choisis avec un nombre suffisamment grand d'échantillons.
Pour conclure, personellement, si j'ai besoin de performance de calcul je préfère de loin utiliser un algo en C ou Fortran que j'appelle dans l'interpréteur, c'est tellement simple et confortable.
[HS]
(*) Certains vont rire car parler de "performances" avec une telle machine face à celles d'aujourd'hui peut sembler incongru. Cependant elle n'a rien a envier aux netbooks à la mode et ronronne comme un chat depuis plus de 7 ans. (parfois le chat est enroué, saleté de poussière qui désaxe les ventilos !)
[/HS]
[^] # Re: Trollons peu trollons bien
Posté par dkremer . Évalué à 1.
Pour conclure, personellement, si j'ai besoin de performance de calcul je préfère de loin utiliser un algo en C ou Fortran que j'appelle dans l'interpréteur, c'est tellement simple et confortable.
Oui, dans ce cas, ça pose la question de savoir pour quel domaine d'utilisation python est-il conçu. Étant un langage interprété, est-ce que la performance peut être sacrifiée sur l'autel de la souplesse de développement et d'exécution ?
Est-ce que la performance est un problème pour l'utilisation de Python ? À vrai dire, je me pose la question de savoir dans quel cas la performance est un problème critique. Il est vrai que j'aimerai parfois que Python soit ultra rapide, mais c'est vrai qu'un calcul peut être à même d'être plus rapidement réalisé avec le C qu'avec Python.
Je voudrai noter cependant que, ayant consulté le livre de référence de Python (Python en concentré), il suggère d'utiliser les modules issus de la bibliothèque gmp pour les calculs numériques. Enfin à vous de voir.
[^] # Re: Trollons peu trollons bien
Posté par Antoine . Évalué à 2.
En fait non. Si tu as vraiment besoin de calculs très rapides sur de grosses quantités de données, tu fais des sous-routines en C.
Python 3.0 est plus lent sur trois points :
- le calcul de petits entiers car tous les entiers sont maintenant de précision arbitraire ("infinie" si ce n'est bien sûr la mémoire virtuelle disponible pour le processus)
- les chaînes de caractères qui sont désormais unicode par défaut (avec une occupation mémoire doublée et donc une moins grande efficacité des caches)
- la couche IO qui a été réécrite, et pour l'instant en majorité en Python plutôt qu'en C
Les deux premiers points ne sont pas cruciaux, car les pertes ne sont pas énormes comparées au coût d'interprétation qui lui n'a pas vraiment changé. Le troisième point devra être corrigé dans Python 3.1.
Il y a des comparaisons de performance entre Python 2.5 / 2.6 / 3.0 ici (mais attention, versions beta, pas versions finales, il y a eu quelques corrections entre temps) :
http://mail.python.org/pipermail/python-dev/2008-August/0819(...)
Et Guido van Rossum qui se plaignait que les autres langages de scripts devenaient des vraies poubelles et gagnait en lourdeur au fil de leur évolution ?
Je ne sais pas à quoi tu fais allusion mais il parlait certainement de l'accumulation de bricolages syntaxico-sémantiques qui mène à ce à quoi ressemblent Perl ou Javascript aujourd'hui. De ce côté-là Python 3 est effectivement une simplification.
[^] # Re: Trollons peu trollons bien
Posté par reno . Évalué à 2.
Quel encodage utilise Python?
Parce que si c'est UTF-8, il n'utilisera pas plus de place pour les chaines ASCII qu'ASCII justement..
[^] # Re: Trollons peu trollons bien
Posté par Zenitram (site web personnel) . Évalué à 2.
De ce que j'ai compris, c'est un "vrai" support d'Unicode (sinon aucun intérêt d'en parler, on peut toujours faire de l'UTF-8 avec des vieux softs, le problème d'UTF-8 étant pour les découpages/comptage), donc ça va doubler voir quadrupler (le post initial parle de doubler, donc UTF-16 comme pour Java? Pas UCS-4 comme sous Linux?)
Parce que si c'est UTF-8, il n'utilisera pas plus de place pour les chaines ASCII qu'ASCII justement..
Oui, mais bon, la on est sur un site français, pas américain, donc l'ASCII est un peu limité pour nous. D'ailleurs, "limité" ne fait pas 6 octets en UTF-8... Donc pour notre langue, UTF-8 utilisera plus de place que le latin-1 habituel.
[^] # Re: Trollons peu trollons bien
Posté par Antoine . Évalué à 3.
C'est une option à la compilation de Python. Les binaires officiels Windows sont compilés en UTF-16 (parce que ça rend la communication avec les API Windows plus efficace), quant aux version Linux ça dépend de la politique de la distribution (Debian compile en UTF-32, Mandriva en UTF-16).
[^] # Re: Trollons peu trollons bien
Posté par reno . Évalué à 1.
J'aimerai bien savoir en quoi UTF-8 n'est pas un vrai support d'Unicode..
La réponse du dessous que c'est une option a la compilation parait plus logique, donc cela veut dire que l'utilisation mémoire sera soit grosso-modo inchangée par rapport a latin-1/ASCII (bin oui, compté le nombre d'accent utilisé en moyenne dans une phrase..) soit doublée (UTF-16) soit quadruplée (UTF-32).
Je comprends qu'on utilise UTF-16 sous Windows l'OS utilisant UTF-16, par contre sous Linux utiliser UTF-16 ou UTF-32 j'ai plus de mal a comprendre: les CPUs sont tres puissant donc "gacher" de la mémoire/du cache, cela ne me parait pas optimal..
[^] # Re: Trollons peu trollons bien
Posté par Zenitram (site web personnel) . Évalué à 3.
Avec UTF-8, tu as plein de merdes : tu coupes là ou il ne faut pas et hop tu as des octets invalides, ça rame pour compter (strlen() comptent le nombre d'octets, pas le nombres de caractères) etc.
(c'est le même problème dans 0.001% des cas avec Windows toutefois, car c'est que UTF-16, les plages >0x7FFF étant sur 2 fois 2 octets).
Bref, pour le traitement de caractères, UTF-16/32 a plein d'avantages (perf etc...)
par contre sous Linux utiliser UTF-16 ou UTF-32 j'ai plus de mal a comprendre:
* Java utilise UTF-16 (ou UCS-2 je ne sais plus), donc pour un binding c'est mieux
* UCS-4 /UTF-32 est la norme habituelle de Linux pour Unicode. J'avoue avoir du mal à comprendre le choix d'UTF-16 pour les compilations Linux du coup.
cela ne me parait pas optimal.
UTF-16/32 est loin d'être optimal aussi pour certaines choses. Il y a des avantages et des inconvénients que ce soit UTF-8 ou UCS-4, faut choisir entre les inconvénients. Le choix est loin d'être simple.
En C/C++, du coup on laisse le choix au programmeur plutôt que de lui forcer la main.
[^] # Re: Trollons peu trollons bien
Posté par Victor STINNER (site web personnel) . Évalué à 4.
[^] # Re: Trollons peu trollons bien
Posté par Zenitram (site web personnel) . Évalué à 2.
Ca, c'est sympa pour les codes >0xFFFF sous Windows et Mandriva... Bon, ca concerne 0.01% de la planète, mais ça va leur faire mal niveau "on accepte tout le monde" (bon, honnêtement, j'en ai vu des caractère bizarres, mais pas encore ce genre de caractères...)
Mais pourquoi diable Mandriva a compilé en UCS-2 si j'en croit le post au dessus?
[^] # Re: Trollons peu trollons bien
Posté par Antoine . Évalué à 5.
Non, Python 3 décompose le caractère en deux codes :
Python 3.1a0 (py3k, Dec 7 2008, 21:13:32)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxunicode
65535
>>> s = chr(0x10000)
>>> len(s)
2
>>> s
'\U00010000'
>>> s.encode('utf-32le')
b'\x00\x00\x01\x00'
(sous un build UCS-4, len(s) retournerait 1)
[^] # Re: Trollons peu trollons bien
Posté par lepoulet . Évalué à 2.
Tu fais référence à tous les nouveaux mot-clefs (as, with, mais aussi True et False...) ?
[^] # Re: Trollons peu trollons bien
Posté par dkremer . Évalué à 3.
[ i**2 for i in range(0,100) ]et les fonctions map() et filter() qui sont issues des langages fonctionnels. C'est typiquement une redondance du langage, ce qui est à l'opposé de ce qu'a souhaité le concepteur.
C'est une philosophie à l'opposé du langage Perl, où il y a toujours plusieurs possibilités pour faire une chose précise.
[^] # Re: Trollons peu trollons bien
Posté par Antoine . Évalué à 3.
Ils ne sont pas nouveaux, c'est juste qu'avant ce n'étaient pas des mots réservés (on pouvait appeler une variable "as" ou "True" par exemple). En d'autres termes, le langage n'est pas devenu plus complexe de ce côté-là, mais il y a eu quelques ajustements dans l'implémentation.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.