GeneralZod a écrit 2316 commentaires

We intend PEPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Python. The PEP author is responsible for building consensus within the community and documenting dissenting opinions.

C'est exactement la même chose avec Java.
Tu peux proposer une PEP (JSR), elle est débatue par la communauté (JCP) soit elle adoptée soit elle est accepté. Le mainteneur principal GvR (Sun) a le dernier mot, mais tout passe par une PEP pour décrire la spécification. Comme Java, il y a un jeu de tests pour tester la conformité d'une implémentation.
La différence, c'est que Java est contrôlé par des industriels (Sun, IBM, Oracle, BEA etc...) et Python par la communauté Python, c'est quand même plus sympa ?
Mais bizarrement, on se pose la question de savoir si il existe une spécification pour Python et pas pour Java.


> C'est vraiment oser d''appeler cet "ensemble" spécification et comparer avec ce que fait l'ISO l'ECMA ou l'OASIS en matière de spécification.

Le fait que ça ne passe par un organisme de standardisation, ne veut pas dire qu'il n'y a pas de spécifications. Java n'est pas passé par un organisme de normalisation comme l'ISO ou l'ECMA et personne ne hurle pas "java sapusaipanormaliséparliso".


Ce fil est en train de devenir un ramassis de conneries et de trolls sur Python. Faut vraiment être un enculeur de drosophiles pour comparer Python à C, C++ ou Java. Chacun de ses langages a ses domaines de prédilection et rien n'empêche de les utiliser ensemble selon les besoins. Un bon développeur Python n'a jamais craché sur le C et le C++ (ne serait-ce que pour coder une extension), d'ailleurs, le mariage C/Python ou C++/Python (merci Boost) est un bon compromis entre performance et productivité.
On aurait trollé sur Python vs Perl/Ruby, j'aurais à la rigueur compris vu que ces langages jouent dans la même "catégorie".

À croire que les rubyistes et les mongueurs sont plus matures que les fanboys Java ou DotNet.

Tu es de mauvaise foi, lis la PEP n°1.

> Pas standardisé signifie que l'implémentation ne suit pas une spécification.
Faux, Python suit une spécification (Cf ci-dessous)

> un bug est considéré dans la spec car il est dans l'implémentation
Tu es courant qu'il existe un mécanisme normalisé pour gérer l'évolution du langage ? (Les PEP aka Python Enhancement Proposals). Ça marche comme les JSR de Java sauf que c'est un peu plus ouvert, donc si on suit ton raisonnement, si il y a un bug dans l'implémentation Java de Sun, il est considéré comme faisant partie de la spec ?
http://www.python.org/dev/peps/

La FSF a autre chose à foutre que d'autopsier un cadavre mort-né.
Pas de release depuis fin 2007, un désintérêt total de son créateur pour ce qui n'a été qu'un projet factice sensé redorer l'image de Canonical auprès des libristes.

Mark S. qui plusse la fermeture de la m-l
http://osdir.com/ml/gobuntu-devel/2009-01/msg00001.html
Mark S. qui explique pourquoi Gobuntu a été un échec.
http://podcast.ubuntu-uk.org/2008/05/27/s01e06-flaming-star/

> Ah le finally n'existe pas en Java ?
J'ai dis ça où ? nulle part.
J'ai juste dit que je n'ai pas rajouté la gestion de la fermeture de fichier dans le code Java.

> Je croyais que c'était python qui avait un gestion bancale des exceptions jusqu' à la 2.5
Oui, et ? Python 2.5 est sorti en 2006 (avec with en preview).
Sinon, Python 2.6 introduit une gestion des exceptions encore plus élégante avec with.


> ce qui obligeait à imbriquer 2 blocs try pour obtenir la même chose que try..catch..finally.
Pour dans le cas en question, Java t'impose d'imbriquer 2 blocs try (ou de renvoyer une exception), le premier pour gérer l'exception à l'ouverture du fichier, et un second pour fermer le fichier en cas d'erreur de lecture.
Donc mauvais exemple, sinon les constructions try/except/else ou try/finally suffisait pour la plupart des besoins. Je reconnais que quand on avait besoin d'une structure type try/catch/finally, c'était lourdingue d'où l'unification sous Python 2.5.

Même si traiter les exceptions est une bonne chose, Python ne te force pas à le faire, parfois, ça devient très vite lourdingue en Java. Je trouve with est une solution relativement élégante, un peu à la manière de l'idiome RAII en C++ (dont il s'inspire).


Et on pourrait arrêter cette gueguerre Java/Python ? Je ne vois en quoi dire que Python est plus concis que C, C++ ou Java reviendrait à dénigrer ces langages.

hein, à quel endroit, me suis-je montrer agressif ?

> mais si tu rajoutes la gestion des exceptions dans ton code python ca donne quoi
ben, ça donne la même chose, puisque with permet de simplifier la gestion des exceptions.

Si tu veux la même chose avec try/finally:

f = open("data.txt", 'r')
try:
--for line in f:
----print(line)
finally:
--f.close()

ça reste un poil plus court, et dans les 2 cas en Python, mon fichier est fermé en cas d'erreur, ce que je n'ai pas fait en Java.



http://www.python.org/dev/peps/pep-0343/

C'est quand même la FSF qui est à l'origine des concepts de "Free Software" et de "copyleft".
Je pense que l'approbation de la FSF constitue un label éthique de valeur.

Sinon, les critères distinguant une distribution libre selon la FSF ont été formalisé avec la communauté.
Pour la petite histoire, la discussion a été lancée par Fedora (en particulier, Rahul Sundaram, Community Manager pour RedHat). Au final, Fedora n'est pas "libre" selon la définition de la FSF à quelques détails près. Ce n'est pas grave, ça ne remet pas en question l'attachement de Fedora envers le libre et de continuer son lobbying.
Fedora et la FSF divergent sur certains points mais chaque entité a une politique cohérente avec ses idéaux.
Je souhaite à Blag de perservérer et de prouver qu'une distro FSF-compliant n'est pas qu'une branlette intellectuelle mais bel et bien un effort vers un système à la fois libre et fonctionnel !
Et je souhaite qu'il y ait plus de collaboration avec la communauté Fedora dans les deux sens.


http://fedoraproject.org/wiki/FreeSoftwareAnalysis

> Exemple n°2 (...)
C'est probablement plus par manque de place qu'autre chose que l'auteur n'a pas donné plus d'exemple. Par expérience, à moins de faire son ciol, un programme Python est souvent plus concis qu'un programme C, C++ ou Java mais rarement plus verbeux.

> Exemple n°3 (...)
J'ai l'impression que tu confonds C et C++.
Bien sûr que tu peux bricoler des boucles foreach en C (la GLib en fournit pour les tables de hachage par exemple), ou en C++. D'ailleurs, pas la peine de chercher dans Qt, la STL fournit un algorithme for_each, et Boost fournit une construction encore plus sophistiquée.

La différence c'est que la boucle "for x in tartampion" est une construction native du langage.

Un exemple de lecture de fichier lignes par lignes avec gestion d'exception en Java:

try {
BufferedReader br = new BufferedReader(new FileReader("machin.txt"));
while ((line = br.readLine()) != null) {
System.out.println(line);
}
} catch (IOException e) {
}

en python 2.6 (possible en 2.5 en important du futur with_statement) , ça donne;

with open("data.txt", 'r') as f:
for line in f:
print(line)

Python est plus concis et va à l'essentiel, ça n'enlève rien aux qualités du C++, de Qt et de Java mais c'est un fait. Et là ou je rejoins l'auteur de l'article, c'est que pour une initiation à la programmation, c'est nettement plus adapté que C++ ou Java. Les étudiants arrivent à un résultat plus gratifiant dans le même laps de temps ce qui est non négligeable.

Je n'ai pas dit que ZFS remplacerait BtrFS mais que la position de celui-ci serait très probablement remise en question.
BtrFS est très expérimental alors que ZFS est plus ou moins mature, mais comme tu le soulignes, il y aura des questions à se poser (mode de développement, qualité du code etc ...) mais la question sera ouverte.

Dans le cas où Sun déciderait effectivement d'introduire ZFS dans le noyau Linux, il est très probable qu'ils le feront en collaboration avec la communauté contrairement à Hans Reiser qui s'obstinait à ne pas respecter les "règles du jeu".

De plus, ce que l'on oublie de dire, c'est que BtrFS n'est pas seulement un projet communautaire mais surtout la réponse d'Oracle à ZFS. Donc l'accusation de buzz filesystem envers ZFS est tout aussi valable pour BtrFS.
Pour le moment, BtrFS c'est un filesystem encore alpha, avec un format non finalisé, donc si concurrent sérieux se présente, le débat sera réouvert. Et ZFS pourrait être ce concurrent comme pourrait l'être un nouveau venu.

> Fedora ils refusent de packager comme il faut KDE4 parce que c'est complexe de faire des paquets java...

Tu bloubes-là, c'est pas ce qui est dit.
We don’t want the whole Java stack dragged in as a dependency of KDE.
Tu oublies de préciser que le paquet en question ne compile pas sans jars binaires en violation des règles en vigueur sous Fedora. Le billet pose le même problème mais chez Debian.
Et openSUSE et ArchLinux ne sont pas connus pour être des "Free Software nazi" comme dirait Linus.

Quant à tes insinuations saugrenues, je te signalerais qu'une bonne partie des mainteneurs de JPackages sont soit des employés de RedHat soit mainteneurs chez Fedora.


PS: Merci de m'avoir offert le baton pour te battre.

> Détester la Component Architecture, ça revient à détester bon nombre de design patterns super intéressants
Pas d'accord, tu peux parfaitement utiliser les designs patterns cités sans la ZCA.
Après, la ZCA te donne un cadre prédéfini pour les utiliser, un peu comme ce qui existe déjà pour J2EE. Je n'ai rien contre la ZCA en particulier, je ne connais pas donc je ne me permet pas de juger.
De plus, je reconnais que ce n'est pas très rationnel, mais la simple mention "Zope" suffit à freiner mes ardeurs. Ça n'enlève rien au fait que Zope est un bon framework d'entreprise, qu'il a des qualités, mais c'est pas mon truc ni même mon domaine d'activité principale.

D'ailleurs, j'ai pas fini de lire "Expert Python Programming" qui en parle tout à la fin.

> au lieu d'hériter, on adapte. C'est souvent beaucoup plus propre.
+1

J'avoue qu'à la simple lecture du mot "Zope", j'ai directement sauté l'article.
J'ai commencé à le survoler, mais il me faut un peu plus de temps pour le digérer.

J'attends avec impatience les prochains articles !

Ma critique (dans le sens noble du terme):
* Nouveauté de Python 2.6/3: les principaux concepts sont là, c'est bien expliqué avec des exemples clairs. Python 3 étant principalement là pour nettoyer le langage des incohérences accumulés au cours du temps, ne pas s'attendre à des changements radicaux, idem pour Python 2.6 qui est une release de transition.
* Apprenez d'abord Python: comme le présente son auteur, c'est un plaidoyer qui explique pourquoi choisir Python comme langage d'introduction à la programmation. L'annexe donne des conseils pour apprendre et enseigner Python. C'est très bien argumenté, la bibliographie fait une page à elle seule. À faire lire à vos collègues ou à vos enseignants !
l'article que j'ai préféré, même si on prêchait un convaincu. :o)
* Python comme langage scientifique: ce thème justifierait à lui seul un HS dédié, donc ça va à l'essentiel, et présente les principaux paquets et outils. Donc sur certains passages comme ceux sur SciPy et SimPy ça va un peu vite.
Python a un gros potentiel dans ce domaine, il surpasse largement les mastodontes comme Matlab, mais ce dernier a un avantage clé: un nombre impressionnant de toolbox.
* Python et le Réseau: un tutoriel sur l'utilisation des modules réseaux standard puis de Twisted.
Je tire mon chapeau à l'auteur de l'article pour la partie sur Twisted, c'était pas évident de présenter un paquet aussi complexe de façon à ce que ce soit compréhensible par des néophytes.
* Packager et diffuser son application Python: le nom de l'auteur à lui seul est un gage de qualité. L'article ? très pédagogue, on part du plus simple au plus compliqué (distutils, diffusion sur le PyPI). Je ne sais pas si c'est par modestie, mais l'auteur n'a pas cité son dernier opus "Expert Python Programming" qui consacre un chapitre entier à la question.
* Trucs et astuces: un recueil de petites "recettes" et de conseils. C'est destiné à un public de néophyte, mais j'ai bien aimé le paragraphe sur "with".
* Ctypes et Python: ctypes est un module très pratique permettant d'appeler directement du code C en Python. L'écriture d'extensions en C est assez contraignante dans la plupart des langages (semi) interprété, c'est même ce qui m'a fait préféré C# à Java.
C'est une très bonne introduction à ctypes, bon point pour l'auteur, il présente find_library() qui évite pas mal de gruikeries dans le chargement de modules.
* l'article sur Zope: je ne l'ai pas lu et je ne le lirai pas donc je ne dirais rien. Je suis complétement allergique à Zope.

Ma note finale: 9/10 Compte-tenu du nombre de page limité, c'est mérité.

C'est pas ce qui se dit sur la tribune mais bon.
Enfin, on peut toujours en change (hint: bloquer les css spéciales dans vos préférences).

Tu pourrais expliciter ?
oVirt c'est une application web permettant de gérer des machines virtuelles basé sur libvirt. À priori, y a rien à fusionner, de plus ovirt est déjà disponible dans F10.
http://ovirt.org/index.html

> Tu as raison, le son sous Linux avant F8 ou F9 ça marchait pas on était des millions d'utilisateurs à ne pas s'en rendre compte

esound marchotait nuance, il y avait pleins de fois ou ça plantait. C'était clairement en fin de vie, et tout le monde attendait que ça jarte le plus vite possible depuis le début de GNOME 2.
Et quand Fedora a adopté PA, PA offrait toutes les fonctionnalités d'esound (et plus) et même une couche de compatibilité esound.

> yumex avait beaucoup moins de fonctionnalités que packagekit.
L'interface du gestionnaire de paquets par défaut était Pirut et non pas Yumex.
PackageKit est une couche d'abstraction du gestionnaire de paquets, ça permet d'offrir un mécanisme standard aux applications pour télécharger des plugins, ça permet d'offrir plusieurs IHM (Qt, Curses etc ...), un mécanisme standard de notification, ça offre toutes les fonctionnalités présentes dans Pirut, etc ... De plus, Pirut, Yumex était disponibles sur les dépôts donc faux problèmes.

> En plus quand on mettait à jour dbus ce con de gksudo il plantait toujours
Si DBus plante, y a de fortes chances que tout le bureau plante. Hein, GNOME et KDE reposent essentiellement sur lui.
Donc rien à voir avec gksudo ou PolicyKit comme tu le prétends.
Hein, gksudo c'est une grosse merde au niveau de la sécurité, ça donne des droits privilégiés à des millions de lignes de code non vérifiés et non conçu pour ça.

> Enfin l'équipe KDE a dit que Fedora était la seule à avoir bien fait ses devoirs en intégrant KDE 4.0.
url ? Je ne sais pas ce que pense KDE de l'intégration de KDE 4.0 dans Fedora mais ça n'était pas aussi catastrophique qu'Ubuntu bien que perfectible. Ils ont même invité Rex Dieter (ancien membre du board) pour faire une conférence à ce sujet à Akademy.
http://akademy.kde.org/conference/presentation/41.php

Il est encore trop tôt pour l'affirmer.
Ce que Ted T'so dit c'est qu'en l'état actuel, BtrFS est le meilleur candidat en tant que NGFS et qu'il sera inclus dans le tronc. Vu l'avancement de BtrFS, si un projet concurrent se présente, la discussion sera relancée. Si BtrFS est inclus dans le tronc, c'est principalement du au capital confiance dont bénéficie son développeur.
Si demain, Sun décide de relicencier ZFS et de l'intégrer au noyau Linux, la position de BtrFS serait très probablement remise en question.

En 1990, le consensus était que le Hurd serait le kernel majeur de l'environnement GNU. Enfin, je ne souhaite pas que BtrFS connaisse le même sort que le Hurd.

C'est faisable, la question de savoir si c'est faisable à temps pour la version finale.
Les principaux goulots d'étranglements ont été identifiés, du boulot a été fait (nouveau boot graphique: plymouth, nettoyage du code de X11 etc ...).

1. esound ça marchait bien ? gnome-vfs dont le code était tellement pourri que personne n'osait toucher à certaines parties ? gksudo & cie c'est mieux que PolicyKit ? Soit t'es un grand comique, soit tu divagues.
ça c'était de l'urgent, et ils ont dégagés fissa dès que la solution alternative était au moins aussi bonne voire déjà meilleure.

Quand l'existant est "satisfaisant", le changement est fait progressivement, comme c'est le cas de DeviceKit dans F11. HAL seront remplacés progressivement en fonction de l'avancée de DeviceKit et avec un suivi. Et ça se fera en plusieurs releases (F12 et p'tet F13). Hein, David Zeuthen c'est pas le premier rigolo venu.
http://fedoraproject.org/wiki/Features/DeviceKit

2. Super, si personne ne l'utilise, si personne ne fait d'efforts pour l'intégrer, à ce rythme-là, les développeurs auraient abandonné PA et on serait resté avec cette merde d'esound. Ou alors, les développeurs n'auraient eu qu'à sortir une version 1.0 toute pourrie pour que les distributions se décident à l'inclure. Tout version 0.9.x que PA soit, elle était et est nettement meilleure que l'existant. PA avait déjà quelques années de développement dans les pattes quand Fedora l'a intégré.
Et ça fonctionnait out-of-the-box, les mainteneurs avaient même fait le boulot de porter les applications utilisant esound vers PA (y compris le vénérable xmms) les quelques problèmes venaient d'applications propriétaires comme Skype.
Évidemment, la mauvaise réputation de PA vient du fait que certaines distributions n'ont pas fait leur boulot correctement, voici la réponse de Lennart Poettering mainteneur de PA:
Some distributions did a better job adopting PulseAudio than others. On the good side I certainly have to list Mandriva, Debian, and Fedora. OTOH Ubuntu didn't exactly do a stellar job. They didn't do their homework.
http://0pointer.de/blog/projects/jeffrey-stedfast.html

Je suis d'accord sur le fait que c'est (beaucoup) s'avancer sur Btrfs que de le présenter comme le prochaun FS majeur sous GNU/Linux.
Une chose est sûre, c'est qu'ext4 est et sera la dernière itération de la famille ext et que son successeur sera techniquement très différent.

Ciol fait du ciol (en clair, il FUD).
Fedora n'a jamais intégré une nouvelle fonctionnalité dans la version finale comme ça.
Tout passe dans rawhide, les contributeurs sont fortement encouragés à s'impliquer en upstream, et il y a un suivi. Si une fonctionnalité n'est pas jugée suffisamment stable, soit elle est repoussée, soit on désactive ce qui pose problème, et si il ya perte de fonctionnalité, on offre une solution de repli.
Et si nécessaire, Fedora n'a jamais reculé devant le fait de retarder de quelques semaines voire mois une release.

1. (Fedora == stable) is True
Une nouvelle fonctionnalité est intégré à Fedora si elle respecte ces 3 conditions:
a) Offrir une solution technique meilleure que l'existante. (ex: PulseAudio vs esound)
b) Si il n'y a pas perte de fonctionnalités et sinon être capable d'offrir une solution de repli
(ex: Xen remplaçable par KVM + xenner)
c) Si au moment de la version finale, la fonctionnalité est jugée suffisamment stable pour être incluse. Sinon, elle est repoussée à plus tard (ex GCC 4.2 qui sera remplacé par GCC 4.1 + backports, puis GCC 4.3), ou bien les fonctionnalités instables sont désactivés (ex: Xserver 1.5 dans Fedora 9).
Au final, c'est une distribution pas plus instable qu'une autre, relativement avancée et agréable à l'utilisation. Certes, Fedora étant destiné à un public libriste, la compatibilité avec le logiciel propriétaire et les pilotes propriétaires n'est pas une priorité. Ça ne veut pas dire que Fedora cherche volontairement à casser la compatibilité mais que ça ne doit pas freiner le logiciel libre.

2. Oui mais ...
Mis à part le passage Fedora 6 -> 7 qui a été assez périlleux sur certaines machines, ça marche plutôt bien. La mise à jour via yum est possible (et ça fonctionne d'après ceux qui l'ont testé) mais non supporté (certains changements notamment au niveau du filesystem sont prises en charge par Anaconda). Jusqu'à Fedora 8, seule la mise à jour via Anaconda était officiellement supportée. Depuis, un outil nommé Preupgrade permet de mettre à jour automatiquement sa machine, tu le lances, il télécharge les paquets et met à jour la distribution au prochain redémarrage via Grub.
La machine sur laquelle je suis actuellement a connu successivement Fedora 8 - 9 - 10 sans aucune réinstallation avec des passages sur rawhide. De même pour le MacBook qui est passé de FC6 à rawhide (F11). J'ai rencontré un unique souci, c'était le résolveur de dépendance qui bloquait sur un paquet tiers, j'ai juste eu à le supprimer et à relancer le processus de mise à jour.
Fedora est bien meilleure sur ce point-là que bon nombre d'autres distributions, certes, Debian et RHEL sont encore indétronables sur ce point.

Linus est un utilisateur exigeant, quand il ne trouve pas un outil adapté, il l'écrit lui-même !
Pas d'OS sympa sur son 386 ===> j'écris mon propre kernel "Linux" aka "Linus' Unix"
Pas de VCS à la hauteur ===> J'écris mon propre DVCS "Git" (en bon Français "connard")
Pas de bureau à mon gout ===> La suite est logique ... Quant au nom, Linus a déjà donné la règle I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git..

On doit se préparer à voir très prochainement un "Sod Desktop Environment" (ce qui donne dans la langue de Molière "Environnement de Bureau de l'Enculé").

> c'est quoi le probleme avec le message ubuntu?
Je parlais _des_ messages qui s'affichent dans les boites de dialogues dont le texte prêtent à rire et ne fait pas du tout professionnel ainsi que des traductions pourries soumises via Rosetta.
Pour avoir fait de la traduction, c'est loin d'être trivial.

> Installe des paquets non authentifies, c'est pas tres malin, c'est un fait.
Hein, de quoi tu parles ?

> Quand un joli malware se rependra (automatiquement qui plus est) sur 80% des machines ubuntu a travers un repo non officiel d'ubuntu.
Tu t'es pas trompé de file ?