La programmation Python et les IH

Tout d’abord, merci à tous pour vos retours

@doubletrouble

Je fais moi aussi du C (et du shell, évidemment - tellement évident qu’on l’oublie toujours), mais surtout pour du développement système - peu adapté ici donc, surtout que les librairies que j’utilise sont déjà optimisées avec du code C/C++ pour la plupart.

Avez-vous utilisé un framework particulier (django, joomla… autre ?) pour votre projet ? N’hésitez pas à nous indiquer quand vous en ferez la publication en tout cas, je gage que ça peut intéresser du monde

@blackfalcon

Quels autres langages, par curiosité ? J’en ai essayé plusieurs avant de me fixer sur le python, tellement déroutant de simplicité qu’il rend le complexe trivial, c’est vraiment un langage qui vaut le coup d’y investir un peu de temps

Je n’ai pas vraiment réfléchi à la question de la publication, d’autant que sans base de données il n’a pas vraiment d’intérêt autre que didactique… disons que ça reste un sujet ouvert.

En effet pour les cryptos, c’est ce qu’on m’a expliqué. Il faudrait que je m’y plonge pour me forger un vrai avis sur le sujet, pour le moment je suis assez ambivalent sur ces monnaies et me contente de les suivre de loin, considérant que c’est une variante à la mode du forex, la liquidité en moins…

@M07

J’utilise également Python à peu près quotidiemment pour du développement système, là mon choix de faire une interface graphique "lourde" a été dicté par la curiosité (découvrir tkinter, en l’occurence) et la nécessité (j’utilise matplotlib pour générer mes graphes, et vus les temps de traitement sur des périodes un peu plus longues que quelques années le navigateur finirait par perdre patience… à moins de rendre les graphes côté client en JS, vu que c’est matplotlib qui accapare la majorité du temps de génération).

Côté db j’utilise PostgreSQL pour stocker et interroger mes données (directement en SQL, via psycopg2 et pandas donc). La base est nourrie par divers "scrapers" qui s’occupent de consulter les pages de cours sur divers sites boursiers, d’extraire les données de la bouillie généralement informe qu’est leur HTML (via Beautiful Soup) puis de générer des fichiers CSV avec les données désirées, qui sont ensuite versionnées (git) et importées.

Je suis moi aussi passé par les pages finances de Yahoo et Google, j’ai d’ailleurs aspiré la plupart de mon historique depuis Yahoo pour les cours, et depuis divers sites de courtiers pour les listes de dividendes. Je n’utilise plus les pages finances depuis : c’est pratique pour récupérer d’un seul coup les données historiques, mais pour la maintenance quotidienne il vaut mieux interroger des pages listant les valeurs et cours de la journée (moins de requêtes, ça arrange tout le monde et on peut aussi collecter les cours intraday si on en a envie).

Python 2 est agonisant, je suis donc parti directement sur Python 3. J’ai la même approche que vous concernant les modules, étant moi aussi plus d’une fois tombé sur de magnifiques projets complétement obsolètes, et parfois sur des livres dont les exemples étaient antédiluviens, ce qui est extrêmement pénible et frustrant… J’ai donc essayé dans la mesure du possible de me cantonner à des modules "éprouvés" - je pense que vous conviendrez que la liste suivante est raisonnable :
- ceux fournis avec python même : tkinter et un paquet de modules de la librairie standard (datetime, notamment)
- les modules tiers majeurs : matplotlib pandas numpy beautifulsoup4 tensorflow
- les modules tiers "mineurs" : psycopg2 pygments dateutil keras
Je considère ici comme mineur un module dont la disparition soudaine ne me chagrinerait pas outre mesure : certes je devrais adapter mon code, au pire forker ledit module, mais ils ne sont pas "vitaux" contrairement à un module majeur où je serais bien plus embêté (matplotlib et pandas doivent représenter à eux seuls la grande majorité du code, en l’occurence). Quant à ceux faisant partie de la librairie standard, je ne m’inquiète pas outre mesure pour leur pérennité.

Toutefois il n’y a pas que le code qui risque de disparaître, il y a aussi les sources de données… risque que j’ai "dilué" en multipliant les scrapers, et donc les sources de données potentielles - ainsi la "panne" de yahoo finance suite à une modification d’API ayant cassé pandas_datareader ne m’a que fort peu impacté, les autres scrapers étant là pour compenser (et ayant déjà récupéré les valeurs historiques).

@Nappy

Vous savez, ce projet a commencé un peu de la même manière

Je me demande quelle taille github autorise pour les repos non payants… avec tous les CSV on flirte avec le GB, sans compter les metadonnées de git lui même, et sans db l’intérêt est assez limité. Peut être avec un simple CSV d’exemple, une sorte de démo technologique… mais ça a peu d’intérêt, je pense.

Une chose que je pourrais faire, par contre, serait d’enfin réunir mes propres modules et d’en faire un paquet pip autonome… ça me simplifierait aussi la vie, cela fait un moment que je me le dis

Ha, la limite semble "poliment" fixée à 1GB…

@roudoudou

Merci, mais le meilleur est encore à venir

@Geronimo

Votre site est diablement intéressant, comment en avez vous eu l’idée ? Suite à votre certification AMF j’imagine ?

En tout cas il va clairement falloir que j’intègre vos données oui, la tâche la plus difficile sera de trouver un nom à l’onglet Je pense que ça sera mon prochain développement, entre deux entraînements de réseaux de neurones. Je vous tiens au courant, et pourquoi ne pas collaborer sur des développements en effet !

@bombadil

Ha, vous avez poussé plus loin que moi, bravo Ayant utilisé Django vous devriez pouvoir le mettre en ligne aisément je pense, attention toutefois à bien tenir Django à jour, les scanners automatiques veillent… le web est un environnement hostile Toutefois comme vous le dites il manque également cruellement d’applications d’analyse fondamentale, il y aurait donc ici un public tout trouvé pour votre projet… si cela vous intéresse d’essayer de sauter le pas et d’ouvrir votre application sur le web, n’hésitez pas à me contacter

Votre processus semble très intéressant en tout cas, j’espère pouvoir faire de même mais il va déjà falloir que j’enrichisse ma base de données avec les informations fondamentales (vous les collectez où, directement sur les sites des sociétés je suppose ? quid du parsing des documents ?), jusqu’à présent je ne l’ai fait qu’à la main et pour une poignée de sociétés dans lesquelles je songeais justement investir… et surtout, que je m’instruise convenablement sur les méthodes - j’ai déjà parcouru le site des daubasses et bien que je pense avoir saisi les principes généraux, il vaut mieux que je lise les classiques sur le sujet avant de me jeter dans le code

Bonjour Laurent, heureux de savoir que j’ai une influence positive sur votre motivation

Scrapy est très bien aussi, j’en avais considéré l’utilisation également mais je n’avais pas besoin de toutes les fonctionnalités de plus haut niveau qu’il offrait. Néanmoins pour du scraping "at scale" je pense que Scrapy serait plus simple à mettre en oeuvre.

Pour vos soucis d’erreurs 429, j’ai dû gérer des délais entre les requêtes en effet. Certains sites affichent les seuils tolérés, généralement bien cachés dans un coin de la documentation pour développeurs, alors que pour d’autres il faut y aller en tâtonnant… Pour Scrapy il y a l’option download_delay, par exemple.

Une astuce que j’ai utilisée consiste à gérer mon pipeline de la manière suivante :
- télécharger le HTML et le mettre immédiatement en cache (fichier local, en mémoire dans Redis ou Memcache, plein de choses sont possibles - l’important est d’avoir le HTML brut immédiatement accessible, pour qu’un échec de parsing ne déclenche pas une nouvelle requête HTTP et ne crame notre quota de requêtes inutilement)
- travailler ensuite à partir de ce cache local : parser le HTML, détecter les modifications éventuelles et les pousser dans l’étape suivante
- enfin on vérifie la cohérence des données obtenues, et on les enregistre de manière pérenne (Postgresql, dans mon cas)
On peut très bien imaginer un système évènementiel pour chaque étape, via un système pub/sub (Redis, RabbitMQ, ZMQ…) chaque module agit alors de manière autonome et le suivant ne se déclenche que lorsqu’il a du travail à faire. Ainsi il n’est pas très grave de prendre une 429 : on retente simplement la requête après une durée aléatoire et notre pipeline reste fonctionnel, de plus ce design est très simple à paralléliser sur plusieurs machines ensuite.

Tkinter n’est que le framework graphique pour gérer l’interface "lourde" (fenêtres, widgets), on pourrait utiliser autre chose comme GTK+ ou Qt. Les graphiques sont pour leur part rendus par Matplotlib, sur laquelle s’appuie Seaborn. Seaborn est de plus haut niveau que Matplotlib et permet de faire des graphiques intéressants beaucoup plus rapidement, en particulier pour de l’analyse/exploration rapide de données, c’est un excellent choix.

D’ailleurs si votre but est simplement de tester rapidement une idée ou d’explorer/manipuler vos données sans concevoir une interface graphique "lourde" dédiée (ce qui serait en effet une perte de temps), je vous conseille de tester Jupyter Notebook : ça ouvre un environnement Python accessible en local via votre navigateur, et vous permet de manipuler le code et les données de manière simple et conviviale, avec les graphiques qui apparaissent directement dans le navigateur, potentiellement de manière interactive si vous le configurez pour.

Voici un exemple simple, datant des premiers pas de Prolix :

Chaque cellule peut être éditée puis réexécutée indépendamment des autres, c’est très pratique pour le prototypage et l’exploration de données. Il est ensuite aisé de réintégrer le code dans des scripts autonomes pour industrialiser le déploiement.

N’hésitez pas à nous faire un retour de votre avancement, ça intéressera sûrement du monde ici, moi le premier !

Bonjour !

Swingueur a écrit :

Urlib ne fonctionne pas ou alors j’ai trouvé des scripts sur internet assez complexes

Regardez plutôt la librairie requests, qui fournit une interface bien plus simple/logique que celle d’urllib.

Swingueur a écrit :

Ensuite, il faudrait bosser le parsing de CSV

Idem, jetez un oeil à la librairie pandas. Tout ceci a déjà été évoqué dans la file, y compris les scrapers

Et surtout, utilisez une version récente de Python. Le minimum vital étant 3.6 de nos jours.

Pour la base vous avez l’embarras du choix, à voir selon vos besoins (relationnelle classique, nosql/full text, simple cache… sans doute les trois, d’ailleurs).

Bon courage pour votre projet, cela me fait penser que je dois reprendre les miens…

MasterNag a écrit :

- Cela signifie que vous générez toujours un fichier du même nom pour chaque action/indice ?
- Les commits dans git sont-ils fait automatiquement par script Python une fois les fichiers importés ?

Tout dépend de votre but : le mien était de pouvoir tester, debugger et valider simplement mes parsers, donc le plus simple était de générer un CSV par jour (avec la date dans le nom du fichier) et de programmer les parsers pour écrire dans les bons fichiers (CSV, JSON et même XML selon les sources). Dans la même veine, les commits sont manuels : je balaye rapidement les diffs lors du commit pour repérer les erreurs éventuelles, et corriger le cas échéant (ce que je fais aussi lorsque je commit du code, ça permet souvent de repérer les dernières coquilles).

Ainsi en cas de mise à jour du parser, que ce soit à case d’une modification dans le format d’entrée (un XML qui devient du JSON, du HTML ou un PDF qui change, etc) ou d’une lib utilisée qui aurait été mise à jour, je peux effacer mes csv et les regénérer à partir des fichiers gardés en cache : si git diff me montre des différences, c’est que j’ai introduit une régression quelque part. Vue la complexité de certains parsers, il est toujours utile d’avoir ce filet de sécurité.

Un exemple qui me vient en tête est la différente entre "10 000.00" (europe) et "10,000.00" (usa), j’ai aussi croisé du "10.000,00" et du "10 000,00" donc pour parser ça dans tous les cas sans erreur, il faut un peu d’heuristiques… et des tests unitaires. J’ai également des contraintes au niveau de la base de données pour qu’un nombre invalide soit détecté en dernier ressort, et elles se sont déjà déclenchées par le passé sur du code que je pensais correct… on n’est jamais trop prudent !

MasterNag a écrit :

- Une fois le fichier importé quel est l’intérêt de le conserver via git ?
- Est-ce uniquement en tant que backup (et dans ce cas là un dump périodique de la base ne serait-il pas suffisant ?) ou avez-vous besoin de les réutiliser parfois ?

Il m’arrive de réimporter toute la base de données de zéro ou partiellement à partir des fichiers parsés, car je ne suis pas toujours sur le même ordinateur. J’ai bien un dump pour les sauvegardes, mais cela ne concerne qu’une seule table (celles des dividendes, dont l’import est assez complexe en raison des changements d’isin/raisons sociales).

Voilà pour ma méthode, à vous de trouver celle qui vous convient Cela peut paraître trop précautionneux, mais il vaut mieux s’assurer que les données qu’on manipule et sur lesquelles on base nos prédictions soient correctes.