flan a écrit 1830 commentaires

Django permet depuis très longtemps d'intégrer ses propres moteurs (autrement dit un adaptateur à une base de données) à l'ORM de base, et tu peux depuis longtemps faire du LDAP ou du MongoDB.

À côté de ça, tu peux maintenant (mais c'est récent, Django 1.8 ou 1.9) changer d'ORM et utiliser un autre (par exemple SQLAlchemy). De façon générale, Django est maintenant beaucoup plus modulaire : tu peux changer son moteur de template (pour du Jinja2, au hasard) et son ORM.

En quoi sa parole serait-elle d'évangile ? il précise justement qu'il ne parle que de ses besoins personnels, et que sa situation n'est pas forcément transposable.
Si tu préfères Linux, bah grand bien t'en fasse. Que pourrait-il dire d'autre ? Il n'a jamais sous-entendu qu'OS X te serait bien mieux adapté.

En revanche, OS X n'est pas un dérivé UNIX bâtard. OS X EST un UNIX de plein droit, il est d'ailleurs certifié UNIX (contrairement à Linux ;) ).

Après, je ne comprends absolument pas ton passage sur son acceptation sociale et son statut de jouet (tous les professionnels, quels qu'ils soient, qui utilisent OS X au quotidien seront ravis d'apprendre qu'ils ne font que jouer ; heureusement que tu es là pour leur apprendre :) ).

En fait, le X correspondrait aux deux, à la fois une référence à UNIX et au « 10 » romain. D'après ce que j'ai lu (mais je ne garantis pas l'info), Mac OS 9 a été sorti uniquement pour passer à X/10 (il n'apporterait que peu de chose par rapport à Mac OS 8, il aurait très bien être une version mineure).

Ensuite, Mac OS X a été renommé en OS X (il y a 3 ou 4 ans, de mémoire), et maintenant OS X est renommé en macOS (sans majuscule).

Oui, c'est d'ailleurs pour ça que j'ai mis « x is None » ; cependant il n'est possible que parce qu'il n'y a qu'une seule instance de None.

La méthode recommandée est :
```

class Test:
… def init(self, items=None):
… self.items = [] if items is None else items
…

… def add(self, item):
… self.items.append(item)
```
None est un objet dont il existe une unique instance (comme False ou True), on peut donc indifféremment utiliser « x is None » et « x == None ».

Malheureusement, l'inférence de type n'est pas parfaite, surtout avec les bibliothèques tierce-partie qui n'aident pas toujours beaucoup (voire rarement) à ce sujet :(

Ça serait pas mal de n'avoir que les erreurs de type, mais il y a tant d'autres raisons… l'algo peut être faux, on peut oublier de vérifier certaines conditions, les cas limites (j'essaie d'utiliser hypothesis pour ça), mauvaise gestion des exceptions, …

Bon, globalement j'ai quand même bien plus de chances que ça fonctionne dès le premier lancement que l'inverse depuis que je fais les choses proprement (PyCharm + indications de type + tests + hypothesis + intégration continue).

Avant même la compilation : dès l'écriture du code. Pourquoi compiler du code alors que la compilation échouera forcément ?

Quand je code en Python, j'utilise PyCharm qui fait de l'inférence de type assez efficace (d'autant plus que je l'aide pas mal à ce sujet) et me force à respecter la PEP008. C'est maintenant rarissime que j'obtienne des erreurs de type au lancement.

En prenant un cas caricatural et en oubliant tous les autres avantages (lib standard, écosystème, absence de compilation, …), ça ne change pas grand-chose, forcément.

Merci pour ton retour. J'ai un peu l'impression que tu en parles au passé, a-t-il été abandonné, ou est-ce bien un changement de poste de ta part ?

Au final, avec Kerberos, cela fonctionnait-il bien ? Comment était possible la transmission du ticket Kerberos au smtp derrière SoGO ? Pas d'authent' en local sur le port 25 ?

Tu as trois possibilités pour les paquets Python :

• avec le système de packaging de ta distrib (apt-get install python-numpy)
• depuis le dépôt avec les sources et la recompilation qui va avec
• depuis le dépôt avec des versions précompilées (avec plusieurs choix d'archi)

par exemple : https://pypi.python.org/pypi/numpy/1.9.3

Et ces langages font souvent appel à du C pour les fonctions consommatrices de ressources. Après, je suis très content d'utiliser ces langages, il ne faut juste pas se voiler la face.

D'ailleurs, on peut faire du calcul matriciel en Python qui soit aussi performant que le code C équivalent. Ça n'a absolument rien de magique, car les bibliothèques bien écrites (comme numpy) sont codées en C, et le code Python (qui est la seule chose que le développeur voit, et qui sera facile à écrire et concis) ne sert que de ciment au code qui calcul. Du coup, on se moque que le code Python ne soit pas très performant, vu qu'on n'y passe qu'un pouillème du temps de calcul.

Ok, merci encore pour toutes ces réponses.

pour les catégories ou les flux publics, je pensais à la possibilité de mettre des flux ou des groupes de flux visibles d'autres personnes, avec une page proposant ces groupes déjà prêts à être ajoutés dans une sélection perso.

Merci pour tes réponses. Je n'ai pas encore eu le temps de m'y plonger sérieusement, mais je note pour plus tard, dans ma liste de choses à installer ^ ^

Peut-on l'utiliser en reverse proxy, plus simplement ?

Y a-t-il moyen de compiler facilement et de l'exporter sous forme de .deb ?
De plus, si je comprends bien, la conf' est écrite dans un fichier .py au milieu du code. Serait-il envisageable de l'exporter dans un .ini ?

Que se passe-t-il pour la mise à jour de la base de données si tu changes le modèle ? Je suis habitué au système de migrations de Django, mais je ne connais pas du tout Flask.

Encore une question : peut-on partager ou rendre publiques des catégories ? Je n'ai pas vu de telle option en me logguant rapidement.

Je suis également franchement intéressé. Ça me paraît pas mal du tout ! Je n'ai pas eu le temps de tester, mais je le mets sur ma liste de choses à installer.

Par pur plaisir d'être pénible, j'aurais quelques remarques, uniquement basées sur la doc et liées à mes petites manies :

• pour moi, un projet Python devrait s'installer via pip (quitte à avoir une commande pour créer la doc), ou via des paquets (type .deb ou .rpm), le tout associé à un fichier de conf' : c'est toujours plus agréable d'avoir une seule méthode pour installer tous les projets, et de pouvoir les installer sans accès internet. C'est en tout cas ainsi que je raisonne pour mes projets perso (basés sur Django), mais j'ai l'impression que ce n'est pas le cas ici.
• y a-t-il moyen d'utiliser le REMOTE_USER (ou HTTP_REMOTE_USER) pour authentifier l'utilisateur ? j'aime bien avoir mes utilisateurs authentifiés via Kerberos.

C'est un bête Mac Mini. Quant à la consommation, je ne l'ai pas fait directement, mais d'autres que moi l'ont mesurée.

J'espère qu'un portable fait largement moins de 20 W au repos, vu que mon ordi fixe fait dans les 10 W, avec un Intel Core 2 Duo + 8Go de RAM et un SSD (et il fonctionne 24H/24 depuis 2009).

tu as raison, j'aurais pu préciser que Darwin en soi n'avait strictement aucun intérêt :)

OS X n'est pas une distrib BSD, ce n'est d'ailleurs même pas un noyau BSD. Autour du noyau XNU/Mach se trouvent pas mal d'outils d'origine BSD (la gestion des drivers, au moins au début vu que je ne sais pas si c'est toujours le cas), mais le noyau n'est pas le même.

En (très) gros, tu as l'empilement
OS X = (Cocoa|Quartz|..) + Darwin
Darwin = outils maison + outils BSD + XNU/Mach
Darwin est complètement open-source et est un OS complet que tu peux installer (mais sans interface graphique intéressante)

Pour avoir assisté à quelques congrès d'info (parfois très théorique, parfois très appliquée), j'ai vu beaucoup de Mac (voire une écrasante majorité) et beaucoup d'écrans affichaient un terminal sous une forme quelconque.
De mon côté, si je n'avais pas de terminal, l'option "Mac" ne serait même pas envisageable.

Plutôt GNU/Windows, non ?

Oui, c'est sûr que find est vraiment l'argument clef qui va faire basculer les gens d'OS X à Windows :)

(sinon, je ne m'étais jamais rendu compte qu'installer une autre version de Python était plus compliquée que de télécharger le .dmg et de cliquer quelques fois sur OK).

Logiquement tu ne t'intéresse qu'à tes dépendances direct et si tu utilise ces dépendances c'est que tu pense qu'elles sont assez malines pour faire de même. C'est l'unique façon de faire si tu ne veux pas forker tes dépendances pour jouer à mettre à jour une dépendance de ta dépendance directe.

Il faut donc analyser la qualité de chaque dépendance. Ça prend du temps, surtout quand on voit les absurdités montrées plus haut (franchement, qui penserait que vérifier qu'un objet est un entier positif demande 3 dépendances ?!?). Faire ce travail pour quelques projets ne me pose pas de problème particulier, le faire pour plusieurs centaines m'en pose beaucoup plus.

A moins que tu utilises d'une manière que je ne connais pas bien, tu ne gère jamais toutes ces dépendances. Tu vas par exemple avoir une dépendance à babel qui lui utilise d'autres dépendances. Chacun s'occupant de ses dépendances. Jamais tu n'as à gérer l'ensemble de ton graph de dépendance.

Oui, c'est la théorie. Ça implique de faire confiance à toutes tes dépendances. On peut trouver du bon et du moins bon dans tous les langages ; mais encore une fois plus tu as de dépendances différentes, plus tu as de chances de retrouver avec une dépendance foireuse dont une sous-dépendance te posera problème.
C'est beaucoup plus facile de faire confiance à 3-4 personnes qu'à 300 ou 400. À nouveau, le problème n'est pas qualitatif mais quantitatif.

C'est une question d'usage aussi, quand je fais du JS j'ai peu de dépendances, comme lorsque je fais du ruby.

Oui, nous sommes d'accord. Tu peux faire du mauvais ou du bon code avec n'importe quel langage. En théorie, du moins. En pratique, la qualité moyenne (je ne parle pas de toi spécifiquement !) varie fortement d'un langage à l'autre.

Oui, mais via un outil maison pour appliquer stdeb sur toutes les dépendances avec d'éventuels patches.

C'est pas sérieux comme argument. Sinon tu pousses le raisonnement et tu n'utilise aucune bibliothèque ou framework, aucune dépendance d'aucune sorte puisque tu ne maitrise pas la qualité de tes dépendances à moins d'aller toutes les auditer.

Tu ne peux pas pousser à fond cet argument sans le vider de sa substance. Le problème n'est d'avoir des dépendances et un graphe de dépendance quelconque. Le problème est d'avoir beaucoup de dépendances et un graphe de dépendance compliqué.
Si tu as dix dépendances qui n'ont quasiment pas de dépendance, il est humainement possible de s'en occuper.

Si tu as cent dépendances qui ont chacune un graphe de dépendance complexe (tu augmentes fortement la probabilité qu'il y ait un problème dans une dépendance de dépendance de dépendance, dans un code que tu ne maîtrises absolument pas), ce n'est plus humainement possible de s'en occuper.

Ce n'est pas un problème de qualité, c'est un problème de quantité. Et en pratique, ce problème arrive avec JS, pas avec Python.