flan a écrit 1830 commentaires

Sauf que justement je veux installer un outil pour plusieurs utilisateurs et qu’il ne touche pas aux dépendances.

Peut-être parce que le blanc et le noir sont les deux contraires les plus basiques, associés à la dualité jour (positif, symbole de la vie) / nuit (négatif, symbole de la mort).
Ça n’a très probablement rien à voir avec des histoires de race…

Ah mais j'aime beaucoup Python également !

C'est d'ailleurs pour ça que je suis autant agacé par ces soucis. Certes, ils sont mineurs (on les contourne quand même assez facilement), mais je trouve vraiment dommage qu'ils ne soient pas corrigés alors qu'ils peuvent rebuter de nouveaux venus (en pratique, je les rencontre à la mise en place de nouveaux environnements de développement, mais une fois que tout est en place, ça tourne comme une horloge) et que les solutions techniques sont assez simples.
Accessoirement, quand tu expliques la mise en place des outils de développement à un débutant Python, tu essaies d'expliquer les grandes lignes… et tu te retrouves à expliquer ces problèmes qui mettent en jeu des points assez obscurs.
Un peu comme si tu devais faire des apartés sur les nombres imaginaires dans une explication sur l'addition des nombres entiers : ça casse pas mal la fluidité de l'explication. Oui, ça sent le vécu ^{^}

En revanche, je suis bien conscient que les corrections peuvent être lourdes dans la mesure où ça casse la comptabilité (mais bon, le passage à Python3 aurait pu être le prétexte à un nettoyage… peut-être pour Py4 ?)

C'est vrai qu'on pourrait se poser la question :D
Mais pour moi, c'est clairement de Python.
Quand tu fais découvrir l'écosystème Python à quelqu'un et que tu l'aides à mettre en place son environnement de dév' (notamment sur des systèmes non directement connectés à internet), l'effet n'est vraiment pas terrible quand :
- pip install va déclencher des setuptools install qui vont foirer
- pip install ne fonctionne pas parce que problème TLS et il faut faire un curl […] | bash
- pip install ne fonctionne pas mais python -m pip install fonctionne
- pip install ne fonctionne pas mais si tu relances juste après à l'identique, ça fonctionne
- pip install toto --upgrade va mettre à jour toutes les dépendances, même celles que tu ne veux pas
- …

alors que théoriquement, tout aurait pu fonctionner avec le premier « pip install » s'il n'y avait eu aucun conflit de version et que pip et setuptools utilisaient la même config de miroir.

Ça ne répond pas à la question.

À l'instant, sur une Ubuntu 18.04 fraîchement installée, voilà ce que ça donne :

$ sudo pip3 install XXXXXX --upgrade
Traceback (most recent call last):
File "/usr/bin/pip3", line 9, in <module>
from pip import main
ImportError: cannot import name 'main'
$ sudo python3 -m pip install XXXXXX --upgrade
......
Successfully installed XXXXXX-1.1.2

Honnêtement, je trouve que ce genre de soucis ne donnent pas une bonne image du langage.

Quand je vois maître-esclave sans aucun contexte, je pense d'abord à de l'ordonnancement en informatique.

Je pense que personne n'est contre l'idée de changer de terme pour en prendre un plus adapté.

La question est de changer de terme parce que le terme « esclave » fait penser aux esclaves actuels en Arabie Saoudite, ou au Nigéria avant que les Anglais n'y mettent fin au début du XXème siècle.
Mmmmh en fait, je crois que ceux-ci, on s'en fout un peu en fait, désolé.

Tiens, c'est intéressant à savoir. La dernière fois que j'ai essayé — en 2013 je crois —, la version était antédiluvienne (genre 2.2 ou 2.3), la doc était spartiate. Du coup, je n'avais pas pu jouer avec :(

On peut avoir des résultats rigolos avec certaines recherches sur le LaTeX :)

Comme d'hab, les problèmes de Google viennent d'un abus de position dominante. Pour avoir des soucis de ce genre, encore faut-il avoir une position dominante, autant dire que MS n'est pas près d'être embêté dans le domaine de la recherche internet.

Ça fait un certain temps que j'entends parler de TypeScript, mais je n'ai jamais pris le temps d'essayer. Même si je fais peu de JavaScript, je me dis que toute chose permettant d'avoir davantage de garanties sur mon code est bonne à prendre.
Accessoirement, ça n'a pas l'air d'être très dur de s'y mettre, surtout si tout code JS valide est un code TS valide.

En fait, je pense que c'est surtout l'inférence de type, très efficace même s'il faut parfois l'aider un peu, qui m'est le plus utile au quotidien.
Sans attendre la qualité d'un langage statiquement typé, on s'en rapproche fortement.

Et du coup, dans 200 ans, nous devrions être encore au C ?
Bien évidemment qu'un jour le C sera remplacé (même s'il y aura certainement quelques usages résiduels, tout comme on peut encore trouver du Windows 3.11 de nos jours).

Au passage, le C sera peut-être remplacé par le Swift, en tout cas chez Apple. Il a en tout cas été créé sur mesure pour ce faire.

Concernant les erreurs de type, qu'utilisais-tu comme IDE ?

Depuis que je suis passé à PyCharm (en l'aidant parfois un peu avec les annotations), ça ne m'arrive plus qu'exceptionnellement. Entre vim et PyCharm, j'ai dû diviser par plus de 10 les erreurs de typage.

Je ne recommandes pas du conservatisme pour Python, je trouve simplement qu'on se retrouve avec deux classes qui font doublon, ou alors j'ai raté quelque chose sur la différence entre dict et OrderedDict.

Et je ne recommande pas non plus du conservatisme pour les outils de packaging, je pense au contraire qu'il aurait fallu finir la transition (actuellement, on a un mélange de pip et de setuptools largement incompréhensible quand on n'est pas connaisseur des subtilités de Python) pour n'avoir qu'un seul outil de gestion de package.
Accessoirement, rajouter twine rajoute un nouvel outil à installer et à découvrir. Il aurait peut-être été plus intéressant de l'intégrer dans pip, ou simplement moderniser setuptools.

Personnellement, j'ai eu des soucis avec pip et des Ubuntu 16.04, avec une méthode super propre qui consiste à faire du curl … | bash (pénible à faire quand tu es dans un réseau sans accès direct à internet et que rajouter un package en dehors des quelques technos de miroir maîtrisées est coûteux).

Je trouve qu'officialiser l'ordre conservé dans les dict est une mauvaise idée, alors qu'on a les OrderedDict pour ça.

Je sais que c'était à la base un peu par hasard (l'implémentation des OrderedDict s'est trouvée être plus efficace que l'implémentation des dict et donc a été reprise telle quelle pour les dict), mais que se passera-t-il quand on trouvera une implémentation encore plus efficace mais qui ne respecte pas l'ordre ? Fera-t-on des dict, des OrderedDict et des UnorderedDict ?

Sinon, il y a eu quelques autres petits changements dans l'écosystème : les vieilles versions de pip sont cassées (algos TLS qui ne sont plus acceptés, si je ne me trompe pas), et python setup.py sdist upload va disparaître.

Du coup, parfois un pip install pip --upgrade ne passe plus alors qu'un python3 -m pip install passe…

Je trouve franchement dommage d'introduire de nouvelles incompatibilités dans un écosystème déjà compliqué. Il aurait été bien plus utile de dégager setuptools/easy_install qui n'utilise pas la même configuration que pip. Par exemple, quand j'installe A qui dépend de B avec pip install A, B sera probablement installé via setuptools et non pip.
On ne voit pas la différence, sauf quand on utilise uniquement un miroir privé. Parfois l'installation fonctionnera, parfois non…

L'option choisie par l'équipe est clairement d'introduire les incompatibilités peu à peu, sûrement par peur de recommencer l'épopée Python 3, qui a mis plus de 10 ans à être réellement adopté à cause d'un trop grand nombre d'incompatibilités.

Même si ce sont des threads distincts, j'imagine que ça lance le calcul sur le fichier complet fraîchement enregistré sur disque à chaque modification. Ça doit se ressentir sur des fichiers un peu longs.

Ou comme si c'était simplement lourd et pénible.

C'est peut-être de la simple optimisation tout à fait objective.

Tu as un montant X (en euros) à dépenser, et un paquet d'étudiants E.

Tu as une fonction f(x, e), qui correspond au niveau de l'étudiant à la fin de ses études, en fonction de son niveau évalué à l'entrée et de la somme investie pour lui.

Bien sûr, tu n'auras jamais de valeur précise ou fiable, mais globalement on peut espérer que f sera croissante en x et e (plus t'investis, ou meilleur est l'étudiant au départ, meilleur il sera à la fin — ça semble raisonnable).

Ensuite, il faut déterminer ce qu'on veut optimiser (ce qui n'est malheureusement jamais dit dans les programmes politiques, alors que c'est le plus important) :
- le niveau moyen ou médian ?
- le niveau des 5% meilleurs ?
- le niveau des 95% meilleurs (en gros on aide presque tout le monde mais on abandonne les cas désespérés) ?
- le niveau des moins bons ?

Dans ce qui suit, les chiffres sont donnés au pifomètre, bien sûr.
Si on consacre 5% de son budget pour 1% des élèves (c'est un peu le principe des ENS), ça permet de doubler leur niveau en sortie et ils pourront servir de « locomotive intellectuelle » (pour doper l'innovation, la recherche, former des disciples, …).
Si on fait ce que tu proposes (répartition parfaitement égale entre les étudiants), on va avoir un gain négligeable (5,2%) pour 99% des élèves et une énorme perte (80%) pour le 1% qui devait tirer tout le monde vers le haut. Je ne suis pas sûr que la société en sorte gagnante…

En tout cas, dire que la société irait mieux en donnant la même chose à tout le monde est loin d'être évident, surtout sans aucune donnée un peu chiffrée.

Pour moi, il est très utile d'avoir une adresse différente par service (qui redirigent toutes vers deux ou trois adresses).
Cela permet d'isoler définitivement (rediriger vers la corbeille) une adresse qui est compromise (une fuite de données, par exemple).
De plus, si ton adresse @linuxfr est compromise avec son mot de passe, cela évite que ton compte @linuxorg soit attaqué (même si bien sûr ton mot de passe n'a rien à voir).

Partant de là, le catch-all est utile car tu n'auras peut-être pas la possibilité de créer l'alias au moment de créer un nouveau compte (par exemple si tu es en magasin, ou si tu n'as pas ton keepass avec toi).

En effet, j'ai lu un peu vite ; en cas d'hébergement on fait ce qu'on veut. Il faut accepter les contraintes et risques liés, mais j'imagine que c'est pris en compte.

Le catchall est de moins en moins accepté par les hébergeurs. Gandi et OVH y ont renoncé, par exemple.

Et ce que je reproche c'est que c'est les mêmes qui vont reprocher de payer trop d'impôt, qu'on donne trop d'APL etc. (pour info le président a fait l'une de ces trois écoles)

Bin pour le coup, je me sens un peu concerné, et je trouve un peu facile de dire que ce sont les mêmes qui reprochent de payer trop d'impôts.
J'en connais pas mal qui sont dans le même cas, et je n'ai pas souvenir d'avoir réellement entendu ce discours.
Certes, tu dois certainement trouver du monde qui tient ce discours… mais à nouveau, ta généralisation me semble franchement trop rapide. A priori, quelque soit le discours, tu trouveras du monde qui le tient.

Accessoirement, on peut aussi considérer que l'impôt est mal employé.