1 Introduction
Une partie essentielle du travail du data scientist consiste à synthétiser l’information que contient ses jeux de données afin de distinguer ce qui relève du signal, sur lequel il pourra se concentrer, et ce qui relève du bruit inhérent à tout jeu de données. Dans le travail du data scientist, lors d’une phase exploratoire, il y a donc un aller-retour constant entre information synthétique et jeu de données désagrégé. Il est ainsi essentiel de savoir synthétiser l’information dans un jeu de données avant d’en saisir la structure, cette dernière pouvant ensuite guider les exploitations ultérieures, pour une phase de modélisation ou de correction de données (détection d’anomalies ou de mauvaises remontées de données).
Nous avons déjà exploré une partie essentielle de ce travail,
à savoir la construction de statistiques descriptives pertinentes
et fiables. Néanmoins, si on se contentait de présenter l’information
en utilisant des sorties brutes issues du combo groupby
et agg
sur un DataFrame Pandas
, notre connaissance des données serait assez
limitée. La mise en oeuvre de tableaux stylisés à partir
de great tables
constituait déjà un progrès dans cette démarche mais, en vérité,
notre cerveau se représente l’information de manière beaucoup plus intuitive
par le biais de visualisations graphiques simples que dans un tableau.
1.1 La visualisation des données, une part essentiel du travail de communication
En tant qu’humains, nos capacités cognitives étant limitées, nous ne pouvons appréhender qu’une information limitée là où l’ordinateur est capable de traiter de grands volumes d’information. En tant que data scientist, cela signifie qu’utiliser nos compétences informatiques et statistiques pour obtenir des représentations synthétiques de nos nombreux jeux de données est essentiel pour être en mesure de répondre à nos besoins opérationnels ou scientifiques. L’ensemble des méthodes et des outils qui constituent la boîte à outil des data scientists vise à simplifier l’appréhension puis l’exploitation de jeux de données dont le volume dépasse nos capacités cognitives.
Ceci nous entraîne vers la question de la visualisation des données, un ensemble d’outils et de principes pour représenter de manière synthétique des faits stylisés ou contextualiser une donnée individuelle. La visualisation de données est l’art et la science de représenter visuellement des informations complexes et abstraites à l’aide d’éléments visuels. Son objectif principal est de synthétiser l’information présente dans un ensemble de données afin de faciliter la compréhension des enjeux de celle-ci pour une analyse ultérieure. La visualisation de données permet, entre autres, de mettre en évidence des tendances, des corrélations ou des anomalies qui pourraient être difficiles voire impossibles à saisir simplement en examinant des données brutes, ces dernières nécessitant une certaine mise en contexte pour porter du sens.
La visualisation de données joue un rôle crucial dans le processus d’analyse de données en fournissant des moyens visuels pour explorer, interpréter et communiquer des informations. Elle facilite la communication entre experts de la données, décideurs et grand public, en permettant aux derniers de bénéficier du travail rigoureux des premiers pour donner sens aux données sans la connaissance des subtilités conceptuelles qui ont permis de synthétiser l’information contenue dans celle-ci.
1.2 La place de la visualisation dans le processus de valorisation de la donnée
La visualisation des données n’est pas restreinte à la phase finale d’un projet, c’est à dire à la phase de communication de résultats à une audience qui n’a pas accès à la donnée ou n’a pas les moyens de la valoriser. La visualisation intervient à toutes les étapes du processus de valorisation de la donnée. Il s’agit d’ailleurs d’un travail essentiel pour trouver comment basculer de l’enregistrement, un instantané d’un phénomène, à une donnée, un enregistrement qui a une valeur parce qu’il porte une information en tant que telle ou lorsqu’il est combiné avec d’autres enregistrements.
Le travail quotidien du data scientist consiste à regarder un jeu de données sous toutes ses coutures pour identifier les axes prioritaires d’extraction de valeur. Savoir rapidement quelles statistiques représenter, et comment, est essentiel pour gagner du temps sur cette partie exploratoire. Il s’agit principalement d’un travail de communication envers soi-même qui peut se permettre d’être brouillon car il s’agit de dégrossir le travail avant de polir certains angles. L’enjeu à ce niveau du processus est de ne pas manquer une dimension qui pourrait être porteuse de valeur.
Le travail de communication réellement chronophage intervient plutôt
lorsqu’on communique à une audience ayant un accès limité à des
données, ne connaissant pas bien les sources, ayant
un temps d’attention limité
ou n’ayant pas des compétences quantitatives. Ces
publics ne peuvent se satisfaire d’une sortie brute comme
un DataFrame dans un notebook ou un graphique produit
en quelques secondes avec la méthode plot
de Pandas
.
Il convient de s’adapter à leurs attentes, qui évoluent,
et aux outils qu’ils connaissent, d’où la place de plus en
plus importante prise par les sites
web de data visualisations.
2 Communiquer, une ouverture au data storytelling
La visualisation de données a ainsi une place à part dans l’ensemble des techniques de la data science. Elle intervient à tous les stades du processus de production de la donnée, de l’amont (analyse exploratoire) à l’aval (restitution à des publics multiples) et peut, si elle est bien construite, permettre de saisir de manière intuitive la structure des données ou les enjeux de son analyse.
Art de la synthèse, la visualisation de données
est également l’art de raconter une histoire et
peut même, lorsqu’elle est bien construite, prétendre
au rang de production artistique.
La dataviz est un métier en soi dont on trouve de
plus en plus de praticiens dans les titres de presse
ou dans des entreprises
spécialisées (Datawrapper
par exemple).
Sans prétendre construire des visualisations aussi riches que celles des spécialistes, tout data scientist se doit d’être en mesure de pouvoir produire rapidement quelques visualisations permettant de synthétiser l’information présente dans les jeux de données à sa disposition. Une visualisation claire et lisible tout en restant simple peut être meilleure qu’un discours pour faire passer un message.
De même qu’un discours, une visualisation est une communication pour laquelle un locuteur - la personne construisant la visualisation - cherche à transmettre une information à un récepteur - éventuellement la même personne que le locuteur puisqu’une visualisation peut être construite pour soi-même dans une analyse exploratoire. Il n’est donc pas surprenant qu’à l’époque où la sémiologie occupait une part importante dans les débats intellectuels, notamment autour de la figure de Roland Barthes, le concept de sémiologie graphique ait émergé autour de la personne de Jacques Bertin (Bertin 1967; Palsky 2017). Cette approche permet de réfléchir sur la pertinence des techniques mises en oeuvre pour transmettre un message graphique et de nombreuses visualisations, si elles suivaient quelques-unes de ces règles, pourraient être améliorées à peu de frais.
Eric Mauvière, statisticien français héritier
de l’école de la sémiologie graphique de Bertin,
propose d’excellents contenus sur le sujet. Certaines
des présentations qu’il a pu faire, notamment
celle pour le SSPHub
présentées dans la Note 2.1
devraient être visionnées dans toutes les formations
de data science tant elles évoquent les nombreux
écueils rencontrés par les data scientists.
3 Communiquer, une ouverture à la mise à disposition d’applications
L’objectif de ce cours est d’introduire aux principaux outils et à la démarche que doivent adopter les data scientists face à divers jeux de données. Il devient néanmoins de plus en plus commun pour les data scientists de développer et mettre à disposition des applications interactives proposant un certain nombre d’explorations et de visualisations automatisées de données. Il s’agit d’enjeux plus avancés que ce cours mais qui constituent souvent un point d’entrée vers la data science pour des publics proches des data scientists, notamment les data engineers, les data analysts ou les statisticiens.
Nous évoquerons certains des outils privilégiés pour faire
cela, notamment les écosystèmes liés aux applications web
et aux outils Javascript
. Ce besoin, devenu assez standard
pour les data scientists, fait la passerelle avec la mise
en production,
l’enjeu principal d’un cours de 3e année de l’ENSAE
construit par Romain Avouac
et moi-même (site web du cours ensae-reproductibilite.github.io/). Le présent site web, par exemple, est construit
selon ce principe grâce à des outils permettant d’exécuter de manière
reproductible du Python
sur des serveurs standardisés et ensuite
mettre à disposition ce code par le biais d’un site web.
4 L’écosystème Python
Pour revenir à notre cours,
nous présenterons dans cette partie quelques librairies
et visualisations basiques en Python
permettant de
partir sur de bonnes bases. Les ressources pour
approfondir et progresser dans l’art de la visualisation
ne manquent pas, comme cet ouvrage (Wilke 2019).
4.1 Les packages de visualisations de données
L’écosystème Python
pour la visualisation de données est très riche et
très éclaté.
Il est
possible de consacrer des livres entiers à celui-ci (Dale 2022).
Python
propose
de nombreuses librairies pour produire de manière rapide et relativement
simple des visualisations de données1.
Les librairies graphiques se distinguent principalement en deux familles:
- Les librairies de représentations figées. Celles-ci ont plutôt vocation à être intégrées
dans des publications figées type PDF ou documents texte. Nous présenterons
principalement
Matplotlib
etSeaborn
mais il en existe d’autres, en pleine émergence, commePlotnine
, l’adaptation deggplot2
à l’écosystèmePython
. - Les librairies de représentations réactives. Celles-ci sont adaptées à des représentations
web et offrent la possibilité aux lecteurs d’agir sur la représentation graphique affichée.
Les librairies qui proposent ces fonctionnalités reposent généralement sur
JavaScript
, l’écosystème du développement web, pour lequel elles offrent un point d’entrée viaPython
. Nous évoquerons principalementPlotly
etFolium
dans cette famille mais il existe de nombreux autres frameworks dans ce domaine2.
Il est tout à fait possible
de faire des visualisations sophistiquées avec
une chaine de bout en bout Python
puisqu’il s’agit d’un langage couteau-suisse
dont l’écosystème est très
riche. Néanmoins, Python
n’est pas la panacée et il peut parfois
être utile, pour obtenir un produit fini parfaitement poli,
de finaliser le travail avec d’autres langages, comme Javascript
pour les visualisations réactives ou QGIS
pour le
travail cartographique. Ce cours donnera les outils minimums
pour faire un travail rapide et plaisant mais le diable étant dans
les détails, il ne faut pas s’arcbouter à vouloir utiliser
Python
pour tout et n’importe quoi.
Dans le domaine de la visualisation, ce cours adopte le parti pris d’explorer quelques librairies centrales à partir d’un nombre restreint d’exemples en répliquant des graphiques qu’on peut trouver sur le site d’open data de la mairie de Paris. La meilleure école pour la visualisation restant la pratique sur des jeux de données, il est recommandé d’explorer la richesse de l’écosystème de l’open data pour expérimenter des visualisations.
4.2 Les applications de visualisation
Cette partie du cours se focalise sur des représentations synthétiques simples. Elle n’évoque pas (encore ?) la construction d’applications de visualisation de données où un ensemble de graphiques se mettent à jour de manière synchrone en fonction d’actions d’utilisateurs.
Ceci dépasse en effet le cadre d’un cours d’introduction car construire
ces applications
impliquent
de maîtriser des concepts plus complexes comme l’interaction entre une page
web et un serveur, d’avoir des rudiments de connaissance en Linux
, etc.
Les concepts nécessaires à la compréhension de ces outils sont au coeur
du cours de 3e année “Mise en production de projets de data science”
que Romain Avouac donnons en 3e année d’ENSAE.
Néanmoins, comme la valorisation de données sous une forme applicative est très commune, il il est utile a minima d’évoquer la dualité entre sites statiques et applications dynamiques afin de donner les bons gestes et pointer vers les outils adéquat. Dans le monde de l’applicatif, il est important de distinguer le front (la page visible par les utilisateurs de l’application) du back office (le moteur qui effectue des actions en fonction des paramètres choisis par l’utilisateur de la page).
Il existe principalement deux paradigmes pour faire
interagir ces deux éléments. La distinction principale entre ces deux approches est qu’elles s’appuient sur des serveurs différents. Un site statique repose sur un serveur web là où Streamlit
s’appuie sur serveur classique en backend. La différence principale entre ces deux types de serveurs réside principalement dans leur fonction et leur utilisation:
- Un serveur web est spécifiquement conçu pour stocker, traiter et livrer des pages web (le front) aux clients. Cela inclut des fichiers HTML, CSS, JavaScript, images, etc. Les serveurs web écoutent les requêtes HTTP/HTTPS provenant des navigateurs des utilisateurs et y répondent en envoyant les données demandées. Cela n’empêche pas d’avoir des étapes complexes de valorisation de données, ni de la réactivité en embarquant du
Javascript
dans l’application mais les étapes de traitement enPython
sont faites en amont de la mise à disposition de l’application. Pour les utilisateurs dePython
, il existe plusieurs constructeurs de sites statiques avant une mise à disposition par le biais d’un hébergement surGithub Pages
. Les deux écosystèmes les plus communs sontQuarto Markdown
etDjango
, le premier étant plus simple d’usage et de maintenance que le second. Ce site, par exemple, est construit grâce àQuarto
ce qui assure la reproductibilité des exemples présentés et une mise en forme ergonomique et paramétrable des résultats.
- Un serveur backend classique est conçu pour effectuer des opérations en réponse à un front, en l’occurrence une page web. Dans le contexte d’une application construite avec
Python
, il s’agit d’un serveur avec l’environnementPython
ad hoc pour exécuter le code nécessaire à répondre à toute action d’un utilisateur de l’application. Le code est exécuté à la volée et non une fois pour toute comme dans l’approche précédente. Il s’agit donc d’un paradigme pouvant permettre plus de complexité applicative mais représentant un défi supplémentaire lors de la phase de mise en production. Dans l’écosystèmePython
, les deux principaux outils permettant de construire de telles applications sontStreamlit
etDash
, le premier étant plus rapide à mettre en oeuvre que le second. Plus récemment, l’écosystème équivalent dominant enR
,Shiny
a été adapté enPython
parPosit
.
tkinter
?
Les écosystèmes présentés ci-dessus pour les applications réactives sont des frameworks web. Ils se distinguent des clients lourds comme tkinter
,
l’outil historique pour faire des interfaces graphiques. Outre l’aspect plus rudimentaire des
interfaces tkinter
par rapport à celles de Streamlit
, Dash
ou Shiny
, il existe
des raisons fortes pour privilégier ces derniers à tkinter
.
Ce dernier est un client lourd. Autrement dit, il est adhérent à un système d’exploitation
et à des installations de packages en amont du fonctionnement de l’interface.
Il est bien sûr possible de rendre portable celle-ci mais, comme cela est développé
dans le cours de mise en production,
il y a de nombreuses raisons pour lesquelles cette approche peut provoquer des erreurs
ou des bugs inattendus. Les frameworks web présentent l’intérêt de simplifier
cette mise à disposition en dissociant le front (des pages HTML et du CSS) du back (du
code Python
). Ils se sont donc imposés naturellement même si on retrouve encore beaucoup
de ressources en ligne datées sur le développement d’applications avec tkinter
.
En ce qui concerne la construction d’applications, le premier réflexe
à avoir est: “ai-je besoin de faire une application réactive ou un site
statique ne suffit-il pas ?”. Ce dernier étant beaucoup plus facile à
mettre en oeuvre et ayant une charge de maintenance minimale, c’est souvent
un choix rationnel. S’il devient complexe de faire un site statique, par
exemple parce qu’ils impliquent des calculs sophistiqués qu’il serait
complexe de mettre en oeuvre sans compétences JavaScript
, on peut alors
se poser la question de la séparation entre front et back
en reportant les calculs vers une API, construite par exemple par le biais de FastAPI
. Il s’agit, par exemple, d’une méthode pratique pour mettre
à disposition un modèle de machine learning comme le
dernier chapitre
de la partie modélisation l’évoquera. Si la mise en oeuvre d’une API
est compliquée ou bien est un bazooka pour tuer une mouche,
alors on pourra aller vers une application réactive du type
de Streamlit
.
Encore une fois, la construction d’une application fait
appel à des concepts qui dépassent
un niveau introductif en Python
. Avoir conscience des bons réflexes
peut néanmoins faire économiser un temps non négligeable en évitant de patauger
dans la semoule à cause d’un mauvais choix initial.
4.3 Résumé de cette partie
Pour en revenir au contenu de cette partie après cet aparté, celle-ci est divisée en deux et chaque chapitre est lui-même dual, selon qu’on s’intéresse aux représentations figées ou dynamiques :
- Dans un premier temps, nous évoquerons des
représentations graphiques standards (histogrammes, diagrammes
en barre…) pour synthétiser certaines informations quantitatives ;
- Les représentations fixes reposeront sur
Pandas
,Matplotlib
etSeaborn
- Les graphiques réactifs s’appuieront sur
Plotly
- Les représentations fixes reposeront sur
- Dans un deuxième temps, nous présenterons les représentations
cartographiques:
- Les cartes figées à partir de
Geopandas
ou deplotnine
- Les cartes réactives avec
Folium
(adaptationPython
de la librairieLeaflet.js
)
- Les cartes figées à partir de
4.4 Références utiles
La visualisation de données est un art qui s’apprend, au début, principalement par la pratique. Néanmoins, il n’est pas évident de produire des visualisations lisibles et ergonomiques et il est utile de s’inspirer d’exemples de spécialistes (les grands titres de presse disposent d’excellentes visualisations).
Voici quelques ressources utiles sur ces sujets :
Datawrapper
propose un excellent blog sur les bonnes pratiques de visualisation, notamment avec les articles de Lisa Charlotte Muth. Je recommande notamment cet article sur les couleurs ou celui-ci sur les textes ;- Le blog d’Eric Mauvière ;
- “La Sémiologie graphique de Jacques Bertin a cinquante ans” ;
- Les visualisations trending sur
Observable
; - Le New York Times (les rois de la dataviz) revient tous les ans sur les meilleures visualisations de l’année dans la veine du data scrollytelling. Voir par exemple la rétrospective de l’année 2022.
Streamlit
ou Dash
Outre le cours de 3e année de l’ENSAE,
le lab de data science de l’Insee a construit de nombreux tutoriels
pour s’appropier les écosystèmes d’applications réactives en Python
qui
sont l’un des produits les plus attractifs de l’écosystème Python
.
Voici par exemple un tutoriel 101 très détaillé sur Streamlit
permettant de créer une application type Yuka
sur les données de l’openfoodfacts
. Un autre tutoriel pas à pas construit par l’Insee
est consacré à streamlit
et vise à proposer la construction d’un tableau de bord du trafic aérien.
Et quelques références supplémentaires, citées dans cette introduction :
Informations additionnelles
environment files have been tested on.
Latest built version: 2024-12-07
Python version used:
'3.12.6 | packaged by conda-forge | (main, Sep 30 2024, 18:08:52) [GCC 13.3.0]'
Package | Version |
---|---|
affine | 2.4.0 |
aiobotocore | 2.15.1 |
aiohappyeyeballs | 2.4.3 |
aiohttp | 3.10.8 |
aioitertools | 0.12.0 |
aiosignal | 1.3.1 |
alembic | 1.13.3 |
altair | 5.4.1 |
aniso8601 | 9.0.1 |
annotated-types | 0.7.0 |
anyio | 4.7.0 |
appdirs | 1.4.4 |
archspec | 0.2.3 |
asttokens | 2.4.1 |
attrs | 24.2.0 |
babel | 2.16.0 |
bcrypt | 4.2.0 |
beautifulsoup4 | 4.12.3 |
black | 24.8.0 |
blinker | 1.8.2 |
blis | 0.7.11 |
bokeh | 3.5.2 |
boltons | 24.0.0 |
boto3 | 1.35.23 |
botocore | 1.35.23 |
branca | 0.7.2 |
Brotli | 1.1.0 |
cachetools | 5.5.0 |
cartiflette | 0.0.2 |
Cartopy | 0.24.1 |
catalogue | 2.0.10 |
cattrs | 24.1.2 |
certifi | 2024.8.30 |
cffi | 1.17.1 |
charset-normalizer | 3.3.2 |
click | 8.1.7 |
click-plugins | 1.1.1 |
cligj | 0.7.2 |
cloudpathlib | 0.20.0 |
cloudpickle | 3.0.0 |
colorama | 0.4.6 |
comm | 0.2.2 |
commonmark | 0.9.1 |
conda | 24.9.1 |
conda-libmamba-solver | 24.7.0 |
conda-package-handling | 2.3.0 |
conda_package_streaming | 0.10.0 |
confection | 0.1.5 |
contextily | 1.6.2 |
contourpy | 1.3.0 |
cryptography | 43.0.1 |
cycler | 0.12.1 |
cymem | 2.0.10 |
cytoolz | 1.0.0 |
dask | 2024.9.1 |
dask-expr | 1.1.15 |
databricks-sdk | 0.33.0 |
dataclasses-json | 0.6.7 |
debugpy | 1.8.6 |
decorator | 5.1.1 |
Deprecated | 1.2.14 |
diskcache | 5.6.3 |
distributed | 2024.9.1 |
distro | 1.9.0 |
docker | 7.1.0 |
duckdb | 0.10.1 |
en-core-web-sm | 3.7.1 |
entrypoints | 0.4 |
et_xmlfile | 2.0.0 |
exceptiongroup | 1.2.2 |
executing | 2.1.0 |
fastexcel | 0.11.6 |
fastjsonschema | 2.21.1 |
fiona | 1.10.1 |
Flask | 3.0.3 |
folium | 0.17.0 |
fontawesomefree | 6.6.0 |
fonttools | 4.54.1 |
frozendict | 2.4.4 |
frozenlist | 1.4.1 |
fsspec | 2023.12.2 |
gensim | 4.3.2 |
geographiclib | 2.0 |
geopandas | 1.0.1 |
geoplot | 0.5.1 |
geopy | 2.4.1 |
gitdb | 4.0.11 |
GitPython | 3.1.43 |
google-auth | 2.35.0 |
graphene | 3.3 |
graphql-core | 3.2.4 |
graphql-relay | 3.2.0 |
graphviz | 0.20.3 |
great-tables | 0.12.0 |
greenlet | 3.1.1 |
gunicorn | 22.0.0 |
h11 | 0.14.0 |
h2 | 4.1.0 |
hpack | 4.0.0 |
htmltools | 0.6.0 |
httpcore | 1.0.7 |
httpx | 0.28.1 |
httpx-sse | 0.4.0 |
hyperframe | 6.0.1 |
idna | 3.10 |
imageio | 2.36.1 |
importlib_metadata | 8.5.0 |
importlib_resources | 6.4.5 |
inflate64 | 1.0.0 |
ipykernel | 6.29.5 |
ipython | 8.28.0 |
itsdangerous | 2.2.0 |
jedi | 0.19.1 |
Jinja2 | 3.1.4 |
jmespath | 1.0.1 |
joblib | 1.4.2 |
jsonpatch | 1.33 |
jsonpointer | 3.0.0 |
jsonschema | 4.23.0 |
jsonschema-specifications | 2024.10.1 |
jupyter-cache | 1.0.0 |
jupyter_client | 8.6.3 |
jupyter_core | 5.7.2 |
kaleido | 0.2.1 |
kiwisolver | 1.4.7 |
langchain | 0.3.10 |
langchain-community | 0.3.9 |
langchain-core | 0.3.22 |
langchain-text-splitters | 0.3.2 |
langcodes | 3.5.0 |
langsmith | 0.1.147 |
language_data | 1.3.0 |
lazy_loader | 0.4 |
libmambapy | 1.5.9 |
locket | 1.0.0 |
lxml | 5.3.0 |
lz4 | 4.3.3 |
Mako | 1.3.5 |
mamba | 1.5.9 |
mapclassify | 2.8.1 |
marisa-trie | 1.2.1 |
Markdown | 3.6 |
markdown-it-py | 3.0.0 |
MarkupSafe | 2.1.5 |
marshmallow | 3.23.1 |
matplotlib | 3.9.2 |
matplotlib-inline | 0.1.7 |
mdurl | 0.1.2 |
menuinst | 2.1.2 |
mercantile | 1.2.1 |
mizani | 0.11.4 |
mlflow | 2.16.2 |
mlflow-skinny | 2.16.2 |
msgpack | 1.1.0 |
multidict | 6.1.0 |
multivolumefile | 0.2.3 |
munkres | 1.1.4 |
murmurhash | 1.0.11 |
mypy-extensions | 1.0.0 |
narwhals | 1.16.0 |
nbclient | 0.10.0 |
nbformat | 5.10.4 |
nest_asyncio | 1.6.0 |
networkx | 3.3 |
nltk | 3.9.1 |
numpy | 1.26.4 |
opencv-python-headless | 4.10.0.84 |
openpyxl | 3.1.5 |
opentelemetry-api | 1.16.0 |
opentelemetry-sdk | 1.16.0 |
opentelemetry-semantic-conventions | 0.37b0 |
orjson | 3.10.12 |
OWSLib | 0.28.1 |
packaging | 24.1 |
pandas | 2.2.3 |
paramiko | 3.5.0 |
parso | 0.8.4 |
partd | 1.4.2 |
pathspec | 0.12.1 |
patsy | 0.5.6 |
Pebble | 5.1.0 |
pexpect | 4.9.0 |
pickleshare | 0.7.5 |
pillow | 10.4.0 |
pip | 24.2 |
platformdirs | 4.3.6 |
plotly | 5.24.1 |
plotnine | 0.13.6 |
pluggy | 1.5.0 |
polars | 1.8.2 |
preshed | 3.0.9 |
prometheus_client | 0.21.0 |
prometheus_flask_exporter | 0.23.1 |
prompt_toolkit | 3.0.48 |
protobuf | 4.25.3 |
psutil | 6.0.0 |
ptyprocess | 0.7.0 |
pure_eval | 0.2.3 |
py7zr | 0.20.8 |
pyarrow | 17.0.0 |
pyarrow-hotfix | 0.6 |
pyasn1 | 0.6.1 |
pyasn1_modules | 0.4.1 |
pybcj | 1.0.2 |
pycosat | 0.6.6 |
pycparser | 2.22 |
pycryptodomex | 3.21.0 |
pydantic | 2.10.3 |
pydantic_core | 2.27.1 |
pydantic-settings | 2.6.1 |
Pygments | 2.18.0 |
PyNaCl | 1.5.0 |
pynsee | 0.1.8 |
pyogrio | 0.10.0 |
pyOpenSSL | 24.2.1 |
pyparsing | 3.1.4 |
pyppmd | 1.1.0 |
pyproj | 3.7.0 |
pyshp | 2.3.1 |
PySocks | 1.7.1 |
python-dateutil | 2.9.0 |
python-dotenv | 1.0.1 |
python-magic | 0.4.27 |
pytz | 2024.1 |
pyu2f | 0.1.5 |
pywaffle | 1.1.1 |
PyYAML | 6.0.2 |
pyzmq | 26.2.0 |
pyzstd | 0.16.2 |
querystring_parser | 1.2.4 |
rasterio | 1.4.3 |
referencing | 0.35.1 |
regex | 2024.9.11 |
requests | 2.32.3 |
requests-cache | 1.2.1 |
requests-toolbelt | 1.0.0 |
retrying | 1.3.4 |
rich | 13.9.4 |
rpds-py | 0.22.3 |
rsa | 4.9 |
ruamel.yaml | 0.18.6 |
ruamel.yaml.clib | 0.2.8 |
s3fs | 2023.12.2 |
s3transfer | 0.10.2 |
scikit-image | 0.24.0 |
scikit-learn | 1.5.2 |
scipy | 1.13.0 |
seaborn | 0.13.2 |
setuptools | 74.1.2 |
shapely | 2.0.6 |
shellingham | 1.5.4 |
six | 1.16.0 |
smart-open | 7.0.5 |
smmap | 5.0.0 |
sniffio | 1.3.1 |
sortedcontainers | 2.4.0 |
soupsieve | 2.5 |
spacy | 3.7.5 |
spacy-legacy | 3.0.12 |
spacy-loggers | 1.0.5 |
SQLAlchemy | 2.0.35 |
sqlparse | 0.5.1 |
srsly | 2.4.8 |
stack-data | 0.6.2 |
statsmodels | 0.14.4 |
tabulate | 0.9.0 |
tblib | 3.0.0 |
tenacity | 9.0.0 |
texttable | 1.7.0 |
thinc | 8.2.5 |
threadpoolctl | 3.5.0 |
tifffile | 2024.9.20 |
toolz | 1.0.0 |
topojson | 1.9 |
tornado | 6.4.1 |
tqdm | 4.66.5 |
traitlets | 5.14.3 |
truststore | 0.9.2 |
typer | 0.15.1 |
typing_extensions | 4.12.2 |
typing-inspect | 0.9.0 |
tzdata | 2024.2 |
Unidecode | 1.3.8 |
url-normalize | 1.4.3 |
urllib3 | 1.26.20 |
wasabi | 1.1.3 |
wcwidth | 0.2.13 |
weasel | 0.4.1 |
webdriver-manager | 4.0.2 |
websocket-client | 1.8.0 |
Werkzeug | 3.0.4 |
wheel | 0.44.0 |
wordcloud | 1.9.3 |
wrapt | 1.16.0 |
xgboost | 2.1.1 |
xlrd | 2.0.1 |
xyzservices | 2024.9.0 |
yarl | 1.13.1 |
yellowbrick | 1.5 |
zict | 3.0.0 |
zipp | 3.20.2 |
zstandard | 0.23.0 |
View file history
SHA | Date | Author | Description |
---|---|---|---|
cbe6459 | 2024-11-12 07:24:15 | lgaliana | Revoir quelques abstracts |
593106f | 2024-09-21 14:39:32 | lgaliana | Abstract également |
1ebb5ee | 2024-09-21 14:23:43 | lgaliana | Translate the introduction to visualisation |
72d44dd | 2024-09-21 12:50:38 | lgaliana | Force build for pandas chapters |
d02515b | 2024-04-27 21:32:25 | Lino Galiana | Eléments sur les applis & évaluation (#495) |
005d89b | 2023-12-20 17:23:04 | Lino Galiana | Finalise l’affichage des statistiques Git (#478) |
1f23de2 | 2023-12-01 17:25:36 | Lino Galiana | Stockage des images sur S3 (#466) |
09654c7 | 2023-11-14 15:16:44 | Antoine Palazzolo | Suggestions Git & Visualisation (#449) |
8082302 | 2023-08-25 17:48:36 | Lino Galiana | Mise à jour des scripts de construction des notebooks (#395) |
3bdf3b0 | 2023-08-25 11:23:02 | Lino Galiana | Simplification de la structure 🤓 (#393) |
5d4874a | 2023-08-11 15:09:33 | Lino Galiana | Pimp les introductions des trois premières parties (#387) |
2dc82e7 | 2022-10-18 22:46:47 | Lino Galiana | Relec Kim (visualisation + API) (#302) |
8e5edba | 2022-09-02 11:59:57 | Lino Galiana | Ajoute un chapitre dask (#264) |
a4e2426 | 2022-06-16 19:34:18 | Lino Galiana | Improve style (#238) |
12965ba | 2022-05-25 15:53:27 | Lino Galiana | :launch: Bascule vers quarto (#226) |
66a5276 | 2021-11-23 16:13:20 | Lino Galiana | Relecture partie visualisation (#181) |
4cdb759 | 2021-05-12 10:37:23 | Lino Galiana | :sparkles: :star2: Nouveau thème hugo :snake: :fire: (#105) |
0a0d034 | 2021-03-26 20:16:22 | Lino Galiana | Ajout d’une section sur S3 (#97) |
5ac3cbe | 2020-09-28 18:59:24 | Lino Galiana | Continue la partie graphiques (#54) |
8ed01f4 | 2020-09-24 21:27:29 | Lino Galiana | Ajout d’une partie visualisation |
Notes de bas de page
To be honest, for a long time,
Python
was a bit less enjoyable in this regard compared toR
, which benefits from the indispensable libraryggplot2
.Not built on the grammar of graphics, the main graphical library in
Python
,Matplotlib
, is more cumbersome to use thanggplot2
.seaborn
, which we will present, simplifies graphical representation somewhat, but again, it is difficult to find something more flexible and universal thanggplot2
.The library
plotnine
aims to provide a similar implementation toggplot
forPython
users. Its development is worth following.↩︎In this regard, I highly recommend keeping up with data visualization news on the platform
Observable
, which tends to bring together the communities of dataviz specialists and data analysts. The libraryPlot
could become a new standard in the coming years, a sort of intermediate betweenggplot
andd3
.↩︎
Citation
@book{galiana2023,
author = {Galiana, Lino},
title = {Python pour la data science},
date = {2023},
url = {https://pythonds.linogaliana.fr/},
doi = {10.5281/zenodo.8229676},
langid = {fr}
}