flan a écrit 1848 commentaires

Personnellement, je n'ai pas souvenir avoir de bugs liés à l'indentation, et encore moins à cause d'un mélange d'espaces et de tabs. Alors, certes, j'utilise un IDE utile, à nouveau…

C'est surtout que quand on fait du calcul intensif avec Python, ce sont toujours les mêmes bibliothèques qui reviennent (coucou NumPy) et celles-ci sont a priori plutôt bien travaillées.

J'ai beau chercher, je ne vois vraiment pas l'intérêt de cette construction. C'est différent d'à peu près tous les autres langages objet (rien que ça, c'est un gros défaut car il est naturel de vouloir réutiliser les concepts déjà connus), alors que le seul intérêt affiché est de pouvoir changer dynamiquement d'héritage… je sens le truc qu'il ne faut surtout pas faire en pratique (intuitivement, si un objet a besoin de changer tout le temps de parent, c'est qu'il y a un petit souci quelque part…).

Et ça, c'est sans parler des autres trucs qui ressemblent à ce que font les autres langages mais en fait ce n'est pas pareil. Par exemple {toto: "titi", tata: "tutu"} est la même chose que {"toto": "titi", "tata": "tutu"} (donc parfois mettre des guillemets ne change rien — je n'ai jamais vu ça ailleurs) et bien sûr c'est un objet avec les propriétés "toto" et"tata" et surtout pas une HashMap (ou dict pour les Pythonnistes) qui serait écrite Map([[ "toto", "titi" ], ["tata", "tutu"]]).
Bon, personne n'utilise l'objet Map officiel (sans rire, je ne l'ai jamais vu utilisé) et tout le monde utilise des {} comme des HashMap.

Oui, on est d'accord, mais la PEP008 est déjà pas mal. Avec un peu de chance, black deviendra un outil officiel :)

Bof.

D'une part, ce n'est pas parce que tu codes en Python que ton CPU va passer son temps dans du Python (si le cas s'y prête bien, ton code passera son temps soit à faire des E/S, soit dans du code hyper optimisé en C ou tout autre langage performant).

D'autre part, c'est bien joli de dire qu'il faut faire du code optimal, mais combien de temps cela prend-il ? Bah oui, pour prendre mon petit cas personnel au boulot (et en perso, d'ailleurs), le code est très souvent sous-optimal et je le fais ainsi en toute connaissance de cause. Simplement, ça coûterait beaucoup plus cher de faire du code optimisé (en plus d'être parfaitement inutile).

Un autre avantage : tout le monde (ou presque) code en Python de la même façon, en respectant (plus ou moins) la PEP008 sur la norme de code. J'ai très rarement des problèmes pour me plonger dans le code des autres (bien moins que dans d'autres langages).
Certes, on peut faire du Python avec des tabs ou 5 espaces par indentation… mais je ne me souviens pas en avoir rencontré.

L'utilisation de black va encore augmenter ça, je pense.

Je suis d'accord : la transition a été douloureuse, mais elle était absolument nécessaire.
Le print n'est absolument pas un problème (plein d'outils peuvent le corriger automatiquement, comme 2to3).
Le vrai problème a été posé par la transition unicode vers str. À côté de ça, le reste des incompatibilités ne coûte rien à corriger. C'était le point à corriger, et quitte à le corriger, autant corriger tous les autres points mineurs (dont print).

Expérimentalement, je constate qu'une grande partie des bugs que je rencontrais en Python 2 ont disparu en Python 3 grâce à cette transition.

Personnellement, j'utilise un IDE utile (PyCharm, en l'occurrence). Autrement dit, il me détecte à l'écriture à peu près toutes les erreurs qui seraient détectées à l'écriture également avec du C ou tout autre langage typé. Au besoin, si l'inférence de type ne suffit pas, j'aide un peu l'IDE avec des annotations (notamment pour les rares cas où il ne peut pas deviner l'info).
Si j'ai une erreur de type à l'exécution, c'est qu'il y a un souci (pas assez d'annotation), mais c'est vraiment rare.

Alors, certes, on peut faire des choses « sales » à l'exécution (bien pire qu'ajouter des méthodes ou des classes :D), mais c'est clairement déconseillé. Cela dit, l'auteur de Python a toujours considéré que c'était un langage pour adultes : si tu veux faire des choses de ce genre, tu peux, mais tu en assumes les conséquences.

Ou alors on prend la définition d'un abus, autrement dit un usage excessif ou mauvais.

Si tous les contributeurs avaient forké dans leur coin au loin de contribuer à la source, on peut légitimement considérer cela comme plutôt nuisible à l'avancement du projet…

Et ? Parce que c'est un droit donné par les licences libres, on ne pourrait pas abuser de ce droit ? J'ai du mal à comprendre le lien, à vrai dire.

Après, ce n'est pas parce que l'éditeur écrit plein de clauses dans son contrat qu'elles seront forcément reconnues comme valables en justice, en cas de litige…

Je subodore même que si tu fais un logiciel qui a pour seul but de faire une action purement répréhensible, tu auras fait faire une belle licence te dédouanant de toute responsabilité, tu auras certainement quelques soucis avec la justice.

Même pour ce genre de logiciels, tu peux avoir des surprises. Pas à cause des perfs de Python en soi, mais parce que tu peux écrire des codes de calcul intensifs 100% en Python qui en fait ne font sous le capot que des appels à des bibliothèques en C.

Non. On peut très bien préférer la sécurité et ne jamais vouloir basculer en http.

Du RAID-5 ? J'espère que les disques ne sont pas trop gros… Vaut mieux du RAID-6 globalement.

C'est même plutôt un prédécesseur sur le sujets : les applications ne peuvent pas accéder à toutes les API (y compris le système de fichiers) par défaut. Avec la version actuelle (Mojave), il est nécessaire d'explicitement autoriser un terminal à accéder à l'ensemble du système de fichiers (sachant que les restrictions UNIX classiques s'appliquent toujours, bien sûr).

L'accès à la géolocalisation ou au carnet d'adresse est limité depuis plusieurs années, également.

Pas forcément : celui qui l'a codé vingt auparavant était peut-être un expert du Perl ;)

Y a-t-il un but particulier derrière l'écriture de ce nouveau moteur ?
« pour le fun » est bien sûr une réponse valable, mais peut-être y a-t-il d'autres raisons (je ne connais pas nodejs, mais il a sûrement certains défauts).

Quelque part, c’est assez logique que le second arrivé sur le marché ait appris des erreurs du premier :)

launchd a même été envisagé par certaines distribs, de mémoire.

Je parle d’un sommaire de l’ensemble des pages, pas seulement au sein d’une seule page ;)

Pour avoir testé ça récemment, je pense l'exact contraire.

Il est très facile de sécuriser du HTML : tu le parses et tu le réécris tel quel, en ignorant toutes les balises et attributs qui ne sont pas dans une liste blanche. Par exemple, pour la balise a tu autorises l'attribut href uniquement.
Au contraire, sécuriser du Markdown avant conversion en HTML est plus complexe : si tu protèges violemment les « < » et « > » (en les remplaçant par les entités HTML), ça va casser les citations Markdown (par exemple).

Quant à passer du Markdown… en fait c'est également un sacré bazar avec les retours à la ligne, les listes imbriquées, les changements de paragraphe… Quand tu as des enchaînements de paragraphes dans un élément de liste, elle-même dans un second paragraphe d'un élément de liste, tu te retrouves à jouer à l'aveuglette sur le nombre d'espaces qu'il faut mettre en début de ligne.

J'ai été beaucoup plus convaincu par un éditeur WISYWIG comme CKEditor5 dont la représentation est un sous-ensemble limité de HTML.

chiffrement est encore mieux ;) chiffrage est plutôt la mesure d'un coût.

Parce qu'il y aura toujours un moment où il faudra un peu plus que les balises de base du HTML. Du coup, on va commencer à utiliser des classes CSS pour spécialiser un peu certaines balises de base (comme distinguer liens internes et liens externes, ou mettre des paragraphes avec un fond orange pour des avertissements, comme ici ). Puis on se rend compte que pour avoir un beau rendu, il va falloir encapsuler tout ça d'un div supplémentaire, ou mettre le titre de la bulle en gras (donc ajouter un strong).

Et comme on aura déjà fait plusieurs pages de HTML, il faut tout revérifier à la main, en oubliant bien sûr la moitié.

Et imaginons qu'on veuille avoir un lien sur tous les titres ? Pourquoi devoir les faire à la main quand on pourrait les générer à la main ? Idem, si on avoir un bête index.

Bof. Le terme « digital » est tellement répandu que beaucoup ne connaissent que celui-ci…

C’est le vendeur qui choisit, car en fait il choisit un niveau de risque. Soit il prend une bonne sécurité et il sera bien remboursé, soit le contraire.