Posté par golum () le 15/12/2006 à 23:17. (lien). Évalué à 2.

Relis mon exemple,c'est bien appelé depuis l'extérieur mais refusera de compiler avec un tableau d'Object en paramètres. Il devra donc le transformer en tableau de int et aura donc anticipé le pb.

Avec du python tu construis ta liste sans faire au fait qu'elle peut contenir des chaînes. Quand ca pète en prod tu cherches dans l'urgence et merde j'ai oublié de transformer les objets de ma liste en en entiers avant l'appel.

[ Répondre ]

Posté par golum () le 15/12/2006 à 23:02. (lien). Évalué à 2.

Mais le typage statique étant statique, ta fonction "sum" qui additionne des entiers est impropre à l'addition d'autres choses que des entiers (par exemple, des réels ou des complexes). Il n'est pas sans contrepartie.

sauf si tu créer un interface qui répond à ton comportement (dans ton ca être sommable) ou que tu utilises des type paramétrés (templates).En outre on a une approche descendante, on modélise son système au niveau structurel (classe, intefaces).
C'est vrai que C++ permet la surcharge des opérateurs à la différence de Java. Ca a ses avantages mais c'est complexe à mettre en oeuvre.

En pratique on ne récrit jamais de code Python en C, sauf parfois quelques bouts très critiques.

En pratique on modélise son application et on génère le squelette décode à partir de ça et on le complète.
Je citais ca à titre d'exemple pour montre que l'approche était possible avec Java. Groovy étant plus proche de Java que jython ou jRuby.

Bon j'me marrais bien avec vous mais là j'vais m'pieuter

[ Répondre ]

Posté par golum () le 15/12/2006 à 22:49. (lien). Évalué à 2.

Oui, mais si tu ajoutes un cast depuis Object, tu reviens aux effets que tu critiques, à savoir : possibilité d'exception à l'exécution.

Non puisque tu dois transformer ta chaîne "2" en int avant de la passer à ta liste en paramètre. Dons c'est à la compil que tu détecte le pb.

Ben non, tu ne dois pas te coltiner l'arbre de dépendances, puisque l'effet souhaité pour la plupart des exceptions est d'arrêter totalement le
...

C'est tout le contraire.
Le but du jeu c'est justement que chaque bloc appelant intercepte l'exception à son niveau pour libérer des ressources qu'il a ouvert( fichier ouvert, connection à une db,..) et relance aux niveau supérieur.
En plus si tu ne l'intercepte pas à un moment donne tu sors du programme. Donc il faut bien faire le tri entre les exceptions qui te permettre de retrouver un état stable et celles qui sont irrécupérables.

[ Répondre ]

Posté par golum () le 15/12/2006 à 22:35. (lien). Évalué à 2.

Oui, comme beaucoup de RFCs de l'IETF...

Je ne savais pas que python était une norme.Mes compliments

Ce qui ne l'empêche pas WSGI d'être de plus en plus implémenté :

Si j'ai bien compris, il y a autant d'implémentations que de framework..
javax.serlvet dispose d'une implémentation standard.
Vivement que wsgi fasse parie intégrante de la standard library :)

Bon c'est pas mal, il reste encore un peu de travail pour obtenir une spec aussi complète que JEE (EJB, RMI, ....)

[ Répondre ]

Posté par golum () le 15/12/2006 à 22:21. (lien). Évalué à 2.

En python on a pas besoin du do while

C'est une absence mineure, comme celle du switch case.
Je préfère cela à une absence majeure comme celle des fonctions escomme objets à part entière.

Ce que je voulais signaler c'est qu'il vaut mieux utiliser des conventions explicites en enrichissant la syntaxe lorsque c'est nécessaire plutôt que de faire confiance à des idiomes du langage qui sont sujets aux défaillances humaines.

un programmeur inexpérimenté qui veut implémenter le do while sera tenté de mettre en place un truc du genre:

bloc_code1
while(cond):
... bloc_code1

au lieu de la construction montrée plus while 1:.
Il augmentera les chances d'erreur puisqu'il devra resynchroniser bloc_code1 dans les 2 références alors qu'il peut en fait n'en utiliser qu'une seule avec la construction while 1:

Note que vouloir opposer Java à Python pour la concision du code est perdu d'avance de toute façon.

Je ne cherche pas à démontrer que Java ou un langage typé statique est plus concis qu'un langage dynamique. Je montre simplement que le gain de productivité pour le prototypage et le dev est perdu en maintenance puisque le code produit par les premiers est de meilleure qualité et que le client s'expose à moins de déconvenues (cf. mon post plus bas) http://linuxfr.org/comments/785080.html#785080

Oui rejetons tout ce qui pemet d'apporter de la qualité aux developpement: les contrats, le typage fort, les GC.

Python a le typage fort et le GC.

Je voulais dire typage statique.
Pourquoi se passer d'une précaution supplémentaire. Le GC en est une autre et il servait d'exemple.

Il lui manque certes les "contrats" (mais Java les a-t-il ? hmmm ?).

Note qu'avec un peu d'imagination, tu pourrais faire une bibliothèque de contrats pour Python avec des décorateurs de fonctions. Je crois même que ça existe, mais j'ai la flemme de vérifier.

Les 2 l'implémentent avec des libs ou au travers des annotations.

Mais encore une fois, l'utilité d'une méthode se spécifie par la documentation, pas en ajoutant des mots-clés à qui mieux-mieux pour contrôler les accès.
...
- soit ta méthode est destinée aux classes dérivées, et tu l'expliques dans la documentation (vu que de toute façon, il faut bien documenter tout ce qui est non-privé, n'est-ce pas ?)

Oui et tu fais quoi si la lib que tu utilises n'emploie pas les mêmes conventions de documentation que toi ou que le dev n'a pas documenté tous les aspects. Il vaut mieux se palucher une fonction de doc de 15 lignes pour découvrir dedans que les attributs sont protégés plutôt que le langage te l'explicite. Je préfère faire confiance à la machine plutôt que m'en remettre à l'humain et à son inconstance. Rajoutes à ca qu'il faut documenter les exceptions que tu peux lever, les types de paramètres attendus si tu fais des traitements particuliers (ex de la somme des éléments d'une liste d'entiers). Tu peux aussi rajouter des assert qui ne sont vérifiés qu'à l'exécution et ne te protègent tjs pas des cas non prévus. Autant faire confiance au typage statique.

Mmmh ?
Java a bien été conçu dans l'optique où le programmeur fait beaucoup de bêtises et où il faut une tonne de mécanismes ....nformaticiens" à la chaîne dans l'optique de baisser les coûts.

On peut aussi dire que Java permet d'entreprendre des projets de plus grande envergure puisque les sources d'erreurs humaines qui ne sont as toujours dues à l'incompétence que tu insinues sont évitées.
Les développeurs du projet communautaire Apache sont-ils des victimes de ce taylorisme d'entreprises ?

Ca n'a pas forcément à voir avec la compétence des développeurs. Le même développeur devra être encore plus vigilant avec son code Python et perdra tout le temps gagné au prototypage à verrouiller son code. Ce point ne peut-être amélioré pour une langage dynamique alors que le codeur Java peut se reposer sur son IDE pour gagner en productivité.
En plus le monde Java dispose maintenant d'un langage dynamique avec une syntaxe à la Java et basé sur l'API Java Groovy. La boucle prototypage en langage dynamique et réécriture en langage statique a des fins d'optimisations ou de qualité est plus simple avec le couple Groovy/Java que le couple Python/C.

[ Répondre ]

Posté par golum () le 15/12/2006 à 20:56. (lien). Évalué à 2.

Merci de me raffraichir la mémoire.
La fac, ca remonte à quelques années pour moi.

[ Répondre ]

Posté par golum () le 15/12/2006 à 20:55. (lien). Évalué à 3.

Evidemment, tu me sors unr erreur qui ne peut être détectée qu'à l'exécution.
Je n'ai jamais prétendu qu'on pouvait se passer des tests unitaires avec les langages à typage statique et c'est pas pour rien qu'il existe jUnit en Java.
Le typage statique apporte simplement un niveau de sécurité supplémentaire.

Maintenant observe le code suivant:

l=range(35)
>>> def sum(l):
... j=0
... for i in l:
... j=j+i
... return j
...
>>> a=sum(l)
>>> sum(range(35))
595

Imagines que la fonction sum soit placée dans un module m1, qu'un développeur utilise cette fonction dans son propre module m2 et l'inclue dans une fonction plus spécifique qui accepte encore "l" en paramètre.Imagines que cette fonction soit mal documentée (l'erreur est humaine et la paresse encore plus), ou encore que celui qui utilise m2 implémente un algorithme complexe pour construire la liste en paramètre à la fonction de m2.
Du coup la liste passée en paramètre en prod est.
l=[1,"2",3]
(Les test d'intégrations ne pouvant être jamais être exhaustifs en raison de la combinatoire)
Résultat des courses en prod

Traceback (most recent call last):
File "", line 1, in ?
File "", line 4, in sum
TypeError: unsupported operand type(s) for +: 'int' and 'str'

Avec un langage typé statiquement, tu as déclaré un type tableau d'entiers en paramètre des fonctions et l'algorithme de l'utilisateur devra accepter des int ou ne compilera pas(éventuellement après un cast s'il manipule des Object ou d'autres types).

Et là on parle des types de base, mais on a le même type de contrôles avec des classes ou des interfaces alors que le duck typing ne vérifiera rien et te lanceras des exceptions tout pareil.

Imagines que tu aies affaire à des dizaines de composants avec de nombreuses dépendances et tu augmentes la probabilité de ce genre d'erreur, surtout si tu intègres des modules externes que ton équipe n'a pas développé. Là où la documentation fait foi et où on se base sur des conventions implicites qui sont sujettes à négligence ou oubli, le typage explicite et uniforme montre sa supériorité.

Avec Java, les exceptions sont également vérifiées à la compilation et sont explicitées alors qu'avec un langage typé dynamiquement tu dois te coltiner tout l'arbre de dépendance pour vérifier dans la doc ou dans le code toutes les exceptions qui sont susceptibles d'être levées.

[ Répondre ]

Posté par golum () le 15/12/2006 à 12:04. (lien). Évalué à 3.

Oui en fait les 2 sont complémentaires.

Les SSII poussent à l'infogérance et à l'outsourcing pour récupérer des marchés et les DSI les mettent en concurrence pour baisser les coûts.

Mais bon c'est quand même bien le Syntec qui faisait du lobbying pour le contrat de projet afin d'avoir des esclaves jetables à volonté qui se retrouvent à la charge du contribuable en inter-projet.
On ne parlera pas des SSII qui font leur business avec l'offshore et autre nearshore.
Faut dire que la directive Bolkenstein qui est maintenant passée n'a pas tenu toutes ses promesses sur le principe d'origine donc ca les embêtent un peu de payer leurs untermenschen au tarif local.

[ Répondre ]

Posté par golum () le 15/12/2006 à 09:08. (lien). Évalué à 2.

Ah oui et PEP 333
http://www.python.org/dev/peps/pep-0333/
"Status = Draft"
:D

[ Répondre ]

Posté par golum () le 15/12/2006 à 09:05. (lien). Évalué à 3.

Parce que le typage statique permet aux programmes de se "déverminer" sans intervention humaine peut-être ? Voilà une nouvelle inattendue.

Si mais tu ne le découvres pas à l'execution en prod

Oui, en même temps le fait que ce soit possible est plutôt une qualité du langage. Python évite l'inflation de mots-clés en fournissant un langage souple qui permet aux programmeurs de réaliser les abstractions dont ils ont besoin sans que ça ait l'air affreux.

Tout a fait la logique se décrit avec 2 propositions. (non p et p=>q si mes souvenirs sont exacts)
On a juste créé 3 autres fonctions loqiques (et, ou et ou exclusif) pour faire affreux et pas pour du tout pour simplifier l'ecriture des propositions.
en python on a pas besoin du do while
while 1:
...
if(cond):
break
est beaucoup plus "joli"

Elégant, le mot-clé "virtual" dans la spécification des classes de base ? :-O

pas élegant peut-être pas mais cohérent sûrement.

L'ordre de résolution est : D, B, C, A, object. Profondeur d'abord ??

http://docs.python.org/tut/node11.html#SECTION00115100000000(...)
"This is depth-first, left-to-right"
Faudra qu'ils remettent à jour leur doc alors

C'est quoi le problème à résoudre ?
Si tu veux déclarer qu'un attribut est à usage interne, tu n'as qu'à le préfixer d'un underscore, c'est une convention suffisamment explicite pour indiquer à l'utilisateur de ta classe qu'il ne faut pas toucher à cet attribut-là.
Si l'utilisateur en question est assez téméraire pour passer outre, c'est son problème.

Le problème a résoudre est que je cherche le mot clé protected et non private.

La philosophie de Python n'est pas de prendre les développeurs pour des enfants et de mettre des barrières partout (contrairement à Java qui favorise le contexte social d'une informatique réalisée par une armée de tâcherons sous-payés et incompétents) ; c'est un langage pour adultes consentants. A chacun d'être à la hauteur.

Oui rejetons tout ce qui pemet d'apporter de la qualité aux developpement: les contrats, le typage fort, les GC.
Tu devrais peut-être te remettre au C

Sinon va faire un tour sur les annonces d'emploi des devs Java et tu verras comme ils sont sous-payés.
Ca c'est de l'argumentaire.
Je ne relèverai même pas sur l'incompétence.

[ Répondre ]

Posté par golum () le 14/12/2006 à 14:44. (lien). Évalué à 2.

Bon je vais les aider un peu.

Python founit un module de refactoring pas trop mal fait qui peut être intégré dans pas mal d'IDE
http://bicyclerepair.sourceforge.net/

D'ailleur un IDE assez sympatoche le propose (pyQT)
http://www.die-offenbachs.de/detlev/eric.html

[ Répondre ]

Posté par golum () le 14/12/2006 à 14:13. (lien). Évalué à 4.

Kiss MOUAHAHAHA.

J'avais acheté un beau kiss avec une carte ethernet, il y a 5 ans de ça.
On m'avait dit à l'époque que c'était une super marque parce qu'il sortaient des firmwares régulièrement et qu'ils étaient européens, la qualité toussa.

Ca fait 5 ans que j'attend les mises à jour pour pouvoir lire mes Xvid. Il y a bien des nouveaux firmware une fois par an mais c'est juste des maj du GUI sous Windows ou de l'interface de connexions aux Webradios.
Je ne te parle pas des DVDs qui freezent.

Du coup je l'ai refilé à mes mômes et j'ai racheté un bon lecteur DVD au supermarché du coin qui me lit tout au ptit poil.

[ Répondre ]

Posté par golum () le 14/12/2006 à 13:52. (lien). Évalué à 1.

Disons que le prosélytisme des pythonneux dans les news java me lasse un peu.

Et pourtant je ne suis pas le dernier à utiliser ce langage à l'occasion.
Ces faiblesses que je pointe, expriment ma frustation de ne pas voir ces aspects progresser dans les versions de Python qui se succèdent. La plupart de ces griefs ont reçu des propositions d'amélioration dans les PSP et ont été rejetée ou retardées. On assiste du coup à un éclatement de la communauté que je trouve dommageable. (fork de python http://boo.codehaus.org/, librairies complémentaires d'usage générales, ...)

[ Répondre ]

Posté par golum () le 14/12/2006 à 13:15. (lien). Évalué à 3.

Oui et surtout python est un vrai langage objet.

Il ne supporte pas l'héritage d'interface et nous vend son duck typing.
Un principe révolutionnaire lorsque tu dois faire de l'intégration de composants, surtout couplé avec son typage dynamique. Lorsque tu assembles des modules que tu n'avais pas conçu initialement pour ca et que tu découvres en prod que tu passes pas dans un cas non prévu (les test d'intégration etant plus difficiles à mettre en place que les test unitaires) alors que la compilation te l'aurait indiqué dès la phase de dev. La sécurité en devient imparable.

Grâce à ce même typage dynamique, tu en es réduit à utiliser les tests unitaires pour déverminer tes programmes alors que le contrôle de type à la compilation te permet de gagner un temps fou. 2 précautions ne valent mieux qu'une.
Quel développeur qui adopte une programmation defensive n'en est pas réduit à poser des
assert sur le type de la classe attendu.
Du coup certains ont implémenté les interfaces dans des libs non standard.

Tu n'as pas d'attributs ou de méthodes protégées.

Tu déclares tes attributs privés en les déclarant avec __ et tu peux casser aisément l'encapsulation par programme.

Comble de l'élegance, tu dois passer le paramètre self à toute tes déclarations de méthodes.

Tu dois te coltiner des idiomes du langage pour implémenter des structures de contrôles aussi basiques qu'un do while.

Tu peux faire de l'introspection sur tes objets en explorant le dictionnaire qui lui est associé, même si on te le déconseille parce que ca peut changer. Preuve que son modèle objet est figé.

Son héritage multiple est bancal (en profondeur d'abord de gauche à droite) puisqu'il ne résoud pas le pb de l'héritage en diamant de façon élégante comme le C++ (ou en l'évitant grâce à l'héritage d'implémentation simple couplé avec l'héritage d'interface et la délégation comme en Java)


Tu n'as pas RMI en standard
pas de libs standard équivalente aux servlets, aucune spécification commune, ce qui t'oblige à choisir parmi une pléthore de frameworks dont aucun n'arrive à s'imposer.


.....

[ Répondre ]

Posté par golum () le 14/12/2006 à 09:55. (lien). Évalué à 2.

s/la version de python qui disaient/la version de python la plus rapide de l'ouest qui disaient/
s="la version de python qui disaient"
s=s[0:20]+"la plus rapide de l'ouest"+s[20:]

[ Répondre ]

Posté par golum () le 14/12/2006 à 09:43. (lien). Évalué à 4.

for i in xrange(100):
... print i+1, r"Tu ne diras plus de bétises sur python le langage qui roxor sa mère"

[ Répondre ]

Posté par golum () le 14/12/2006 à 09:38. (lien). Évalué à 2.

Deconnes pas! y'a ironpython (laversion de python qui disaient) et boo qui tourne dessus.
Au moins sur une bonne JVM, ils peuvent défouler avec du jython comme au bon vieux temps ou y avait pas encore les itérateurs et que qu'on avait le choix entre try except et try finally dans le même bloc.

Bon allez! Promis, je recommencerai plus ==> []

[ Répondre ]

Posté par golum () le 14/12/2006 à 09:11. (lien). Évalué à 2.

Tu as parfaitement raison mais SOULfly_B parlait d'un usage amateur. Je pense que ca ne le dérange pas que la logique applicative soit déportée complétement sur le navigateur. L'important dans ce cas est de pouvoir developper son site en Java est de pouvoir le bazarder sur son site perso après la compilation vers Javascript avec juste son MySQL d'activé. Mais ca doit avoir rapidement ses limites.
C'est l'avantage de GWT par rapport à echo2, la logique applicative peut être placée entièrement coté client ou répartie entre le client et serveur alors que Echo2 impose de la répartir des 2 cotés. La contrepartie à cette souplesse c'est peut-être qu'avec l'approche echo2 tu as une partie du travail de répartition de la charge qui est déjà faite de façon optimisée alors que tu dois sûrement faire tout ça à la mano dans le cas de GWT. Ca reste à vérifier.

[ Répondre ]

Posté par golum () le 13/12/2006 à 22:56. (lien). Évalué à 3.

Bon les filles, passe encore que vous fassiez de la pub a peine déguisée pour votre chouchou (que j'apprécie par ailleurs) en vous raccrochant aux branches mais si vous alliez jouer ailleurs. C'est pas ce qui manque les news et les journaux python

Ils adoptent la même licence que l'équivalent libre de GWT en python !
http://pyjamas.pyworks.org/FR/

; ) ;) ;) ;) ;)
C'est plus un clin d'oeil c'est une paralysie faciale

Pour un peu on parierait que vous êtes sous Ubuntu.

Entre le thread python et le troll web2.0 on a du mal à se rendre compte qu'on est sur une dépêche GWT Java

Aux moinsseurs : Chargez, Feu !
J'me sens d'humeur suicidaire ce soir.

[ Répondre ]