Entretien de la communauté Python avec Sebastián Ramírez – Real Python

By | juin 7, 2021

Formation Python

Aujourd'hui, je suis rejoint par Sebastián Ramírez, développeur de logiciels chez Explosion AI. Il est également le créateur des frameworks populaires FastAPI et Typer. Dans cette interview, nous discutons de la saisie en Python, de ses motivations pour créer FastAPI et de l'avenir du framework, et bien plus encore. Sans plus tarder, entrons-y.

Ricky : Merci de m'avoir rejoint, Sebastián. J'aimerais commencer par les mêmes questions que je pose à tous mes invités : comment êtes-vous entré dans la programmation et quand avez-vous commencé à utiliser Python ?

Photo de profil de Sebastián Ramírez

Sébastien: Merci de m'avoir

J'ai commencé à coder quand j'avais environ quinze ans, en essayant de créer un site Web pour l'entreprise de mes parents. Le premier "code" réel que j'ai écrit était du JavaScript dans un code HTML avec un alert("Bonjour tout le monde"). Je me souviens encore de la montée d'excitation en voyant ce petit message d'alerte et du puissant sentiment de penser que je l'avais codé.

J'avais peur d'apprendre une autre langue pendant des années, pensant que je devais d'abord maîtriser "au moins" JavaScript. Plusieurs années plus tard, l'un des nombreux cours en ligne que je suivais à l'époque nécessitait Python pour contrôler un Pac-Man AI et d'autres choses. Le cours comportait un seul didacticiel de longue page avec uniquement les bases de Python, et c'était suffisant pour ce cours. Je voulais vraiment l'essayer, alors je suis allé de l'avant avec ce didacticiel de base.

Bien sûr, je suis rapidement tombé amoureux de Python et j'aurais aimé commencer plus tôt 😅

Ricky : Vous êtes actuellement développeur de logiciels chez Explosion AI, la société à l'origine du célèbre framework de traitement du langage naturel (NLP) spaCy. Pouvez-vous nous parler un peu de votre quotidien ? Qu'est-ce qui vous intéresse dans l'intelligence artificielle et l'apprentissage automatique, et quel outil Explosion AI a-t-il créé pour aider les développeurs à repousser les limites dans les deux domaines ?

Sébastien: Oui, Explosion est surtout connu pour spaCy, la boîte à outils NLP open source. Ils ont également créé Prodigy, un outil commercial inscriptible pour annoter efficacement des ensembles de données d'apprentissage automatique. Mon travail a été principalement sur Prodigy Teams, une version cloud de Prodigy axée sur les équipes avec plusieurs utilisateurs. Le produit étant très axé sur la confidentialité, créer une version équipes/cloud présente de nombreux défis particuliers.

Néanmoins, j'ai récemment a décidé de quitter l'entreprise. Je suis actuellement (au moment où j'écris ceci) en train de terminer toutes les vacances que j'avais accumulées 😁

Mon plan est de trouver un moyen de consacrer un pourcentage élevé de mon temps de travail à FastAPI, Typer et aux autres projets open source, tout en faisant probablement du conseil pour aider d'autres équipes et entreprises à rendre tout cela durable 🚀

Ricky : Les gens vous connaissent peut-être mieux en tant que créateur de FastAPI, un framework Web hautes performances pour la création d'API qui est rapidement devenu l'un des frameworks Web Python les plus populaires. Qu'est-ce qui vous a donné l'inspiration pour le construire, et qu'avez-vous prévu pour le futur ? Et pour ceux qui n'ont pas encore essayé FastAPI, pourquoi pourraient-ils choisir de l'utiliser pour leur prochaine API par rapport à d'autres frameworks populaires, tels que Flask et Django ?

Sébastien: En fait, j'ai évité de construire un nouveau cadre pendant des années.

J'ai d'abord appris et utilisé de nombreux frameworks, plug-ins et outils, améliorant toujours mon flux de travail (et celui des développeurs que je dirigeais), tout en améliorant les produits que nous construisions. Et comme je travaillais sur des start-ups, en pivotant toujours, en créant de nouveaux produits rapidement, etc., j'ai eu la chance d'itérer beaucoup sur ce processus consistant à trouver le "bon" workflow et les bons outils, en combinant les frameworks existants avec de nombreux plug-ins. ins et outils.

Dans le même temps, j'ai également eu la chance de travailler sur d'autres domaines, comme le front-end avec JavaScript, TypeScript, plusieurs frameworks, certaines applications hybrides, certaines applications de bureau Electron, etc. Et la plupart ou tous les projets étaient très centrés sur les données (science des données, apprentissage automatique, etc.), il était donc toujours important de disposer de bons moyens de communiquer les données.

À ce stade, j'avais de nombreuses fonctionnalités spécifiques que j'aimais de plusieurs frameworks, outils et même d'autres langages et écosystèmes :

  • Saisie semi-automatique dans l'éditeur
  • Détections automatiques d'erreurs dans l'éditeur (contrôles de type)
  • Simplicité du code
  • Validation automatique des données
  • Conversion automatique des données (sérialisation)
  • Documentation API automatique
  • Prise en charge des normes, comme OpenAPI pour les API Web, OAuth 2.0 pour l'authentification et l'autorisation et JSON Schema pour la documentation des données
  • Injection de dépendances pour simplifier le code et améliorer la réutilisation des utilitaires
  • Bonnes performances/concurrence

Mais je n'avais aucun moyen de réunir toutes ces fonctionnalités en même temps lors de la création d'API Web, et le meilleur flux de travail que j'avais mis au point comportait encore des pièges et des mises en garde. Cela nécessitait des intégrations de plug-ins difficiles, des composants obsolètes, des outils non documentés, du code dupliqué, etc.

Mais à un moment donné, il n'y avait rien d'autre à essayer. Et c'était mon signal. J'ai commencé à étudier les normes, telles que OpenAPI, JSON Schema, OAuth 2.0 et autres. Et j'ai commencé à concevoir comment je voulais que tout fonctionne, en testant d'abord sur plusieurs éditeurs, en optimisant l'expérience du développeur avant d'écrire le code interne réel.

Ensuite, je me suis assuré d'avoir les bons blocs de construction pour FastAPI : Starlette (pour toutes les parties Web) et pydantic (pour toutes les parties de données), tous deux dotés de performances et de fonctionnalités exceptionnelles. Et enfin, je me suis mis au travail pour mettre en œuvre ces conceptions sur la base des normes et de la meilleure expérience de développeur que j'ai pu trouver, ainsi que quelques extras (comme le système d'injection de dépendances).

Il y a beaucoup plus d'informations sur l'histoire, la conception et l'avenir de FastAPI ainsi que sur les alternatives, l'inspiration et les comparaisons dans les documents. En bref, FastAPI est né des apprentissages et de l'inspiration de nombreux autres outils, conceptions d'API et idées, et sur des bases très solides (Starlette et pydantic).

Pour ceux qui sont curieux de l'essayer, je suggère de consulter uniquement la page principale ou README et de suivre ce mini-tutoriel. En quinze ou vingt minutes, vous aurez une très bonne idée du fonctionnement de FastAPI, si vous l'aimez ou non, et si cela vous serait utile.

Pour ceux qui utilisent déjà d'autres frameworks dans un produit existant, ne sautez pas pour migrer vers FastAPI simplement parce qu'il a l'air brillant. Si votre produit fonctionne bien et que vous n'avez pas besoin de nouvelles fonctionnalités, ou si vous n'avez pas besoin des avantages de FastAPI, cela ne vaut peut-être pas la peine de changer.

Néanmoins, si vous souhaitez migrer vers FastAPI, c'est en fait relativement simple car il n'y a pas d'intégrations complexes. Vous pouvez utiliser des packages Python normaux combinés directement avec FastAPI, et vous pouvez migrer par petites pièces ou créer uniquement de nouveaux composants avec FastAPI.

Ricky : Typer est un framework d'interface de ligne de commande (CLI) que vous avez construit et qui est similaire à FastAPI en ce sens qu'il repose fortement sur la frappe de Python. je remarque un motif 😉 Qu'est-ce qui vous plaît tant dans la frappe, et pensez-vous que davantage de bibliothèques devraient adopter la frappe de Python ?

Sébastien: Oui tout à fait! Il y a un modèle très puissant là-bas. Les annotations de type (ou conseils de type) sont ce qui alimente la saisie semi-automatique et les vérifications de type dans les éditeurs. Et ces annotations de type ont été inventées pour servir cet objectif. Ces deux caractéristiques justifient à elles seules leur utilisation.

De plus, s'il s'agit d'un outil qui devrait être utilisé par d'autres développeurs, je souhaite vraiment que de nombreux packages Python pour la gestion, par exemple, l'infrastructure ou les clients SaaS adoptent pleinement les annotations de type. Cela améliorerait tellement la vie de leurs développeurs et faciliterait l'adoption de leurs outils.

Mais maintenant, dans le cas de pydantic, FastAPI et Typer, ces annotations de type contiennent déjà de nombreuses informations qui peuvent être utilisées pour créer des outils plus puissants. Ils contiennent implicitement des informations de documentation telles que "le nom devrait être une chaîne" et "l'âge devrait être un flottant".

Ces informations sur les annotations de type pourraient également être utilisées pour la validation des données, par exemple, si la fonction attend une chaîne mais reçoit un dictionnaire. C'est une erreur qui pourrait être signalée, et si le framework est basé sur des fonctions recevant des paramètres, le framework (comme FastAPI ou Typer) pourrait s'en charger.

Et puis ces annotations de type peuvent également être utilisées pour la sérialisation des données. Par exemple, dans une URL, tout est une chaîne, et il en va de même dans la CLI. Mais si on déclare dans les annotations de type qu'on veut un entier, le framework (FastAPI ou Typer) peut essayer de convertir une chaîne comme "42" de l'URL ou de la CLI dans un entier réel pour notre code.

Ainsi, alors, avec un fragment de code très intuitif et simple déclarant simplement un type pour une variable, nous pouvons soudainement obtenir trois fonctionnalités supplémentaires (validation, sérialisation, documentation) en plus des deux d'origine (auto-complétion et contrôles de type) . C'est beaucoup de valeur extraite de très peu d'effort de codage.

Et dans la grande majorité des cas, toutes ces caractéristiques nécessitent exactement la même information : « l'âge est un nombre entier ». Ainsi, en réutilisant le même morceau de code (l'annotation de type) pour déclarer cela, nous pouvons éviter beaucoup de duplication de code. Nous pouvons garder une seule source de vérité et éviter de futurs bogues si nous décidons de changer le type à un endroit (comme pour la validation) mais oublions de le mettre à jour également à un autre endroit (comme la documentation).

En ayant une déclaration de type unique, nous pouvons éviter beaucoup de ces erreurs liées au code dupliqué qui se désynchronise. Et ces fonctionnalités sont ce que FastAPI et Typer fournissent.

Ricky : Maintenant que vous avez créé des frameworks Web et CLI modernes très populaires, quels sont vos projets pour l'avenir ? Avez-vous d'autres projets en cours qui vous passionnent ?

Sébastien: Oh, oui, j'ai beaucoup de projets. Peut-être trop

Il y a plusieurs fonctionnalités que je souhaite ajouter à FastAPI et Typer. Je souhaite également travailler sur une interface utilisateur d'administration automatique pour FastAPI indépendante de la base de données (basée sur OpenAPI). Je souhaite travailler sur un moyen de mélanger pydantic avec SQLAlchemy pour les cas d'utilisation nécessitant des bases de données SQL (encore une fois, pour tirer parti de ces annotations de type et réduire la duplication de code).

Je veux aussi beaucoup améliorer le générateur de projet. Je souhaite améliorer, simplifier et mieux documenter tous les utilitaires autour d'OAuth 2.0, en utilisant des étendues, en m'authentifiant auprès de tiers, etc.

Je veux aussi, à un moment donné, essayer de faire des vidéos, éventuellement un cours, et faire plus de contenu sur l'apprentissage de toutes ces choses.

Ricky : Maintenant juste quelques dernières questions. Que faites-vous d'autre pendant votre temps libre ? Quels autres passe-temps et intérêts avez-vous en dehors de Python et de la programmation ?

Sébastien: Je n'ai pas eu beaucoup de temps pour d'autres choses ces derniers temps, mais j'espère que cela changera un peu à l'avenir 😅 Quand je peux, j'aime jouer à des jeux vidéo avec ma femme (ou parfois tout seul), regarder des films, et allez prendre un petit-déjeuner ou un café avec des amis à Berlin (quand il n'y a pas de pandémie).

J'aime aussi beaucoup travailler sur ces projets open source, donc je peux facilement y passer des heures le week-end sans m'en apercevoir 😁

Merci beaucoup de m'avoir reçu ! C'est un honneur de partager cette étape avec de nombreuses personnes que je suis et admire.

Ricky : Merci de vous être joint à moi pour cette interview, Sebastián. C'était super de te parler.


Si vous souhaitez contacter Sebastián à propos de FastAPI ou de tout autre sujet dont nous avons parlé aujourd'hui, vous pouvez contactez-le sur Twitter.

S'il y a quelqu'un dans la communauté Python que vous aimeriez que j'interviewe, laissez un commentaire ci-dessous ou contactez moi sur Twitter.

[ad_2]