flan a écrit 1829 commentaires

et pourquoi pas « démonstrateur », tout simplement ?

Apple a réussi un trimestre à capter plus de 100% des bénéfices totaux du secteur (oui, il y avait des fabricants déficitaires).

Au contraire, pour une trentaine d’euros par an (peanuts par rapport au total téléphone et abonnement), la sauvegarde est beaucoup plus simple qu’avec un ordi classique. Tu actives l’option « sauvegarde iCloud » et c’est tout. Si tu perds ton téléphone, tu choisis l’option « restaurer depuis iCloud » et tu retrouves ton environnement (applications installées, organisation de l’écran, préférences, documents, photos, mots de passe enregistrés, …).
Sinon, tu peux activer l’option « sauvegarde wifi » quand un ordi avec iTunes est disponible à proximité. Il faut brancher le téléphone à l’ordi la première fois, mais après il suffit de mettre son téléphone à charger pour que la sauvegarde se fasse.
Il faudra alors brancher le nouveau téléphone au même ordi pour une restauration.

Sur macOS, le moteur d'indexation (Spotlight) fonctionne depuis 13 ans environ, concerne l'ensemble du système et fonctionne avec le moteur d'historique (TimeMachine).
C'est séparé du système de fichiers mais chaque application peut lui amener des infos.
Par défaut, les métadonnées ID3, EXIF, PDF, et autres classiques sont analysées et enregistrées automatiquement.

De plus, le Finder vient avec un système de tags (un simple couple couleur/nom, par exemple rouge/important, vert/travail, bleu/maison, etc.). Je peux ajouter des tags et des commentaires à n'importe quel fichier.

J'ai un champ de recherche accessible en permanence. Si j'y tape le nom d'une personne, par exemple Nicolas Bourbaki, j'ai accès à :
- sa fiche de contact qui contiendra au hasard l'adresse nb@ens.fr et son surnom «Cauchy»,
- tous les mails qui contiennent nb@ens.fr, Nicolas Bourbaki ou Cauchy,
- les pages web qui parlent de lui dans mon historique de navigation internet,
- les morceaux de musique qui y font référence,
- de façon générale, les fichiers qui y font référence (dans le titre, le contenu ou les métadonnées),

Mais ça va un peu plus loin, vu que si j'ouvre l'application Photos et que je vais dans la rubrique « Personnes », j'aurais toutes les photos de Nicolas Bourbaki dès que j'aurais associé son nom à son visage sur une seule photo. Je peux également chercher les photos faites à proximité d'un lieu (si les coordonnées sont enregistrées, souvent le cas avec les téléphones ou si c'est fait a posteriori dans le logiciel).

Si j'ouvre le calendrier, je peux rechercher tous les événements ajoutés depuis un mail de Bourbaki ou qui y font référence directement.

Si j'ouvre Plans et que j'y tape son nom, il va m'afficher son adresse s'il la connaît (via mes contacts, par exemple).

Maintenant, ce n'est pas encore fini : la plupart des applications permettent de faire des « dossiers intelligents » (autrement dit, des critères de recherche enregistrés) qui se basent sur cette indexation :
- Contacts aura un dossier « contacts dont l'adresse est à Paris, qui ont été ajoutés dans les 6 derniers mois et dont l'anniversaire est dans les 15 jours »,
- Mail aura un dossier « mails non lus de la semaine qui contiennent le mot urgent »,
- Finder aura un dossier « fichiers avec le tag rouge/important »,
- Photos aura un dossier « photos de Bourbaki prises par un Sony Coolpix »,
- iTunes aura un dossier « chansons des années 80 les moins écoutées ».

Pour finir, je parlais de TimeMachine : toutes ces possibilités fonctionnent avec le « voyage dans le temps » :
- je supprime Bourbaki de mes contacts,
- je lance l'application Contacts et j'ouvre la liste des mathématiciens,
- j'appelle TimeMachine,
- je choisi la semaine précédente,
- la fiche de Bourbaki apparaît à nouveau et je peux alors la restaurer.

Bref, j'ai l'impression que ce que tu souhaites existe déjà, dans une large mesure.

Il n’y a pas de raison imparable dans un sens comme dans l’autre. En revanche, la PEP008 et l’outil black (qui reformate ton code sans te donner le choix) sont des raisons objectives qui forcent mon choix. Par exemple je préfère les simples quotes mais black fait des doubles quotes : je m’y suis fait car black est super utile.

Il aurait pu être pas mal de plus expliciter les deux grandes stratégies possibles pour la migration :
- rendre du code Python 2 compatible avec Python 3,
- rendre du code Python 3 compatible avec Python 2.

Bien sûr, on peut faire le 1) puis le 2), pour finir par se débarrasser de Python 2.

Le 2) est plus facile car Python 3 est plus strict que Python 2 et une bonne partie du travail est faisable automatiquement.
Souvent, la partie compliqué est de savoir convertir les str de Python 2, qui deviennent soit des bytes, soit des str en Python 3 (et parfois l'un ou l'autre en fonction de leur valeur…). Au contraire, les str de Python 3 deviennent en Python 2 des unicode et les bytes deviennent des str : pas de question à se poser.

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.