Bon ok, c'est voué à l'échec, mais n'empêche !
J'aime les challenges, donc faisons bouger le monde, révoltons nous, menaçons de faire du perl (euh non) ou du ruby (non plus) à la place
Bref, si vous aussi vous n'aimez pas la verbosité du string.format pythonesque, alors signez mes très chères moules, signez !
C'était un message de l'association des castors lapons
http://www.petitiononline.com/PyString/
Journal Il faut sauver le soldat %
26
fév.
2009
# Mouhahahaha
Posté par Victor STINNER (site web personnel) . Évalué à 2.
[^] # Re: Mouhahahaha
Posté par cho7 (site web personnel) . Évalué à 2.
Si c'est juste philosophique, je trouve ça dommage. Pour de vrai hein
[^] # Re: Mouhahahaha
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Au sujet de ton argumentation, je la trouve très faible.
... string.format which is (...) more _verbose_
boring to type
The brackets are not easily found by our fingers on azerty keyboard (altgr + [5/+])
the resulting expression is longer
good syntaxic sugar
Tu ne vas pas convaincre les développeurs avec ces arguments. L'argument de la concision est opposé aux principes de Python : relit « import this ».
Dans la balance, il faut aussi mettre les défauts de cette notation qui sont nombreux et ont plus de poids selon moi :
http://linuxfr.org/comments/1011166.html#1011166
[^] # Re: Mouhahahaha
Posté par cho7 (site web personnel) . Évalué à 5.
Oui, je trouve ça plus simple à écrire, et c'est tout !
écrire {0} ca revient à tapper [altgr+4][shift+0][altgr+=] soit 6 touches (sans compter le .format(...)) là ou avant je faisais [shift + %][s] soit 2 touches. C'est tout. Alors après on peut dialoguer 10 ans sur le fait de savoir si c'est mieux, moins bien, pareil ou pas, mais moi, à mon très humble niveau, bah je préfère tapper %s et donc si _ça ne coute rien_ (et j'insiste là dessus, car je ne sais pas ce que ça peut couter, justement), bah je préfèrerai que les gentils développeurs de python ne touchent pas au %.
Après pour l'histoire des erreurs, de l'homogénéité du langage et tout et tout, c'est sûrement vrai d'autant que t'es impliqué dans le développement python donc tu sais sûrement plus que moi de quoi tu parles, mais pour l'usage quasi quotidien que j'ai de python (une sorte de couteau-suisse), j'ai jamais eu de soucis avec le % !
Voilà, donc non je n'irai pas dialoguer avec les gens de la mailing list python, car comme tu l'as souligné, mon argumentation est pauvre et je vais me prendre une volée si je tente de dialoguer avec des gens qui s'impliquent vraiment.
Mais bon, je me disais, une pétition ca prend 4 minutes à écrire, j'ai pas trop besoin d'argumenter, les gens qui sont ok signent, les autres passent leur chemin, et tout le monde il est content, et je moi je m'auto-congratule à constater que j'suis pas tout seul à aimer le % :)
[^] # Re: Mouhahahaha
Posté par psychoslave__ (site web personnel) . Évalué à 3.
[^] # Re: Mouhahahaha
Posté par cho7 (site web personnel) . Évalué à 2.
Surtout que pour avoir déjà été obligé de tappoter sur un qwerty quelques temps, je sais qu'après c'est pas évident de jumper d'un clavier à l'autre, car même en étant mauvais au qwerty, je choppais des habitudes malgré tout
Et dans la vraie vie les 3/4 des claviers sont azerty, donc autant rester sur le standard de fait.
[^] # Re: Mouhahahaha
Posté par claudex . Évalué à 3.
Je pense quand même que dans la vrai (en tout cas dans ma planète), la majorité des clavier sont imprimer avec la disposition chinoise (je ne sais pas ce que c'est et je ne sais même pas si je sais l'écrire) ou en qwerty (si c'est la disposition qu'ils utilisent majoritairement en inde)
De plus de quel azerty parles-tu? Par exemple l'azerty belge a les accolades en altgr+9 ou 0.
Donc un standard dans les clavier, à part au milieu de la France, je ne vois pas d'où tu le sort.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mouhahahaha
Posté par cho7 (site web personnel) . Évalué à 1.
Bien sûr que statistiquement il y a sûrement beaucoup plus de clavier chinois dans le monde ou de qwerty que mon azerty, et je te crois sur parole quand tu me dis que l'azerty belge n'est pas comme l'azerty français. Mais moi, dans ma vraie vie à moi qui vit en france, je me fiche royalement des dispositions des pays d'à coté, car chez moi les claviers sont tous les mêmes à quelques détails près. Que ce soit au boulot, chez des amis, ou sur tous mes précédents pc, les touches étaient à peu près au même endroit, donc oui l'azerty est pour moi un standard, et manque de pot les accolades sont très mal situées dessus.
[^] # Re: Mouhahahaha
Posté par claudex . Évalué à 2.
C'est ce genre d'arguments qui fait que tu te retrouve (cas vécu, mais sous windows), avec un logiciel qui n'utilise pas le mappage par défaut de windows mais l'azerty français parce que le logiciel est en français.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mouhahahaha
Posté par Maclag . Évalué à 5.
Les chinois utilisent un clavier qwerty standard.
De toute façon ils tapent leurs caractères soit en suivant la phonétique (le plus courant et de loin), soit suivant un code qui décrit le dessin du caractère.
Le chinois simplifié compte environ 20,000 caractères, donc ils ne se sont jamais fait ch... à trouver une disposition adaptée à ça.
HS1: Je n'ai pas connaissance d'un Dvorak adapté au chinois simplifié. Mais il faut se rappeler aussi que le "Chinois" comme langue, c'est en fait le Mandarin pour la Chine continentale et Taiwan, et le Cantonais pour HK et le Canton (enfin pour ces deux derniers on voit une nette progression du Mandarin aussi). Bref, il va falloir faire plusieurs Dvorak chinois...
HS2: Pour ceux que ça intéresse, le dessin du caractère, il faut savoir que les idéogrammes chinois doivent être dessinés suivant un ordre précis dans les traits, avec une direction précise de la plume. Ainsi, un trait "horizontal" n'est pas un simple trait horizontal, c'est un trait tracé de gauche à droite, qui intervient à une certaine étape précise et prévisible -quand on y comprend quelquechose- dans le dessin. Ainsi, à partir d'une description de l'enchaînement des traits élémentaires sans indiquer leur position précise, le logiciel d'entrée peut proposer les caractères correspondant.
[^] # Re: Mouhahahaha
Posté par psychoslave__ (site web personnel) . Évalué à 6.
ah non alors. Je me suis enquiquiné toute ma vie à utiliser du windows, alors c'est pas maintenant que je rox les ours que j'vais apprendre un autre système !
Surtout que pour avoir déjà été obligé d'utiliser un unix quelques temps, je sais qu'après c'est pas évident de jumper d'un système à l'autre, car même en étant mauvais avec unix, je choppais des habitudes malgré tout
Et dans la vraie vie 90% des postes sont sous windows, donc autant rester sur le standard de fait.
[/ironie]
/me satisfait d'avoir appris à utiliser la disposition bépo et à utiliser un système unix.
[^] # Re: Mouhahahaha
Posté par arenthis . Évalué à 2.
Tu auras les doigts tellement exercés pour les {} que ça te semblera même plus rapide :)
[^] # Re: Mouhahahaha
Posté par cho7 (site web personnel) . Évalué à 2.
[^] # Re: Mouhahahaha
Posté par claudex . Évalué à 3.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mouhahahaha
Posté par cho7 (site web personnel) . Évalué à 2.
On sélectionne par exemple le texte qu'on veut mettre en gras, on clique sur le bouton "Gras" et hop plop devient \textbf{plop}
[^] # Re: Mouhahahaha
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -1.
[^] # Re: Mouhahahaha
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Physique, pardon, physique. Les balises de mise en forme logique, c'est ce qu'il faut utiliser à la place.
[^] # Re: Mouhahahaha
Posté par Yth (Mastodon) . Évalué à 1.
Yth.
[^] # Re: Mouhahahaha
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mouhahahaha
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Mouhahahaha
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Accessoirement, dans la branche Python 2.x, aucune fonctionnalité n'est supprimée depuis Python 2.0 (sorti en 2000). Donc ton « brave % » restera jusqu'à la mort de Python2... et c'est pas encore prévu. Donc, tu t'inquiètes un peu tôt je trouve. Personne ne t'oblige à utiliser Python3.
[^] # Re: Mouhahahaha
Posté par Victor STINNER (site web personnel) . Évalué à 1.
[^] # Re: Mouhahahaha
Posté par cho7 (site web personnel) . Évalué à 3.
PEP 3101: Advanced String Formatting. Note: the 2.6 description mentions the format() method for both 8-bit and Unicode strings. In 3.0, only the str type (text strings with Unicode support) supports this method; the bytes type does not. The plan is to eventually make this the only API for string formatting, and to start deprecating the % operator in Python 3.1.
[1] http://docs.python.org/3.0/whatsnew/3.0.html
[^] # Re: Mouhahahaha
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Il y a beaucoup de conditionnel... Parfois, des fonctions marquées comme dépréciées survivent de longue années, voir perdent leur status « déprécié » plus tard :-)
[^] # Re: Mouhahahaha
Posté par Buf (Mastodon) . Évalué à 5.
[^] # Re: Mouhahahaha
Posté par cho7 (site web personnel) . Évalué à 5.
Pour rappel : "eventually" signifie "finalement" ou "au bout du compte", et "actually" signifie "en fait"
# J'aime pas les %
Posté par 태 (site web personnel) . Évalué à 4.
Si jamais j'ai l'idée bizarre de faire un print, je préfèrais utiliser sa variadicité :
print "My name is ", name[:length], "."
Ou éventuellement (vu qu'en py3k, ça ne passera sans doute pas) faire des concaténations de chaînes.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: J'aime pas les %
Posté par Bozo_le_clown . Évalué à 2.
Quoique pour éviter tout problème, je préfère entourer systématiquement mes variables entre accolades ${name} au lieu de $name
[^] # Re: J'aime pas les %
Posté par nicoastro . Évalué à 1.
Surtout oh surtout au grand jamais malheureux sinon autant faire du php /o\
Comment on fait quand les chaînes sont relativement longues, contiennent plus de trois variables tout en gardant le code relativement visible (ie. en gardant l’ordre dans lequel apparaissent les éléments dans la chaîne) ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: J'aime pas les %
Posté par Victor STINNER (site web personnel) . Évalué à 7.
Cette notation souffre de défauts, il existe la forme « "%s" % var » et la forme « "%s" % (var1, var2) », et la première est source de problèmes :
>>> x="1 2"; print "%s" % x
1 2
>>> x=(1, 2); print "%s" % x
Traceback (most recent call last):
File "", line 1, in
TypeError: not all arguments converted during string formatting
Il est difficile d'expliquer pourquoi « parfois ça marche, parfois non ». Il faut utiliser la 2e forme qui est plus laide (virgule toute seule qui semble bizzare) dans ce cas :
>>> x=(1, 2); print "%s" % (x,)(1, 2)
Il existe une 3e forme où les arguments sont nommés :
>>> print "%(truc)s" % {'truc': (1, 2)}(1, 2)
Le problème est le suffixe S qui semble sorti de nulle part et qu'on oublie facilement :
>>> print "%(truc)" % {'truc': (1, 2)}Traceback (most recent call last):
File "", line 1, in
ValueError: incomplete format
Bref, la notation « format % arguments » est concise mais est source de problèmes subtiles, difficile à voir pour un œil non entrainé.
Anecdote : La traduction française de Gajim comportait un bug. Je me souviens plus des détails, mais c'était une erreur du genre : « Login : %(login)s » qui était traduit « Identifiant : %(login) ». Le S étant oublié, le formatage de la chaîne lance une erreur. Mais bon, je pense qu'un traducteur (très souvent quelqu'un qui ne programme pas) peut aussi faire des bêtises avec la notation "{...}".
[^] # Re: J'aime pas les %
Posté par Guillaume Knispel . Évalué à 4.
Et alors ? C'est pratique. La pureté n'a aucun intérêt si elle engendre des trucs lourds qui sont obligatoires alors que les trucs légers et pratiques (mais qui ont certes aussi leur défauts) sont supprimés.
Il faut utiliser la 2e forme qui est plus laide (virgule toute seule qui semble bizzare) dans ce cas
C'est n'importe quoi comme argument de vouloir supprimer le % parce les tuples singleton sont laids.
[^] # Re: J'aime pas les %
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Non, j'essayais de dire que .format() n'a pas deux formes pour les arguments indexés (en opposition aux arguments nommés) :
* "%s" % x
* "%s" % (a, b)
Dans le 1er cas, le comportement change selon que x est un tuple ou non. On peut tomber dans le panneau.
Tandis qu'avec format :
* "{0}".format(x)
* "{1}, {2}".format(a, b)
La syntaxe est homogène et ne prête à confusion. Pour reproduire le comportement « args=("cle", "valeur"); "%s=%s" % args », on doit utiliser le caractère étoile qui indique explicitement d'on « déroule » le tuple : "{0}={1}".format(*args).
[^] # Re: J'aime pas les %
Posté par Guillaume Knispel . Évalué à 2.
Mais je reste quand même un peu sentimentalement attaché au %
J'imagine que dans quelques années je l'aurais oublié. Snif.
[^] # Re: J'aime pas les %
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Très très mauvaise idée au niveau internationalisation.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Voila ce qui arrive quand on veut tout transformer en methode
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
[^] # Re: Voila ce qui arrive quand on veut tout transformer en methode
Posté par dkremer . Évalué à 3.
>>> a=1
>>> a.__add__(2)
3
>>>
[^] # Re: Voila ce qui arrive quand on veut tout transformer en methode
Posté par benoar . Évalué à 4.
(1).__add__(2)[^] # Re: Voila ce qui arrive quand on veut tout transformer en methode
Posté par dkremer . Évalué à 1.
# J'ai rien compris...
Posté par windu.2b . Évalué à 6.
Mais en attendant, si on avait pu avoir un semblant d'explication du problème, ça aurait pas été un mal...
[^] # Re: J'ai rien compris...
Posté par plagiats . Évalué à 5.
Tu noteras que la seconde technique est plus longue à écrire.
D'après l'auteur du journal, la technique utilisant % sera déclarée obsolète dans la prochaine version mineure de Python 3, d'où un appel à sauver le soldat %.
[^] # Re: J'ai rien compris...
Posté par dkremer . Évalué à 1.
[^] # Re: J'ai rien compris...
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
"Hello {0}! How are you today {0}?"
Non, vraiment, meurs % ! Meuuuuurs ! >:-)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: J'ai rien compris...
Posté par cho7 (site web personnel) . Évalué à 2.
[^] # Re: J'ai rien compris...
Posté par dkremer . Évalué à 5.
Par exemple :
num_loto = 42
je_gagne = 10000
print "mon numero de loto est %d, je gagne %d"%(num_loto, je_gagne)
Maintenant, cette caractéristique faisait double emploi avec l'utilisation des dictionnaires :
ma_phrase = "bonjour %(perso1)s, bonjour %(perso2)s"%{'perso1':'julia','perso2':'franz'}
print ma_phrase
On a aussi les templates :
import string
ma_phrase = string.Template('$arg1 additionne a $arg2 donne $arg3')
ma_phrase.substitute(arg1='1', arg2='2', arg3='3')
print ma_phrase
Tout ça fait qu'il est difficile de s'y retrouver pour un débutant qui voudrait apprendre ce langage. Quel outil de formatage ? Dans quelle condition ? Et on s'éloigne alors de la philosophie de Python.
Ceux qui viennent du C se retrouveront facilement dans le formatage par arguments dans la chaînes, ce qui est un ersatz et est vraiment hétérogène avec le reste du langage.
Python3, en cassant la compatibilité ascendante, vient résoudre ce genre de petits problèmes du langage.
Mais les nostalgiques protestent, parce que ça va demander des efforts de se ré-adapter alors qu'on avait déjà une méthode connue.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: J'ai rien compris...
Posté par cho7 (site web personnel) . Évalué à 5.
Pareil, c'est exactement ce que je disais à un gars dans les forums de developpez.net, et qui me disait je cite :"Je ne trouve pas que c'est logique de devoir connaître les tuples et la surcharge d'opérateur pour pouvoir comprendre comment le formatage peut fonctionner."
Moi quand j'ai commencé le python j'en avais rien à secouer de savoir ce qu'était réellement les parenthèses derrière le %, j'ai juste compris que chaque chaine pouvait être formatée simplement via le "%s%s"%(ma_variable1,ma_variable2) et je trouvais ça génial !
Mais on doit être une minorité faut croire, vu les vagues (mode marseillais) d'incompréhension qu'on soulève
[^] # Re: J'ai rien compris...
Posté par dkremer . Évalué à 2.
Donc, je pense que ce changement contribue à la simplicité du langage, qui se veut tout de même un des principaux atouts de python.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
# Une pétition ?
Posté par grosprout . Évalué à -10.
'Fin bon, si des amateurs veulent s'amuser avec ce gadget en toc, pourquoi pas.
[^] # Re: Une pétition ?
Posté par dkremer . Évalué à 1.
[^] # Re: Une pétition ?
Posté par cho7 (site web personnel) . Évalué à 5.
[^] # Re: Une pétition ?
Posté par grosprout . Évalué à -3.
[^] # Re: Une pétition ?
Posté par dkremer . Évalué à 3.
[^] # Re: Une pétition ?
Posté par Yth (Mastodon) . Évalué à 5.
- interprété, parce que pour le compilé j'ai le C qui me convient bien ;
- rapide ;
- peu verbeux ;
- a la syntaxe claire (au revoir bash, perl...) ;
- plutôt sans contraintes de typage, parce que si j'ai besoin de faire un truc super précis, ben j'ai encore le C, là ça serait plutôt pour moins me prendre le choux ;
- un bon paquet de bibliothèques variées et aisément disponibles ;
- ah tiens, s'il pouvait y avoir une killer-feature comme un interpréteur en ligne de commande, un shell du langage en somme, ça tuerait tout, pouvoir tester rapidement un fonctionnement, une fonction, sans écrire tout un programme, juste écrire le bout de code qui t'intéresse et voir ce qu'il donne, super pratique ça, ça manque a des langages comme le PHP ou même le javascript (pourtant ça serait faisable en js)... ;
- intéropérable évidemment (au revoir java (on est vendredi !), et visualbasic, la larme à l'oeil (mwarfff...)) ;
- qui permette aisément de faire un programme, un site web, un script, tout ça dans un même langage, histoire de ne pas en apprendre douze différents, je connais déjà le C en plus, deux langages plus le HTML/CSS/JS, ça suffit amplement ;
- qui soit adapté au calcul scientifique (bc c'est sympa mais un peu limité quand même) ;
- et qui fait ce qu'on attend de lui sans même avoir besoin de t'imposer de mettre $ devant tes noms de variables ;
- qui permette d'éviter de voir l'ignoblissime syntaxe venue de certains inutilisateurs du C qui consiste à mettre l'accolade ouvrante à la ligne, pouaaark !
Bref, ça fait pas mal de contraintes, j'en ai heureusement un sous la main.
Python.
Yth.
[^] # Re: Une pétition ?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Cela, c'est une connerie.
Je trouve que le $ devant les variables en bash, en perl génial. C'est d'une clarté limpide. En plus, en perl, il y en a toujours (même à l'affectation). Il n'y a aucune confusion avec les mots clef du langage.
L'horreur, c'est le CSH qui est tordu sur l'usage du $.
OK, perl a des problèmes de lisibilité mais ce n'est pas à cause du $ devant les variables.
En fortran 90, j'avais la convention suivante, tous les mots clef du langage en petit caractère et toutes les variables en majuscules. Le code était limpide.
Faire resortir les mots clefs du langage par rapport aux variables, ou inversement, est un excelente idée,
[^] # Re: Une pétition ?
Posté par MsieurHappy . Évalué à 6.
[^] # Re: Une pétition ?
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
Je n'imprime pas en couleur mes listings.
Il m'arrive d'édité à distance avec vi sans couleur.
Je n'aime pas que les règles de programmation dépendent de la couleur des choses. Un bon exempe d'un langage que j'aime beaucoup mais dont le créateur génial (Chuck Moore) a été, à mon sens, trop loin est colorForth.
http://en.wikipedia.org/wiki/ColorForth
http://www.colorforth.com/
[^] # Re: Une pétition ?
Posté par Jean B . Évalué à 5.
Oui mais vu que en Python tout est objet même les fonctions, classes, modules etc tu te retrouverai a préfixer absolument tout avec un dollar, sauf une grosse douzaine de mot clé. Un peu ridicule ...
[^] # Re: Une pétition ?
Posté par Yth (Mastodon) . Évalué à 2.
Franchement, pour coder en PHP tout les jours pas vraiment par choix, ces $ devant chaque nom de variable me fatiguent. C'est exactement comme le ; en fin de ligne : totalement inutile, ça plante directement dès qu'ils n'y sont pas, la correction de l'erreur est toujours syntaxiquement évidente.
Le seul et unique intérêt du $ devant les noms de variable est en bash comme en PHP de les glisser directement dans les chaînes de caractères : echo "Bonjour $nom !" , ça c'est pratique.
Ben... C'est tout ce que j'ai trouvé...
Après, avoir de bonnes conventions de codage pour voir clairement les variables, leur type prévu ou leur utilisation, ou même leur champs d'action, c'est valable quel que soit le langage.
Mais je n'ai aucune difficulté à lire, même sans coloration syntaxique, un truc du genre :
for x in ma_liste:
print x
Ce n'est pas moins clair, au contraire, que :
foreach($ma_liste as $x) {
echo $x;
}
Yth.
[^] # Re: Une pétition ?
Posté par Amand Tihon (site web personnel) . Évalué à 2.
Plus répandu, il y a des chances. Mais un petit gars qui bosse sur KDevelop te dirait que ce n'est pas ce qu'il y a de mieux : on en arrive à la coloration sémantique, et je trouve l'idée vachement bonne !
http://zwabel.wordpress.com/2009/01/08/c-ide-evolution-from-(...) pour en savoir plus.
[^] # Re: Une pétition ?
Posté par Yth (Mastodon) . Évalué à 1.
Yth.
[^] # Re: Une pétition ?
Posté par Yth (Mastodon) . Évalué à 1.
C'est juste que j'appelais ça de la coloration syntaxique... A mon avis c'est simplement l'évolution logique de la coloration syntaxique, et ça me parait tellement évident que je suis surpris que des gens découvrent ça en le trouvant génial.
Mais ouais, c'est bien la coloration sémantique, c'est la fête !
Yth.
[^] # Re: Une pétition ?
Posté par fearan . Évalué à 3.
Le perl peut être très clair; tout dépend de celui qui l'écrit.
Une expression rationnelle peut être écrite sur plusieurs ligne, commentée en plein milieu; j'ai rarement vu la syntaxe, mais quand on fait un truc de malade, c'est très utile.
je peux écrire un code python illisible, je peux écrire du perl lisible. Par contre quand je dois écrire un truc qui me servira qu'une fois, j'en ai rien à battre qu'il soit lisible, j'ai besoin de le coder vite, et ça j'y arrive bien mieux en perl (et malgré tout il reste compréhensible, sauf pour les RE qui sont pas commentée :D ...)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Une pétition ?
Posté par windu.2b . Évalué à 3.
Y a quoi de mal à préférer mettre l'accolade à la ligne ?
Je veux bien croire que le 'dredi c'est permis... Mais quand même !
[^] # Re: Une pétition ?
Posté par Yth (Mastodon) . Évalué à 2.
J'ai personnellement horreur de cette façon d'écrire, je trouve que c'est nettement moins lisible que de laisser l'accolade à sa place à la fin de la ligne à laquelle elle appartient.
De plus, j'ai comme philosophie qu'une fonction bien écrite est courte, et se « voit » d'un seul regard. Une fonction ne devrait jamais faire plus d'un écran de long en nombre de lignes, et la moitié c'est déjà pas mal. Sachant que j'utilise en gros un terminal allongé à la hauteur de l'écran, un peu moins de 70 lignes, donc 35 lignes pour une fonction ressemble à une bonne limite floue.
Une fonction trop longue devient illisible, s'il faut faire défiler en haut ou en bas pur la lire en entier c'est insupportable, et plus elle est courte, moins les yeux doivent faire d'aller-retours, plus elle est lisible.
Tout en gardant une opération par ligne bien sûr.
Donc la ligne bêtement perdue par cette accolade qui en prend une pour elle toute seule, gène en soi la lisibilité en accroissant le nombre de ligne.
De plus, l'oeil voit bien les blocs de texte, pour repérer une fonction dans son code, on fait défiler et on regarde la forme du texte, aidé par la coloration syntaxique. Si la fonction est entrecoupée de sauts de ligne incongrus, et de lignes perdues de partout, la fonction semble découpée en tronçons et on a du mal à savoir où elle commence et où elle arrête.
Attention, je ne dis pas qu'il ne faut pas sauter de lignes parfois dans du code, à certains endroits ça sépare des blocs logique et aide à la lisibilité du code, mais il ne faut pas le faire n'importe où.
C'est comme écrire un texte, un livre, tu utilises des paragraphes pour aérer, mais pas des tas de paragraphes d'une seule phrase non plus, le texte est regroupé en groupes de phrases logiques.
Bref, l'accolade à la ligne c'est, à mon sens, une perte de lisibilité.
Après c'est ma vie, mes couleurs, mon appréciation de la chose, mes gouts, mais c'est au moins un peu réfléchi comme avis, donc pas juste un lâché de troll dans le vent du matin :)
Yth.
[^] # Re: Une pétition ?
Posté par windu.2b . Évalué à 3.
Je trouve qu'elle sépare la déclaration de la fonction du corps de cette dernière.
De plus, comme elle se trouve seule et sur la gauche, elle ressort bien. Ce qui me permet de repérer d'un coup d'œil les limites d'un bloc logique, surtout que sa sœur se trouve aussi alignée, plus bas.
Ensuite, sur le fait qu'une accolade à la ligne, c'est une ligne de perdue... Je trouve l'argument moyen. D'abord, parce que quand on dit qu'une fonction ne devrait pas dépasser mes 70-80 lignes, c'est un ordre de grandeur et non une valeur figée. Ensuite parce que si on approche de cette valeur fatidique, et qu'on en est à décaler les accolades, c'est qu'on n'est pas en train de gratter où il faut. Il vaudrait mieux, AMHA, se pencher sur la découpe de la fonction en plusieurs, à factoriser son code, ...
[^] # Re: Une pétition ?
Posté par Yth (Mastodon) . Évalué à 1.
« Gagner » une ligne pour chaque accolade ouvrante rend la fonction plus compacte tout en étant à mon sens plus lisible : je vois mieux les blocs logique comme ça, une ligne vide ça a plein de sens, l'indentation en a aussi.
On est vraiment dans le visuel là, ce que mon oeil perçoit rapidement, d'un seul coup, avec le minimum d'analyse de la part du cerveau.
Et j'ai horreur de l'accolade à la ligne parce qu'elle me gène, et je sépare mes fonctions d'au minimum deux lignes sauf si elles sont très étroitement liées.
Donc ces lignes ce n'est pas du grattage pour faire tomber la taille sous une limite dure, c'est vraiment parce que je trouve ça illisible avec l'accolade à la ligne. Ca casse la logique de l'indentation, c'est laid, et j'aime pas ça :)
Yth.
[^] # Re: Une pétition ?
Posté par Guillaume Knispel . Évalué à 1.
C'est donc le MAAAAAAAL
# Viendez faire du Ruby...
Posté par Bastes . Évalué à 4.
[^] # Re: Viendez faire du Ruby...
Posté par Snarky . Évalué à 8.
Du coup, j'ai eu l'image de rugbymen en tablier en train de préparer des cookies... Je crois que je vais voir mon psy, et vite....
[^] # Re: Viendez faire du Ruby...
Posté par Bastes . Évalué à 2.
Bon, moi je suis immunisé, je m'est déjà méta-programmé. Comme quoi Ruby ça aide.
[^] # Re: Viendez faire du Ruby...
Posté par zebra3 . Évalué à 2.
http://flydamnit.com/wp-content/uploads/2006/07/115031293260(...)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# C Uber Alles
Posté par Grumbl . Évalué à 9.
Et ça, c'est royal...
[^] # Re: C Uber Alles
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
[^] # Re: C Uber Alles
Posté par 2PetitsVerres . Évalué à 3.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: C Uber Alles
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
[^] # Re: C Uber Alles
Posté par cho7 (site web personnel) . Évalué à 3.
[^] # Re: C Uber Alles
Posté par Victor STINNER (site web personnel) . Évalué à 4.
[^] # Re: C Uber Alles
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
.operateur.
C'est très pratique. J'ai deux vecteurs, je veux le produit scalaire
v1 .scalar. v2
J'ai deux tenseurs, je veux aussi le produit scalaire
t1 .scalar. t2
Je me suis battu avec des thésards pour avoir cet opérateur .scalar. et non pas * comme beaucoup pense. *, c'est l'opérateur produit, mais produit de quoi : scalaire, vectoriel... Avec l'opérateur *, on ne sais jamais le type du résultat de l'opération et les formlules mathématiques deviennent imbittables.
En C ou en C++, on ne peut pas faire cela et c'est bien dommage, les formules de math sotn bien moins claires et du coup le risque d'erreur est plus important.
Si on souhaite un langage qui puisse faire "des math", il est important de laisser libre champs aux opérateurs et ne pas se cantonner aux seules méthodes. Les méthodes cassent la symétrie et ne reflète pas la formule
v1.scalar(v2)
est très différent de
v1 .scalar. v2
Dans le second cas, on a bien un produit scalaire entre deux vecteurs, ces deux vecteurs étant au même niveau.
Je crois que c'est une des raisons pour lesquelles perl6 ne sera pas pure objet et que les concepteurs veulent garder l'aspect multi-fonctions.
En dehors des math, je n'ai pas d'opinion et je ne sais pas si cela est aussi important.
[^] # Re: C Uber Alles
Posté par 2PetitsVerres . Évalué à 1.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Fais un fork!
Posté par Fabimaru (site web personnel) . Évalué à 1.
[^] # Re: Fais un fork!
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Après, y'a ceux qui veulent rendre self implicite... Encore un grand débat qui brasse de l'air depuis des années alors qu'il a été expliqué à plusieurs reprises pourquoi self est une bonne chose et nécessaire pour certaines constructions (j'ai pas d'url sous la main) ;-)
[^] # Re: Fais un fork!
Posté par Victor STINNER (site web personnel) . Évalué à 3.
http://mail.python.org/mailman/listinfo/python-ideas
[Python-ideas] Making colons optional?
http://mail.python.org/pipermail/python-ideas/2009-February/(...)
[^] # Re: Fais un fork!
Posté par Bozo_le_clown . Évalué à 2.
do
_ do_something()
while condition()
qu'il faut remplacer tout logiquement par
while True:
_ do_something()
_ if not condition():
__ break
avec sa non moins fameuse PEP 315 reportée à la St Glin Glin
http://www.python.org/dev/peps/pep-0315/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.