Pygithub: Prise en charge asynchrone

Créé le 24 mai 2020  ·  10Commentaires  ·  Source: PyGithub/PyGithub

Que pensez-vous du support asynchrone de PyGithub ? Si je fais du support asynchrone pour PyGithub - l'acceptez-vous ?

Commentaire le plus utile

Je ne pense pas que ce sujet doive être clos. L'utilisation asyncio pour les opérations liées aux E/S est le cas d'utilisation parfait.

Tous les 10 commentaires

De quelle manière ajouteriez-vous le support asynchrone ? Étant donné que la plupart des opérations sont effectuées à distance sur GitHub et que notre code attend une réponse ou un blob JSON, en quoi cela aiderait-il ?

Étant donné que la plupart des opérations sont effectuées à distance sur GitHub et que notre code attend une réponse

C'est une bonne raison pour l'introduction asynchrone ! Je veux dire ... PyGithub devrait gérer l'accès à l'API en tant que coroutines, sinon la plupart du temps, il attend la réponse du serveur au lieu de faire quelque chose d'utile. C'est un concept courant sur nodejs et il est actuellement pris en charge sur @octokit/rest.js
Je suis surpris que personne n'ait demandé cette fonctionnalité avant...

Obs : j'ai peut-être mal compris le fonctionnement actuel de PyGithub, mais je pense que les wrappers d'API séquentiels et synchrones sont moins efficaces qu'un wrapper asynchrone.

Je pourrais ajouter une nouvelle classe AsyncRequester et créer dans toutes les autres classes des méthodes asynchrones pour interagir avec elle, tout en préservant la logique.

Le code asynchrone peut être utile dans les tâches où vous devez produire un grand nombre de requêtes, par exemple, dans une recherche. Cela vous permettrait également de travailler rapidement avec plusieurs comptes sur Github

Ce qui ressemble à une refonte complète, avec l'ajout de la prise en charge de l'utilisation de plusieurs comptes. J'aime votre enthousiasme, mais je pense que c'est énormément de travail pour pas assez de gain.

Cela pourrait impliquer beaucoup de travail, mais j'aimerais le voir mis en œuvre. Actuellement, je suis coincé avec JS dans mes recherches car les performances de @octokit/rest.js dépassent celles de PyGithub. Si vous avez besoin d'aide, je serais heureux de travailler là-dessus aussi.

Au fait, je pense que le support de plusieurs comptes serait trop ! L'asynchronisme n'est-il pas un premier pas formidable vers des gains de performances ?

Peut-être que je peux faire n'importe quelle édition et l'afficher dans une demande d'extraction ? Pour essai

Asyncio semble être une bonne idée compte tenu de mon cas d'utilisation. J'essaie de lire tous les fichiers d'un référentiel de manière récursive et les requêtes synchrones sont tout simplement trop lentes (il me manque peut-être quelque chose comme la limitation de débit sur l'API de github, mais nous pourrions certainement accélérer ces opérations).

Je suggérerais fortement d'utiliser quelque chose comme GitPython pour cela plutôt que de tout demander via l'API GitHub.

Merci pour la suggestion intéressante, je vais essayer car il est logique de le faire de cette façon.

Je ne pense pas que ce sujet doive être clos. L'utilisation asyncio pour les opérations liées aux E/S est le cas d'utilisation parfait.

Cette page vous a été utile?
0 / 5 - 0 notes