Avant, en Python on pouvait simplement ouvrir un process comme on ouvre un fichier avec os.popen.
Maintenant, semble-t-il, à partir de python 2.4, ce n'est plus possible.
Il faut passer par le module subprocess. Et la ça m'agace.
http://docs.python.org/library/subprocess.html#replacing-os-(...)
Je ne vois pas trop l'intérêt d'un tel remplacement. Je n'aimais pas trop python comme ça (sans non plus le détester), mais là il baisse encore d'un cran dans mon estime.
Je sais, mon journal est inutil mais je m'en moque. Ca soulage c'est tout (vous étiez prévenu dans le titre).
Journal Journal inutile : Python c'est complêtement pourri, j'ai un exemple
1
juin
2010
# Avant après
Posté par 태 (site web personnel) . Évalué à 10.
Oui, et on peut encore au moins dans python2.6. Citons la PEP incriminée : http://www.python.org/dev/peps/pep-0324/
The functions and modules that this new module is trying to
replace (os.system, os.spawn*, os.popen*, popen2.*, commands.*)
are expected to be available in future Python versions for a long
time, to preserve backwards compatibility.
L'intérêt du remplacement c'est d'éviter d'avoir 12 façon différentes d'exécuter une commande dans os + celles de popen2 + celles de command en ajoutant des exceptions, en simplifiant la syntaxe dans certains cas (plus de shell escape).
[^] # Re: Avant après
Posté par totof2000 . Évalué à -4.
Enfin c'est du python, et j'ai un peu de mal à me faire à cette logique.
[^] # Re: Avant après
Posté par gaaaaaAab . Évalué à 2.
Se débarrasser de ces noms moisis, j'ai du mal à le voir comme une régression, mais bon, question d'appréciation.
[^] # Re: Avant après
Posté par Philippe F (site web personnel) . Évalué à 2.
au moins, avec subprocess, tu as une interface stable, qui couvre tous les besoins d'utilisation.
# Enfer et damnation !
Posté par Yth (Mastodon) . Évalué à 10.
Mais quelle horreur, vite pendons-le haut et court !
Yth......
[^] # Re: Enfer et damnation !
Posté par totof2000 . Évalué à -1.
[^] # Re: Enfer et damnation !
Posté par Thomas Douillard . Évalué à 10.
[^] # Re: Enfer et damnation !
Posté par Olorim . Évalué à -6.
J'ignore si dans ce cas, cette réunion est problématique, mais il me semble que l'avis de totof (même si avouons le, il est un peu extrémiste sur les bords... du moins sur ce sujet!), n'est pas à rejeter complètement.
Et ce n'est pas parce qu'une communauté décide quelque chose que c'est forcément super méga tiptop de la bal pour le projet, sinon les fork n'existerait pas!
Sur ce, Totof, si Python ça te plais pas, utilise un autre Langage.
[^] # Re: Enfer et damnation !
Posté par lolop (site web personnel) . Évalué à 2.
Après, la façon dont tu identifies le binaire, comment tu communiques avec ce process, comment tu fournis les paramètres, etc... ce ne sont que des options.
Après, tu as le communicate() pour les besoins simples (mais les plus courants), et tu peux utiliser des pipes vers stdin/stdout/stderr pour les choses plus compliquées.
Enfin, les os.spawn/exec, les popen & Co sont disponibles dans les versions 2.x de Python, ça ne change qu'à la version 3 qui est une évolution majeure du langage avec une réorganisation des librairies (et tu peux avoir la V2 et la V3 en parallèle).
Bref, pour moi c'est un journal en effet inutile à la base (comme indiqué dans le titre)... mais qui donnera peut-être des indications à certains.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Enfer et damnation !
Posté par totof2000 . Évalué à -1.
C'est une seule fonctionnalité: lancer un process séparé.
Après, la façon dont tu identifies le binaire, comment tu communiques avec ce process, comment tu fournis les paramètres, etc... ce ne sont que des options.
Mouais, réunir plusieurs fonctions (popen popen2, etc ..) en une seule (même fonctionnalité), pourquoi pas. Par contre je trouve que la façon de faire de Python n'est pas ddes plus intuitives. J'ai repris le code d'exemple que j'ai trouvé dans la doc tel quel, sans trop comprendre ce qu'il fait. Et pour un langage ou tout est explicite, je pense qu'il vaut mieux avoir 5 fonctions différentes pour 5 variantes d'une action plutot que d'avoir une seule fonction ou il faut spécifier explicitement des paramètres inutiles dans la plupart des cas. Je trouvais que l'ancienne version popen popen2, etc .. était plus claire dans son fonctionnement.
Après, tu as le communicate() pour les besoins simples (mais les plus courants), et tu peux utiliser des pipes vers stdin/stdout/stderr pour les choses plus compliquées.
Ce qui me gave c'est qu'un truc simple comme
pipe = os.popen("cmd", 'r', bufsize)
qui est très clair à comprendre devient
pipe = Popen("cmd", shell=True, bufsize=bufsize,stdout=PIPE).stdout
qui est quand même moins intuitif.
[^] # Re: Enfer et damnation !
Posté par lolop (site web personnel) . Évalué à 2.
Et c'est plus sécure: là, tu indiques explicitement que tu vas aller utiliser le shell pour lancer la commande, donc qu'il peut y avoir une tromperie à ce niveau - tu dois en être conscient.
Ceci dit, tant que tu restes en Python 2.x, tu peux continuer avec os.popen (mon treetaggerwrapper.py l'utilise encore, et il tourne très bien avec Python 2.6).
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Enfer et damnation !
Posté par totof2000 . Évalué à 3.
Enfin, quand tu compares les deux approches il n'y a pas photo. Dans le cas ou l'on veut récupérer le flux retourné par une commande la premiere solution reste la plus simple. Les histoires de pipe peuvent être intéressantes, mais pour le cas du popen simple, je trouve que ça embrouille plus qu'autre chose.
(AMA plus intéressant pour les nouveaux venus) les utilisations en Pipe shell.
C'est quand même sortir la grosse artillerie pour pas grand chose je trouve.
Et c'est plus sécure: là, tu indiques explicitement que tu vas aller utiliser le shell pour lancer la commande, donc qu'il peut y avoir une tromperie à ce niveau - tu dois en être conscient.
Mouais, ça reste dans l'état d'esprit Python, et c'est ce genre de truc que je n'aime pas. A force de devoir tout spécifier de façon implicite, on en arrive à l'incantation. Si j'ai besoin de programmer une appli nécessitant une fiabilité telle qu'il soit nécessaire de tout spécifier, je code en ADA, c'est fait pour.
[^] # Re: Enfer et damnation !
Posté par totof2000 . Évalué à 2.
[^] # Re: Enfer et damnation !
Posté par 태 (site web personnel) . Évalué à 2.
pipe = os.popen("cmd", 'r', bufsize)
qui est très clair à comprendre devient
pipe = Popen("cmd", shell=True, bufsize=bufsize, stdout=PIPE).stdout
A priori, si tu préfères l'implicite, tu dois pouvoir faire
Popen("cmd", "args", bufsize, None, None, PIPE, None, False, True).stdoutqui est carrément mois intuitif.[^] # Re: Enfer et damnation !
Posté par pampryl . Évalué à 6.
[^] # Re: Enfer et damnation !
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 4.
Par les pieds !
[^] # Re: Enfer et damnation !
Posté par calandoa . Évalué à 3.
Par exemple, un programme qui fonctionne avec la 2.5 va planter avec la 2.6, et trouver la ligne fautive va prendre plusieurs heures.
Si je compare avec Perl --- ok, je déconne --- avec du C je disais donc, il ne m'est jamais arrivé de voir un programme buguer à l'exécution à cause d'une compilation avec gcc 3.4 plutôt que 3.3 par exemple. Pourtant mon expérience avec Python est insignifiante par rapport au C.
Peut être que Python est un super langage, mais l'incompatibilité potentielle entre deux versions mineures est un des plus grands reproches que je peux lui faire. Un autre reproche est l'incompatibilité linux/windows/cygwin, mais bon, là ce n'est pas entièrement de sa faute.
[^] # Re: Enfer et damnation !
Posté par Yth (Mastodon) . Évalué à 3.
Mais ça arrive, je l'ai subi plusieurs fois, avec des logiciels tiers qui ne compilent plus sous une nouvelle version de GCC.
C'est plus courant qu'on ne le pense, parce que les paquets des distribs gèrent ces problèmes pour nous, mais ça arrive !
Une version d'un logiciel va très bien compilé avec un GCC, et plus du tout avec la version suivante de GCC. souvent pour pas grand chose non plus, une poignée de lignes ou de fonctions, et hop c'est reparti, pour nous, utilisateurs, il suffit d'attendre la version suivante qui ne manque pas d'arriver, et hop, c'est réglé.
Mais ce problème n'est pas spécifique au C.
Et... Je n'ai de la même manière jamais directement été confronté aux problèmes soulevés par les changements de version mineure de python !
Et pourtant je développe en python depuis sept ans maintenant, à de multiples niveaux : scripts, applications, web...
Par contre c'est sûr que le passage à python 3 impose des changements, mais c'est très visible, il y a des outils aidant à la transition, bref c'est une grosse étape, mais s'il y en a une prochaine du même acabit, elle sera peut-être dans dix ans, et dans quinze ans on aura encore le support des anciens modes de fonctionnement pour ne pas casser la compatibilité, en ajoutant un "import obsolete_stuff" à ses fichiers !
Yth.
[^] # Re: Enfer et damnation !
Posté par calandoa . Évalué à 2.
Alors qu'en python, je me rappelle d'une erreur dans SCons où une ligne du style :
« array += ['string'] » était interprété différemment selon que la 2.5 ou 2.6 était utilisée. Le problème apparaissant bien entendu longtemps après, à l'autre bout de l'arborescence, et m'a pris un bon moment à comprendre. Aprés l'avoir reporté, l'avis du mainteneur du projet était que faire marcher du code prévu pour la 2.5 avec la 2.6 n'était même pas envisageable et ça ne valait pas le coup de corriger le problème sur la branche du projet, c'est dire à quel point ce problème avec Python est flagrant.
[^] # Re: Enfer et damnation !
Posté par Jean B . Évalué à 1.
Si tu as un exemple de code qui tourne en 2.5 mais pas en 2.6 je suis preneur.
Bien sur je ne parle pas des extensions.
[^] # Re: Enfer et damnation !
Posté par Moonz . Évalué à 2.
[^] # Re: Enfer et damnation !
Posté par benoar . Évalué à 4.
[^] # Re: Enfer et damnation !
Posté par Jean B . Évalué à 1.
$ python2.5 -c 'as = 42'
<string>:1: Warning: 'as' will become a reserved keyword in Python 2.6
$ python2.4 -c 'as = 42'
$
[^] # Re: Enfer et damnation !
Posté par calandoa . Évalué à 2.
Il n'y a pas le code fautif, mais il y a de quoi le retrouver dans SCons à condition de mettre les mains dans le cambouis.
Et si vraiment tu t'embêtes, un petit google de « python 2.6 not compatible » devrait t'occuper un moment :^)
[^] # Re: Enfer et damnation !
Posté par Antoine . Évalué à 2.
Heu, c'est quand même assez rare, à moins que tu fasses des choses très crades.
Peut être que Python est un super langage, mais l'incompatibilité potentielle entre deux versions mineures
Il n'y a normalement pas d'incompatibilité entre deux versions mineures (sauf rares exceptions, encore une fois). Si tu en trouves une, http://bugs.python.org
# Et sinon ?
Posté par HardShooter . Évalué à 9.
# Tu te réveilles ?
Posté par GeneralZod . Évalué à 10.
Qu'est-ce qui t'agace ? D'avoir une interface unifiée pour lancer un processus ? Une interface tout aussi simple qu'avant mais plus robuste ?
[^] # Re: Tu te réveilles ?
Posté par KamelPanic . Évalué à 10.
# tu n'as qu' ...
Posté par manatlan (site web personnel) . Évalué à 4.
si ce n'est pas déjà fait (et suis persuadé que ça doit déjà exister)
sinon, subprocess : c'est vraiment bien ;-)
[^] # Re: tu n'as qu' ...
Posté par ribwund . Évalué à 4.
[^] # Re: tu n'as qu' ...
Posté par totof2000 . Évalué à 2.
# Pourquoi les gens critiquent toujours python avec de mauvais argument
Posté par Guillaum (site web personnel) . Évalué à 2.
Note The data read is buffered in memory, so do not use this method if the data size is large or unlimited.
(pour communicate)
et
Warning Use communicate() rather than .stdin.write, .stdout.read or .stderr.read to avoid deadlocks due to any of the other OS pipe buffers filling up and blocking the child process.
pour stdout/stdin/stderr
Comme il n'y a pas d'autre moyen de communiquer avec le sous processus, je fais quoi si je ne veut pas deadlocker et si j'ai BEAUCOUP de donnée ?
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par Gniarf . Évalué à 0.
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par nicolas . Évalué à 1.
Et encore heureux qu’on puisse lire n’importe quel fichier quelque soit ça taille et quelque soit le langage utilisé !
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par Gniarf . Évalué à 2.
sinon oui, avec un buffer tout va bien...
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par Frédéric Perrin (site web personnel) . Évalué à -1.
% perl sub fac { sub fac_aux { my ($n, $p) = @_; return $p if $n == 1; return fac_aux($n - 1, $n * $p); } my $n = shift; fac_aux($n, 1); } printf "\n%d - %d\n", fac(5), fac(1000000); ^D 120 - -1(Bon, le résultat est numériquement faux, mais l'exemple porte sur la récursion; sinon j'aurais utilisé une bibliothèque bignum.) On ne parlera pas de l'impossibilité de dire qu'on veut déclarer à l'avance ses variables pour au moins éviter les typos (il paraît que c'est un avantage).[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par koxinga . Évalué à 5.
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par lolop (site web personnel) . Évalué à 5.
setrecursionlimit(...)
setrecursionlimit(n)
Set the maximum depth of the Python interpreter stack to n. This
limit prevents infinite recursion from causing an overflow of the C
stack and crashing Python. The highest possible limit is platform-
dependent.
In [1]: import sys
In [2]: sys.getrecursionlimit()
Out[2]: 1000
In [3]: sys.setrecursionlimit(10000)
In [4]: def fac(n):
...: def fac_aux(n, p):
...: if n == 1:
...: return p
...: return fac_aux(n - 1, n*p)
...: return fac_aux(n, 1)
...:
In [5]: fac(5)
Out[5]: 120
In [6]: fac(999)
Out[6]: 402387260077093773543702433923003985719374864210714632543799910429938512398629020592044208486969404800479988610197196058631666872994808558901323829669944590997424504087073759918823627727188732519779505950995276120874975462497043601418278094646496291056393887437886487337119181045825783647849977012476632889835955735432513185323958463075557409114262417474349347553428646576611667797396668820291207379143853719588249808126867838374559731746136085379534524221586593201928090878297308431392844403281231558611036976801357304216168747609675871348312025478589320767169132448426236131412508780208000261683151027341827977704784635868170164365024153691398281264810213092761244896359928705114964975419909342221566832572080821333186116811553615836546984046708975602900950537616475847728421889679646244945160765353408198901385442487984959953319101723355556602139450399736280750137837615307127761926849034352625200015888535147331611702103968175921510907788019393178114194545257223865541461062892187960223838971476088506276862967146674697562911234082439208160153780889893964518263243671616762179168909779911903754031274622289988005195444414282012187361745992642956581746628302955570299024324153181617210465832036786906117260158783520751516284225540265170483304226143974286933061690897968482590125458327168226458066526769958652682272807075781391858178889652208164348344825993266043367660176999612831860788386150279465955131156552036093988180612138558600301435694527224206344631797460594682573103790084024432438465657245014402821885252470935190620929023136493273497565513958720559654228749774011413346962715422845862377387538230483865688976461927383814900140767310446640259899490222221765904339901886018566526485061799702356193897017860040811889729918311021171229845901641921068884387121855646124960798722908519296819372388642614839657382291123125024186649353143970137428531926649875337218940694281434118520158014123344828015051399694290153483077644569099073152433278288269864602789864321139083506217095002597389863554277196742822248757586765752344220207573630569498825087968928162753848863396909959826280956121450994871701244516461260379029309120889086942028510640182154399457156805941872748998094254742173582401063677404595741785160829230135358081840096996372524230560855903700624271243416909004153690105933983835777939410970027753472000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L
[PS. je suis preneur de ta solution pour mettre du Python dans les commentaires linuxfr]
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par lolop (site web personnel) . Évalué à 2.
(bon, après c'est éventuellement de la gestion de récursion terminale)
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par Antoine . Évalué à 1.
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par lolop (site web personnel) . Évalué à 3.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par dinomasque . Évalué à 2.
BeOS le faisait il y a 20 ans !
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par Moonz . Évalué à 1.
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par lolop (site web personnel) . Évalué à 2.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par Frédéric Perrin (site web personnel) . Évalué à 4.
setrecursionlimit(...)
setrecursionlimit(n)
Set the maximum depth of the Python interpreter stack to n. This
limit prevents infinite recursion from causing an overflow of the C
stack and crashing Python. The highest possible limit is platform-
dependent.
Cela ne fait que repousser le problème. Le vrai souci est que Python ne sait pas ce qu'est une récursion terminale, c'est pour cela qu'il met une limite à la profondeur de la récursion (et qu'il va consommer une mémoire proportionnelle à la profondeur de la récursion). Bon, chez moi ça segfault à partir de fac(2000), donc la mémoire utilisée viendra plus de Python que du code exécuté...
Pour mettre du code, j'ai utilisé la balise <pre>, avec l'option sous la boîte de commentaire « texte avec HTML sans retour chariot ».
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par lolop (site web personnel) . Évalué à 3.
En cherchant un peu sur tail recursion python, on trouve pourquoi ça ne sera pas de façon standard dans le langage:
http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi(...)
Et diverses solutions plus ou moins bonne pour le faire quand même:
http://paulbutler.org/archives/tail-recursion-in-python/
http://www.teamrubber.com/blog/python-tail-optimisation-usin(...)
http://fiber-space.de/wordpress/?p=349
Bon, si tu en as absolument besoin... ben tu ne feras pas de Python.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par Guillaum (site web personnel) . Évalué à 1.
def func(args):
if stop_condition(args):
return stop_value(args)
args = do_something(args)
return func(args)
def func(args):
while not stop_condition(args):
args = do_something(args)
return stop_value(args)
Ce qui donne pour la factorielle :
def fact(n):
accum = 1
while n >= 1:
accum *= n
n -= 1
return accum
voir plus simple ;)
def fact(n):
return reduce(int.__mul__, range(1, n+1))
Après, pour la plupart des algorithmes récursifs non terminaux, et bien tous les langages auront le même problème de stack, sauf les langages/implémentations qui n'utilise pas le C stack et alloue leurs stack sur le tas, ce qui ne fait que repousser le problème plus loin.
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par Frédéric Perrin (site web personnel) . Évalué à 2.
def pgcd(a, b): if a == 0: return b if b == 0: return a if a >= b: return pgcd(a - b, b) else: return pgcd(a, b - a)Je veux bien que ceci puisse être réécrit avec une boucle while, mais l'écriture sera moins naturelle, et la démonstration que tu as vue en cours de maths sur la validité de cet algorithme ne sera plus valable, il faudra refaire un invariant de boucle (c'est d'ailleurs le cas sur la page WP : en:Euclidean_algorithm#Implementations.[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par Barnabé . Évalué à 1.
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par lolop (site web personnel) . Évalué à 2.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par Frédéric Perrin (site web personnel) . Évalué à 2.
http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi(...)
C'est drôle, Guido insiste sur le fait que cela empêche d'avoir une jolie backtrace, alors que cela me semble secondaire. Par contre, il mentionne en passant la gestion des exceptions, ce qui à moi me semble un bien meilleur argument. On ne peut effectivement pas faire de "continuations" si l'on est dans un bloc try, et regarder si on est dans un tel bloc avant de décider si l'on peut optimiser l'appel de la fonction doit être tout de suite moins trivial...
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par Nim . Évalué à 1.
>>> import sys
>>> sys.setrecursionlimit(10000)
>>> fac(999)
402387260077093773543702433923003985719(...)
Sinon oui, le duck typing, on aime ou pas.
Chaque langage a sa philosophie, pour tout ce qui est « défaut » inhérent à celle-ci, on programme en fonction ou on change de langage.
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par gaaaaaAab . Évalué à 2.
Pour pratiquer abondamment le python, je me suis rarement fait piéger par ça. Je ne tape le nom complet d'une variable qu'une seule fois, ensuite, je laisse faire l'auto complétion (qui a le bon goût de préserver mes erreurs typographiques)
ça marche aussi avec les langages de scripts.
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par lolop (site web personnel) . Évalué à 3.
Note que tu es dépendant de la façon dont l'autre process - ainsi que le système - gère les buffers d'entrée/sortie/pipe.
Mais ce genre de problème n'est pas lié à l'existence de subprocess. J'ai un code de 2005 (treetaggerwrapper.py) qui utilise os.popen2, et qui a besoin d'un thread séparé pour pouvoir alimenter un process externe et en même temps récupérer ce qu'il génère.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par Guillaum (site web personnel) . Évalué à 1.
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par lolop (site web personnel) . Évalué à 2.
La doc s'est (nettement) améliorée - elle est mieux structurée qu'avant - mais il y manque encore ce côté participatif/retour d'expérience.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par Guillaum (site web personnel) . Évalué à 1.
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par manatlan (site web personnel) . Évalué à 1.
Dans la grosse majorité des cas, tu trouvais du "code de ce que tu voulais exactement faire avec cet api", et tu copiais/collais.
Certes, il y avait aussi des exemples qu'il ne fallait absolument pas reproduire ;-)
Mais avec un petit système de modération +/- sur les com pertinents ... on aurait certainement le meilleur des 2 mondes.
N'empêche qu'il me semble qu'ils avaient parler justement de faire un système d'annotation en live (tout ajax), lors du passage de l'ancien système à sphinx .. mais apparemment ça n'a pas été retenu ...
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par totof2000 . Évalué à 3.
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par Guillaum (site web personnel) . Évalué à 1.
Et bien ceux avec la meilleur note seront pertinants... Cela marche bien sur slashdot et linuxfr, alors pourquoi pas sur la doc python.
[^] # Circular Reference Warning
Posté par calandoa . Évalué à 2.
# Encapsulation
Posté par barmic . Évalué à 2.
Si je ne me trompe pas ce n'est pas réellement possible d'avoir des donnée membres private/protected. C'est le vrai tur qui me gêne avec le python mais sinon j'aime bien. :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Encapsulation
Posté par benoar . Évalué à 2.
Effectivement. Mais ces qualificatifs n'ont toujours été que des indications pour le programmeur : il y a toujours moyen de le contourner dans le langage. D'où le principe de python d'en faire une indication "visuelle" seulement : quand tu veux faire du "private", tu préfixes ta variable avec deux underscore. Pour du "protected", avec un underscore.
[^] # Re: Encapsulation
Posté par barmic . Évalué à 3.
En C++ j'imagine bien, en D, en Java, en C#, par exemple j'ai déjà plus de mal à imaginer le truc.
De plus il me semble qu'une erreur renvoyée par le compilateur est un peu plus qu'une convention de nommage (pour les cas triviaux je parle pas d'aller faire mumuse avec l'arithmétique des pointeurs ni d'aller bidouiller le code générer par le compilateur).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Encapsulation
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 3.
public class ProofOfConcept {
static class Foo {
private String bar = "private";
@Override
public String toString() {
return "bar = " + bar;
}
}
public static void main(String[] args) {
Foo foo = new Foo();
try {
System.out.println(foo);
Field field = foo.getClass().getDeclaredField("bar");
field.setAccessible(true);
field.set(foo, "public");
System.out.println(foo);
} catch (Exception e) {
e.printStackTrace();
}
}
}
Le résultat donne bien
bar = private
bar = public
Alexandre COLLIGNON
[^] # Re: Encapsulation
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 1.
Alexandre COLLIGNON
[^] # Re: Encapsulation
Posté par Jean B . Évalué à 1.
en python ça donne:
class Date(object):
def __init__(self, day):
self.day = day
@property
def day(self):
return self._day
@day.setter
def day(self, day):
assert 1 <= day <= 31
self._day = day
d = Date(2)
d = Date(42)
Avec un code comme ça pas d'erreur possible. Si quelqu'un modifie _day depuis l'extérieur de la classe et que son code pête il n'a que ce qu'il mérite.
NB j'utilise la syntaxe 2.6 mais il en existe une compatible de 2.2 à 2.6
[^] # Re: Encapsulation
Posté par barmic . Évalué à 2.
Si oui il va falloir le faire pour toutes tes données membres ce qui n'es pas très pratique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Encapsulation
Posté par lolop (site web personnel) . Évalué à 2.
Le côté "on laisse accessible" est dans l'esprit de Python, aucun pythoneur n'ira faire ça pour toutes ses données membres - ou alors c'est un adepte de ADA/Java/C++ qui essaie d'apporter l'esprit de ces langages dans Python - il faut qu'il change d'esprit ou de langage.
Les property, qui permettent de créer des accesseurs pour limiter/contrôler ce qu'on fait avec les variables membres, sont utilisées soit lorsque tu as vraiment besoin de faire des contrôles, soit quand on a du refactoring - pour ne pas casser les utilisations qui feraient des appels directs à une variable.
C'est sûr que Python n'est pas fait pour les personnes qui veulent un typage statique et des contrôles d'accès sur les attributs et méthodes. Chaque langage a ses usages, ses limites... et ses adeptes. Python n'est pas fait pour les "ingénieurs logiciels". Mais ils ont largement le choix d'autres langages.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Encapsulation
Posté par gaaaaaAab . Évalué à 1.
Qu'appelles-tu "ingénieur logiciel" ?
[^] # Re: Encapsulation
Posté par lolop (site web personnel) . Évalué à 2.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Encapsulation
Posté par Jean B . Évalué à 3.
Non je crée une "property", ça permet de définir une fonction qui interceptera les assignations.
> Si oui il va falloir le faire pour toutes tes données membres ce qui n'es pas très pratique.
Oui et non. Personnellement je ne le fait que quand ça a un réel intérêt car j'adhère à la maxime pythonique We're all consenting adults here.
Mais pour un Javaïste c'est équivalent à écrire un couple getter/setter donc bon...
Et puis grâce au coté dynamique de python tu peut écrire des sortes properties générique aka descriptors et tu n'aura plus qu'a déclarer.
Les modèles Django sont basés la dessus.
http://docs.djangoproject.com/en/1.2/topics/db/models/#field(...)
# [HUMOUR] on n'est pas vendredi
Posté par Stibb . Évalué à -1.
Désolé, cette indentation la con me donne des boutons. Python j'ai essayé, j'en ai fait, j'aime le fait que ce soit flexible, mais syntaxiquement, je peux pas. Je vomis après avoir coder, et j'ai la diarrée quand je lit un fichier python.
Donc, une petite pensée pour tous ceux qui comme moi ont développé une alergie au python.
PS: pour vous dire, je préfère encore coder un script en PERL ou en PHP cli plutot que de taper une ligne de code python....
[^] # Re: [HUMOUR] on n'est pas vendredi
Posté par lolop (site web personnel) . Évalué à 3.
[*] Ou autre, ça dépend du fond de la fenêtre d'édition.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: [HUMOUR] on n'est pas vendredi
Posté par GeneralZod . Évalué à 4.
> PS: pour vous dire, je préfère encore coder un script en PERL ou en PHP cli plutot que de taper une ligne de code python....
Toi, t'es le genre à aimer le code pas lisible et imbitable.
[^] # Re: [HUMOUR] on n'est pas vendredi
Posté par Stibb . Évalué à 2.
En python, je n'y arrive pas. C'est moche dès le premier caractère.
[^] # Re: [HUMOUR] on n'est pas vendredi
Posté par GeneralZod . Évalué à 2.
L'important c'est que le code soit lisible, concis et fonctionnel, le choix de l'indentation pour définir les blocs dans Python aide grandement pour les deux premiers points.
[^] # Re: [HUMOUR] on n'est pas vendredi
Posté par Stibb . Évalué à 1.
[^] # Re: [HUMOUR] on n'est pas vendredi
Posté par GeneralZod . Évalué à 4.
En général, le code perl et PHP est nettement plus cryptique que son équivalent Python. AMHA, on peut trouver des contre-exemples mais ça demande beaucoup plus d'efforts.
[^] # Re: [HUMOUR] on n'est pas vendredi
Posté par Stibb . Évalué à -1.
J'aime pas le fait de ne pas avoir d'accolade pour délimiter mes blocs.
J'aime pas le fait de ne pas voir où se termine ma fonction rapidement ou ma classe !
[^] # Re: [HUMOUR] on n'est pas vendredi
Posté par lolop (site web personnel) . Évalué à 3.
Mais quand même, PHP, Perl, Python... ça commence très souvent par un #! du shebang au début du fichier. Donc, si c'est moche dès le premier caractère... y'a un truc.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: [HUMOUR] on n'est pas vendredi
Posté par Alex . Évalué à 4.
[^] # Re: [HUMOUR] on n'est pas vendredi
Posté par lolop (site web personnel) . Évalué à 3.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.