Tiens pendant que j'y pense, l'AFPY est en train de traduire la doc de Python en français (on peut contribuer sur github). Il semble acquis qu'une fois bien avancé elle sera intégré à celle officiel de python, sur https://docs.python.org (actuellement ils discutent de la forme des url pour les traductions de docs).
Outre le coté informatif, est ce qu'il faudrait à terme qu'on incite les auteurs a préféré les liens vers la doc française plutôt qu'anglaise (quand elle sera intégré officiellement) ?
Complètement. Ça ne peut être qu'une bonne chose de garder les tutos (au moins de niveau débutant/intermédiaire) dans un environnement français.
Pour les tutos avancés je suis plus mitigé. Déjà ça me semble moins nécessaire, et surtout l'autonomie ne se gagne réellement qu'à partir du moment où on est capable de lire la doc de n'importe quel module/framework couramment. Hors doc standard, ça veut dire en anglais, donc sans recommander une guideline particulière, je pense qu'il n'y aura pas d'effort particulier à pousser de ce côté.
PS : Oh ! Et puis merci pour l'info. C'est typiquement le genre de truc pas très compliqué auquel on peut contribuer.
Ce n'est pas une mauvais chose je pense, mais pour les débutants. Aujourd'hui c'est ce que je fais avec Django (100% en français <3) mais personnellement, bien qu'étant français, je lis uniquement la doc en anglais.
Pour les bases de données je vois que vous n'avez pas mis sqlite3 alors que le module est fourni de base, y'a t'il une raison ? Pymongo est mieux ?
Hormis cela je pense que turtle peut être retiré de la liste vu que le sujet a été traité, et normalement je compte faire un tutoriel sur un module (je songeais à sqlite3 justement ou à bottle) mais pas dans l'immédiat j'ai déjà des choses qui vont peut être se faire ou à terminer
Non il n'y a pas de raison particulière. Pour répondre plus précisément à ta question, les deux modules ont des usages très différents : le choix d'un moteur base de données est un problème technique à part entière, car il n'y en a pas un qui soit meilleur à tous les niveaux.
Typiquement la première dichotomie à faire est entre les bases de données relationnelles (comme sqlite3, mysql, postgresql, oracle…), ou nosql (redis, mongodb, couchdb, cassandra…). Ce choix dépend de la façon dont les données sont représentées. Typiquement si le but du jeu est de faire beaucoup de croisements entre des données structurées, avec un panel de requêtes varié (par exemple le système d'utilisateurs d'un site web), une base sql sera probablement un meilleur choix : le fait que les données soient structurées permet de créer plein d'indexes différents pour y accéder.
Si au contraire, le but est de stocker des données par simples clé/objet (ou pas beaucoup plus complexe que ça), sans réel besoin de requêtes variées, mais avec une problématique de perfs et/ou de haut volume, ça peut être intéressant d'envisager une base nosql.
Dans ces conditions, sqlite3 est un système relationnel et a le mérite d'être léger. Il a donc pour lui l'avantage d'être simple, inclus dans la bibliothèque standard, et de respecter l'API standard de python pour les SGBD relationnels (en gros, passer à mysql ne demanderait que très peu de changement dans le code). Par contre il ne fonctionne qu'en local (y'a pas de notion de serveur), et ses perfs ne sont pas mirobolantes.
D'un point de vue pédagogique, sqlite3 a beaucoup d'intérêt : si tu sais l'utiliser, alors tu sais utiliser n'importe quel SGBD relationnel en Python.
Imposer le choix je pense pas : les bases nosql ne suivent pas totalement l'ACID lorsqu'elles sont distribuées et qu'une même donnée est susceptible d'être modifiée simultanément par deux utilisateurs mais ce n'est pas la mort non plus : c'est simplement à prévoir dans le design de l'application.
@Folaefolc j'ai recopié la liste telle quelle. Un tuto sur webbrowser, perso, ça me semble overkill : y'a peu de choses à en dire.
Sisi, ça peut imposer le choix. Il y a un certain nombre d'applications dans lesquelles tu ne peut pas te permettre de violer les propriétés ACID. Je pense notamment à tout ce qui est financier, et tout ce qui a une contrainte légale de cohérence (facturations, etc).
C'est exactement ce a quoi je pensai. Dans certains cas ces propriétés sont vraiment importante et c'est typiquement le genre d'applications où tu ne peux pas t'en passer.
Attention, certaines bases de données NoSQL (je pense à Cassandra ou MongoDB par exemple) offrent la possibilité de "passer" en mode ACID. Le Choix d'un SGBD Relationnel vs SGBD NoSQL aujourd'hui ne se limite plus à ça. Aujourd'hui on choisit un SGBD NoSQL en fonction de la nature des données que l'on veut traiter, de l'usage qu'on souhaite en faire, du niveau de Scalabilité que l'on veut, etc.
Certes mais dans ces cas particuliers la nature des données rend déjà les bases nosql peu pertinentes.
Pour moi le premier critère à retenir c'est d'abord celui-ci : isoler d'abord la façon dont s'articulent ces données et dont l'application doit y accéder.
Edit : grilled by firm1.
J'ajouterais également que s'il y a besoin ponctuellement d'ajouter une garantie de cohérence sur une opération donnée, l'appli peut elle-même se charger d'ajouter le mécanisme qui la fournit, et donc assumer l'overhead.
Attention, certaines bases de données NoSQL (je pense à Cassandra ou MongoDB par exemple) offrent la possibilité de "passer" en mode ACID. Le Choix d'un SGBD Relationnel vs SGBD NoSQL aujourd'hui ne se limite plus à ça. Aujourd'hui on choisit un SGBD NoSQL en fonction de la nature des données que l'on veut traiter, de l'usage qu'on souhaite en faire, du niveau de Scalabilité que l'on veut, etc.
Yes, but in a limited sense. MongoDB supports ACID transactions at the document level; today MongoDB does not support multi-document transactions. For many but not all applications, this is sufficient because data for a record tends to be managed as a single document. Like most databases, MongoDB uses write-ahead logging to an on-disk journal to guarantee write operation durability and to provide crash resiliency.
Consistency describes how and whether a system is left in a consistent state after an operation. In distributed data systems like Cassandra, this usually means that once a writer has written, all readers will see that write.
On the contrary to the strong consistency used in most relational databases (ACID for Atomicity Consistency Isolation Durability) Cassandra is at the other end of the spectrum (BASE for Basically Available Soft-state Eventual consistency). Cassandra weak consistency comes in the form of eventual consistency which means the database eventually reaches a consistent state. As the data is replicated, the latest version of something is sitting on some node in the cluster, but older versions are still out there on other nodes, but eventually all nodes will see the latest version.
Tout ça pour dire, ok certes tu peux le faire au niveau application mais on est je pense tous d'accord pour dire que si un outils ne garanti pas une propriété qui est très importante pour l'application, il vaut mieux ne pas l'utiliser plutot que de vouloir la garantir au niveau applicatif.
D’où les guillemets sur "passer" en mode ACID. Et comme ils le disent, dans la grosse partie des cas d'utilisations, leur mode ACID est bien suffisant.
Essai pas de te rattraper avec ta mauvaise foi. Les noSql ne sont pas ACID, c'est tout. Oui dans pleins de cas c'est pas gênant mais quand c'est important leur pseudo ACID ne suffit pas.
À la base on est parti du module sqlite3, qui s'en fout puisque c'est un SGBD local. De la même façon que redis est un SGBD nosql qui est ACID puisqu'il est lui aussi local. D'ailleurs c'est aussi un module interessant pour un tuto, redis.
Redis n'est pas de base ACID mais peut l'être parce que tu peux définir des groupes d'instructions exécutés de façon atomiques. Mais dans l'utilisation normale tu peux avoir des écritures concurrentes qui se tape dessus
Tu peux faire des écritures atomiques avec redis, sinon on peut dire que MySQL avec l'autocommit activé n'est pas ACID non plus : ça ne fait pas avancer le schmilblick pour autant. J'ai déjà eu à designer une écriture/update concurrente dans une base redis locale, avec une contrainte de cohérence, mais une seconde contrainte plus forte encore de perfs : il suffit de penser ses transactions et sa structure de données en conséquence.
Et dans ce cas précis, non, le besoin de cohérence et de transactions correctement lockées ne m'a pas poussé à choisir un SGBD relationnel, sqlite3 ne supporte pas bien le multithread, et lui comme mysql étaient bien trop lents pour répondre à mon besoin.
Donc je maintiens qu'implémenter les mécanismes qui te garantissent les propriétés ACID dont tu as localement besoin directement au niveau applicatif est une solution. Dans ce cas, la nature des données était tout indiquée pour une base nosql, et il était hors de question d'utiliser une base relationnelle à cause d'une bête contrainte de cohérence. La nature des données et celle des accès majoritaires à ces données (création/lecture) ont guidé le choix technique.
Edit : rhaaaa je viens encore de me faire aspirer dans ce HS tout nul sur ACID. Désolé. J'arrête de pourrir le thread ici.
Je suis intéressé pour l'écrire, et celui-ci fait partie du chemin critique donc il est plutôt prioritaire.
Quelqu'un a-t'il déjà créé le dépôt ?
De même, le tuto débutant de martinqt semble être arrivé à stagnation donc j'envisage de reprendre l'écriture de celui que j'avais commencé, car il aborde le sujet avec un angle original par rapport au reste de la littérature francophone, et que ZdS a vraiment besoin de ce type de contenu pour devenir une référence.
PS : aujourd'hui, je vais récupérer un ordi donc je pourrai mettre à jour le PO.
Alors justement, on en a discuté avec entwanne et c'est en train de se mettre en place (j'ai créé le tutoriel hier sur ZdS), je t'ajoute à la conversation et au tutoriel.
Pour le reste, j'aimerais bien contribuer à faire avancer le tutoriel de martinqt ou le tien, mais je dois faire des choix
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
