flan a écrit 1830 commentaires

Je ne connais pas toutes les distribs, mais Ubuntu ne propose que python3 par défaut (python2 n'est pas installé).

À peu près tous ceux que je connais ont réussi à se le faire payer par leur employeur, ou ont craqué à titre personnel. De mon côté, j'ai une license personnelle (mais je vais essayer d'en avoir une par le boulot).

Par exemple détecter si tu utilises un template inexistant, si dans le template tu utilises des filtres ou des variables inexistantes. Du coup, ça propose également de l'autocomplétion intelligente sur les noms de templates et des filtres ou variables. Ça permet de détecter que tu as oublier de charger une bibliothèque de templatetags.
Il propose de lancer les tests via Django quand tu fais un clic-droit sur un TestCase qui utilise la classe fournie par Django.

L'autocomplétion est également adaptée en Python, elle fonctionne avec les modèles (par exemple, si je tape User.objects.filter(, il va proposer username=, username_in, username_gt, … bref tous les filtres SQL disponibles) et les URL.

(et le README de pyimport m'a convaincu que PyCharm était beaucoup plus pratique pour ça :) )

Comme beaucoup, j'utilise PyCharm (Pro) pour faire du Python.

À vu de nez (je ne suis pas spécialiste Emacs), par rapport à PyCharm, il manque à ta configuration
- la détection automatique pour exécuter du code (clic-droit sur une docstring : il propose de lancer doctest, sur un fichier normal : il propose le fichier normal, sur un fichier de tests : il propose unittest, etc.)
- la gestion complète de Django et autres framework
- la gestion de la couverture de code
- l'inférence de type
- les imports automatiques (copier-coller d'un bout de code, et là tu fais Alt-Entrée -> Entrée pour chaque import manquant, sans même être sur la bonne ligne)
- la gestion du setup.py (par exemple tu ajoutes un package XXXX à ton setup.py, il propose de faire un pip install XXXX, ou au contraire si tu utilises YYYY, il te propose de l'ajouter à ton setup.py)

pour le libre, ça dépend des langages : il y a des versions libres et gratuites d'IntelliJ et PyCharm.

C'est a priori déjà possible, il suffit de faire tourner fail2ban sur un collecteur rsyslog.
Enfin, failt2ban ou tout autre système (graylog permet de le faire, par exemple)

on sait qu'il y a un déséquilibre et on veut en sortir.

pourquoi devrait-on sortir de ce déséquilibre, tant que chacun peut faire ce qu'il veut sans être gêné ?

Je suis conscient de répondre à côté de la plaque, mais avez-vous des raisons particulières de ne pas utiliser SQLAlchemy ?
Cette bibliothèque permet d'utiliser SQLite beaucoup plus facilement et d'éviter un certain nombre d'erreurs.

http://sametmax.com/les-critiques-des-orm-sont-a-cote-de-la-plaque/ (note : le slogan du blog est « du code, du cul » et ça peut être très explicite…)

Pas de typage dans les déclarations de méthode, même pas en commentaire
Ça rend la doc des fonctions, classes et modules juste misérable. Si au moins on pouvait avoir un équivalent de PHPDoc, et qu'il soit accepté par la communauté comme un standard, ça aiderait.

Je ne comprends pas trop… Pour la doc, il y a sphinx qui est très clairement le standard de facto, et tu peux indiquer le type comme tu veux. Tu peux également utiliser le TypeHinting, qui est utilisé par les IDE dignes de ce nom.

Les modules
Je sais que ça commence à s'améliorer doucement avec python3 et des brouettes, mais franchement, ça reste moisi. Et tout ça alors que c'est un besoin primaire de programmation de pouvoir facilement diviser son code en plusieurs fichiers. Ça trouve le moyen d'être plus louche que PHP composer et ses PSR.

Quel est le problème pour découper en modules ?

Je suis d'accord avec toi sur ce problème, et c'est dommage qu'ils n'aient pas profité de Python 3 pour changer également ça.
Enfin, ils ont déjà corrigé LE plus gros problème de Python 2 à mes yeux, qui était le mélange unicode/str.

Peut-être pour Python 4 ? :)

Python permet de développer vite, très vite, et en tout cas personnellement, je ne me vois pas développer aussi vite avec un autre langage de programmation (que ce soit grâce au langage lui-même, aux outils, à la bibliothèque standard ou aux bibliothèques existantes de façon générale).
Accessoirement, les morceaux qui ont réellement besoin de perf constituent rarement la majeure partie du code. Pour 95% du code (statistique complètement au jugé, évidemment), Python convient très largement.

Dans certains cas, c'est tout bêtement beaucoup plus rentable pour mon employeur de payer un ou deux serveurs supplémentaires que de me payer du temps supplémentaire à optimiser ou refaire dans un autre langage les parties requises.
Dans d'autres cas, c'est simplement un choix entre « un projet qui pourrait être plus rapide mais qui fonctionne » et « pas de projet du tout ». À nouveau, le choix est vite fait, même si on préférerait toujours avoir plus de perfs.

Je suis bien d'accord avec toi sur PyCharm. J'utilise beaucoup le TypeHinting, je n'hésite pas à rajouter s'il le faut des assert isinstance(x, y) ou un commentaire pour l'aider et je n'utilise que très exceptionnellement le typage dynamique (quand ça permet de vraiment simplifier le code). Au final, ça marche bien et j'ai vraiment très peu de bugs liés à des problèmes de type.

C'est de façon générale quelque chose de très demandé et étudié, on peut espérer du progrès à ce niveau (c'est également nécessaire pour augmenter les perfs).

Je voulais bien sûr dire que de toute façon on utilise des préfixes, avec plein de chiffres après la virgule qui sont perdus dans la nature. Bref, l'argument d'une pseudo-exactitude des Tio/Gio/… ne tient pas debout.

Quel était son inconvénient pour qu’on éprouve le besoin de changer ?

• garder le vrai sens des préfixes SI
• avoir des calculs plus simples et sans ambiguïté de façon générale
• avoir des conversions qui soient simplement… exactes (et oui : on a 1,023 kio = 1 047,55 o… ou 1 047 o = 1,022460[…] kio : conversion exacte impossible dans les deux cas)
• permettre des conversions et des comparaisons d'un coup d'œil (peux-tu comparer 0,49 Tio et 500 Gio ? )

Au final, on a quand même une habitude qui n'apporte pas grand-chose, voire rien du tout (les *io) face à un système (le SI) largement éprouvé, répandu et efficace.

Ça tombe bien, le parsec n'est pas une unité du SI, qui reste donc bien cohérent (et non consistant).

Du coup, la question, c'est pourquoi utiliser des puissances de 2 ?
Pour l'adressage ?

dans ce cas, on utilise de l'hexadécimal, et ce n'est pas pour indiquer réellement une taille (et donc on n'utilise pas les préfixes, vu qu'on veut l'adresse en entier)

Pour indiquer aux gens la capacité des machines qu'ils utilisent ?

je ne vois pas en quoi les puissances de 2 indiquent mieux la capacité des machines que les puissances de 10.

Pour comprendre ce que peux contenir un disque dur que l'on va acheter?

idem. Je peux immédiatement comparer un disque de 0,49 To et un disque de 500 Go. Peux-tu faire la même chose avec des disques de 0,49 Tio et de 500 Gio ?

En quoi la norme SI (même pas ISO) est-elle débile ?

Pourquoi utiliser un mélange de puissances de 10 et de puissances de 2 ? Quel est l'avantage de ce mélange, en fait ? Dans 99,9% (statistique au doigt mouillé particulièrement fiable, évidemment), on parle de toute façon en Mo, Go voire To, avec une valeur exacte qui ne s'exprime facilement ni en puissances de 2, ni en puissances de 10.

Accessoirement, il y a plein de contraintes qui rendent la chose beaucoup moins sexy :
- hors de question d'avoir la moindre confiance dans l'hébergement chez n'importe qui : dans le meilleur des cas, les données sont publiques et on peut se contenter de refaire plein de fois le même calcul (et on prend le résultat de la majorité, mais là il n'y a rien de neuf vu que SETI@home fait ça depuis 20 ans au moins), dans le pire des cas, … bah on ne veut surtout pas que les données soient en clair, et c'est rare de pouvoir travailler sur des données chiffrées : que fait-on dans ce cas-là ?
- les data-center, en plus d'apporter plein de puissance de calcul ont d'autres qualités, notamment la bande-passante et la latence : je ne suis pas sûr que ça puisse être remplacé facilement.

À vue de nez (après 15 secondes d'analyse du setup.py), il te suffit de créer un compte sur https://pypi.python.org , puis dans le dossier des sources de faire

python3 setup.py register
python3 setup.py sdist upload


Accessoirement, il n'y a même pas de renouvellement (donc aucune requête) quand le certificat est encore largement valide (plus de 10 jours, je crois).

Quake 3 a pas loin de 20 ans, il n'a strictement aucune chance d'utiliser toutes les ressources du matériel (c'est-à-dire utiliser les nouvelles fonctionnalités et pas seulement les instructions graphiques qui ont 20 ans).
En libre, je ne suis pas sûr du tout que ça existe de façon générale.

Juste par curiosité, pourquoi avoir pris une RX580, du coup ?

Tient, un truc bête : ne pas mettre du Windows dans les sous-marins nucléaires (ni sur les portes-avions, ni dans les ministères, etc) à cause des problèmes d'espionnage et de potentiel contrôle à distance. C'est tellement basique, mais non je pense que personne ne leur a téléphoné pour leur dire, je ne vois que ça comme explication.

Ou alors qu'ils ont bien pris le problème de l'espionnage et du potentiel contrôle à distance en compte, et que ça n'empêche pas d'utiliser du Windows.

Si :

qui possède […] 4 maisons et 1 appartement

(maisons et appartements sont des immeubles, comme le confirmera n'importe quel notaire).

dire que NH possède 5 immeubles est un peu simpliste, voire faux : un seul est détenu à 100%, les autres étant à 50, 25, 12 et 12%…

je cherche toujours un aspect positif de la chose…

La décentralisation du contrôle de la monnaie.

Et en quoi est-ce positif ? Le contrôle de la monnaie est un outil extrêmement utile à un état pour orienter son économie et adapter son taux de change vis-à-vis des économies des pays voisins. Ton assertion un peu péremptoire mériterait d'être un peu argumentée :)

J'ai l'impression que l'apport de Gufo se situe essentiellement au niveau de la syntaxe.
Il y a certainement beaucoup de progrès à faire, mais n'y a-t-il pas d'autres axes d'amélioration ?

Quelques idées en vrac :

• doit-on garder toujours uniquement stdin, stdout et stderr ? Pourquoi pas avoir plusieurs entrées (exemple tout bête mysql < monfichier.sql << mon-mot-de-passe) et davantage de moyens de sortie ?
• comme déjà dit plus haut, PowerShell (avec sa manipulation d'objets) permet de se passer de awk/sed/… qui ne sont pas très tolérants aux erreurs, est-ce que cela a été envisagé ?
• pourquoi ne pas intégrer un véritable affichage graphique (un ls affichant des icônes, au hasard, ou des tooltips qui s'affichent dynamiquement au-dessus de chaque argument ou commande) ?
• comment améliorer l'intégration de la souris dans l'écriture de commandes ?
• comment améliorer l'intégration des programmes externes (bash-completion est plus un hack qu'autre chose) ? on pourrait imaginer qu'un programme externe amène sa propre autocomplétion, une aide plus intelligente, une vérification de type avec les commandes suivantes, …
• pourquoi ne pas tenter quelque chose de totalement différent (par exemple, Automator d'Apple partage beaucoup de points communs avec un shell, pourrait-on envisager quelque chose qui s'inspire des deux ?)

Bien sûr, il y a potentiellement de gros problèmes de perf à prendre en compte et plein de mauvaises idées là-dedans, et plein d'autres bonnes idées à avoir.

Oui, la situation était différente il y a 50 ans.