<foo> simply produces <foo>in the text).
<URL: http://somewhere.tld/ >,
and it will be automatically made into a link.
(Do not try any other way or it might count as an attempt to spam.)mailto: URI,
e.g. mailto:my.email@somewhere.tld,
if you do not have a genuine Web site).
zEgg (2013-08-28T11:24:41Z)
"Python has some annoying misfeatures, for example the lack of the ternary x?y:z construction of C/C++/Perl, or a print construct which automatically adds a newline."
The ternary operator was added in python 2.5, but the order is different: x?y:z becomes y if x else z. I don't know. It sounds nice, but it's weird to read. I don't think it was THAT important to restrain themselves to two words. I would have preferred if x then y else z.
As for the print function, it was also modified in python 3 to allow no newline (but not by default): print("blah", end="")
Fork (2009-08-09T22:59:12Z)
J'ai repensé à cette entrée en essuyant un petit bug dû au mauvais comportement du modulo en C.
Par contre je me demande comment l'opérateur est implémenté en Python (est-ce qu'il y a un test pour savoir si l'opérande est négative, ou est-ce que c'est plus efficace que ça ?).
Ruxor (2003-11-10T16:17:22Z)
Ah non, je n'avais même pas pensé à Ruby (pourtant ça fait un moment que j'en entends régulièrement parler). Ceci dit l'avantage de Python pour moi était qu'il était déjà installé sur le serveur où j'ai mis le script (il ne faut pas négliger ce genre de détails, parfois on perd un temps fou à cette étape-là).
Damien (2003-11-10T14:46:49Z)
J'oubliais : as-tu jeté un coup d'oeil à Ruby ?
Personnellement, je préfère Python (sans doute aussi une question d'habitude), mais il possède de nombreux points forts (donc le fameux x?y:z).
Je vois Ruby comme un Perl "amélioré" ; il reprend certaines idées de Python.
Anonymous Coward #225 (2003-11-10T14:21:59Z)
Le grand inconvénient de Python c'est que ses implémentations sont merdiques pour la très bonne raison que son concepteur (van Rossum) est carrément minable en tout ce qui concerne compilation de langages : lambda expressions qui chient, bytecode lent à mourrir, etc. Les mauvaises langues prétendent que le dernier Perl exécute du Python plus vite que Python himself… Je ne suis pas allé vérifier, mais si c'était vrai, ce ne serait pas du meilleur effet ! Même si quand on programme en Python c'est rarement pour la performance pure.
Damien (2003-11-10T14:15:01Z)
Ok, je vois mieux ce que tu voulais dire ; désolé, j'ai répondu un peu vite et écrit des énormités.
Je ne cherche pas non plus à défendre Python envers et contre tout ; il a ses limites et ses défauts (sans parler des questions de goûts). Simplement, pour pas mal de tâches, il me semble très correct.
Ruxor (2003-11-10T14:00:42Z)
Expérimentalement, je constate que si je tape « test(0==0,1,1/0) » après avoir entré la définition que tu proposes, alors l'exception ZeroDivisionError est soulevée, ce qui montre bien que le 1/0 a été évalué. De même, si je pose « def frobnicate(): print "ZOINX"; return 42 » et que je tape « test(0==1,frobnicate(),1729) » alors il imprime ZOINX avant de retourner 1729, ce qui montre bien que frobnicate() a été évalué. Et tout cela est très sensé : Python fait du call-by-value et de l'évaluation hâtive (=non paresseuse), donc on ne peut pas empêcher les arguments d'une fonction d'être évalués ; c'est-à-dire qu'aucune fonction ne peut répondre à mon problème. L'opérateur x?y:z que je voudrais permettrait d'écrire 0==0?1:1/0 sans provoquer d'erreur, comme c'est le cas en C.
La FAQ de Python signale qu'on peut remplacer x?y:z par (x and [y] or [z])[0], et là, pour le coup, la sémantique est absolument la bonne (seul l'un de y ou z est évalué), mais ça me paraît absolument ignoble et hackesque comme solution, juste pour éviter la syntaxe x?y:z.
D'autre part j'ai parlé d'écrire a=1+(b=1) pas a=1+(b==1) (très différent). Mon point est que dans un langage qui autorise de toute façon les effets de bord ça n'a pas de sens de chercher à distinguer les « expressions » et les « instructions », et c'est à mon avis une erreur profonde de checher à les séparer sous prétexte que les mélanges seraient des hacks. Ce serait sensé si les « expressions » ne pouvaient *jamais* provoquer d'effet de bord, mais ce n'est pas le cas en Python, puisque je peux écrire a=1+frobnicate() et frobnicate() peut avoir des effets de bord, donc à ce moment là je ne comprends pas qu'on refuse de mettre b=1 à cet emplacement. En Haskell les choses sont clairement séparées puisque tout ce qui peut provoquer des effets de bord est nécessairement filé par la monade IO.
Quant au print, les explications proposées ne me convainquent pas du tout, mais c'est surtout une question de goût. Il est vrai que j'aurais peut-être dû écrire sys.stdout.write partout et éviter complètement le print.
Enfin, je ne me braque pas contre le Python, j'essaie de voir lucidement ses avantages et ses inconvénients, et comme tous les langages que je connais (ce qui commence à faire un paquet) il a les deux. Je ne peux pas dire avoir un langage préféré, parce que tous me déçoivent largement pour au moins certains aspects, et mon choix dépend évidemment de la tâche à accomplir.
Damien (2003-11-10T13:32:22Z)
Non, regarde bien ce que fait cette fonction ; dans le cas le plus fréquent (3 arguments), x est évalué, et selon sa valeur de vérité, y ou z est renvoyé, sans évaluation superflue.
Python insiste sur la clarté et évite autant que possible les hacks. Cela peut gêner au début, mais c'est très salutaire. Ton habitude du C introduit des parasites, qui disparaitront peu à peu si tu fais quelques efforts.
Depuis Python 2.3, on a de vrais booléens, donc l'expression que tu cites n'a plus de sens.
Concernant le print, une réponse précise à ton reproche se trouve ici :
<http://groups.google.com/groups?selm=8or0ps02hec%40news2.newsguy.com>
En gros, print est une fonction pour faciliter la vie dans les cas courants ; pour les autres cas, on utilise sys.stdout.write
Je ne cherche pas à t'évangéliser à tout prix, je souhaites juste t'encourager à approfondir Python pendant quelques temps, sans te braquer trop vite sur certains détails.
Ruxor (2003-11-10T12:39:49Z)
(Mon système de commentaires a bouffé les indentations, mais je comprends ce que tu voulais dire.)
Pour ce qui est de la fonction de test, j'ai l'impression qu'elle évalue tous ses arguments, ce qui n'est pas le cas du x?y:z du C (qui n'évalue que y ou z selon que x est vrai ou non) : c'est un problème si ces arguments peuvent provoquer des effets de bord ; or c'est justement souvent le cas quand on veut utiliser cet opérateur. Mais justement, une autre chose qui m'embête en Python, c'est que des constructions du genre a=1+(b=1), qui sont souvent utiles en C, sont ici interdites. Enfin bon.
Et sinon, la virgule dans le print enlève peut-être le retour chariot, mais il va y avoir une espace à la prochaine instruction print. Or je voulais n'avoir aucun whitespace.
Damien (2003-11-10T10:55:39Z)
Petites précisions à propos de Python :
* Sur l'absence d'opérateur d'alternative :
<http://www.python.org/peps/pep-0308.html>
On peut aisément rédiger une petite fonction qui joue ce
rôle…
------------------------------------------------------------
def test(*args):
l=len(args)
for i in range(1, l, 2):
if args[i-1]: return args[i]
if l%2: return args[-1]
------------------------------------------------------------
* En terminant un print par une virgule, on évite le
retour à la ligne automatique (c'est précisé dans la
doc).
Ne juge pas Python trop vite, prends le temps de t'y habituer et de l'explorer.
Anonymous Coward #224 (phi) (2003-11-09T23:54:32Z)
neither parentheses nor braces!
you may have a look at Python for Lisp Programmers, http://www.norvig.com/python-lisp.html
using indentation is rare among progr lang
Ruxor (2003-11-09T20:52:24Z)
Common Lisp is severely lacking in high-quality free (as in speech) implementations.
Anonymous Coward #221 (Fahree) (2003-11-09T13:42:36Z)
Common Lisp rocks!
Anonymous Coward #220 (Tofas) (2003-11-09T00:27:26Z)
Let the calendar madness continue !