Pony was not developed for async usage, and it may be tricky to use it correctly in an async environment. However, if only part of your application is async, you will be fine if you stick to these two rules:
Je suis très curieux ce qu'ils semblent faire me semble demander à manipuler l'AST de python depuis python lui-même, je ne savais pas que python pouvait faire ça
c for c in ... c'est une "expression générateur" en Python :
>>> (i for i in [])
<generator object <genexpr> at 0x…>
Donc select(c for c in ...) passe un objet de type générateur à la fonction select().
En survolant le code source, ils décompilent le code du générateur (la stdlib de Python fournit les outils pour faire cela) et ensuite réécrit l'AST pour recompiler ça en SQL.
Le générateur n'est jamais exécuté directement du coup.
On a même le module dis qui ne semble pas utilisé par contre.
En regardant tout ça d'un peu plus près, cela me semble très spécifique à CPython. Quid de PyPy, Jython (JVM), et autres implémentations ?
Je n'irai pas jusqu'à dire que c'est un gros hack, car cela exploite les détails d'implémentations "interne" de CPython, mais je n'irai pas jusqu'à dire que c'est "prévu". C'est "permis" me semble un bon compromis.
En tout cas, si je comprends bien le code, il vont en chier pour assurer la compatibilité lors des montées de versions de l'implémentation, car rien ne garantie qu'elle ne bougera pas.
# Autre nommage
Posté par Misc (site web personnel) . Évalué à 6.
Je suis triste, le projet n'est pas parti sur PonyoRM sur la falaise comme thème du site web.
[^] # Antériorité
Posté par Glandos . Évalué à 3.
Ah oui, mais Ponyo semble avoir été créé vers 2006 (pour une sortie cinéma en 2008), alors que PonyORM a 18 ans d'après son historique git.
Forcément, c'est l'autre qui a copié l'un !
# SQLAlchemy
Posté par ff9097 . Évalué à 2.
Une comparaison avec SQLAlchemy ? Qui a plutôt bonne réputation dans le domaine
[^] # Re: SQLAlchemy
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Sur la page d'accueil, presqu'au milieu à droite, on lit :
En gros, de ma compréhension, on a ceci avec PonyORM
Cela ressemblerait, grosso-modo, sous SQLAlchemy à :
Et dans l'exemple sur la page ce serait quelque chose comme ? (j'ai un petit doute)
https://docs.ponyorm.org/queries.html
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: SQLAlchemy
Posté par ff9097 . Évalué à 2.
Je viens de voir qu'il n'y a pas de support de l'async IO ce qui fait un peu tâche
[^] # Re: SQLAlchemy
Posté par ted (site web personnel) . Évalué à 3.
C'est de ça que tu parles?
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: SQLAlchemy
Posté par ff9097 . Évalué à 3.
https://docs.ponyorm.org/integration_with_fastapi.html?highlight=async#async-and-db-session
# Curieux
Posté par barmic 🦦 . Évalué à 2.
Je suis très curieux ce qu'ils semblent faire me semble demander à manipuler l'AST de python depuis python lui-même, je ne savais pas que python pouvait faire ça
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Curieux
Posté par David Delassus (site web personnel) . Évalué à 6. Dernière modification le 28 septembre 2023 à 17:02.
c for c in ...
c'est une "expression générateur" en Python :Donc
select(c for c in ...)
passe un objet de type générateur à la fonctionselect()
.En survolant le code source, ils décompilent le code du générateur (la stdlib de Python fournit les outils pour faire cela) et ensuite réécrit l'AST pour recompiler ça en SQL.
Le générateur n'est jamais exécuté directement du coup.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Curieux
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Oui, l'idée de leur ORM est de pouvoir utiliser directement les itérateurs et de ne pas causer SQL directement (ça me perturbe un peu parce-que je parle assez bien l'autre langue d'une part et que je n'ai pas l'esprit très pythonic d'autre part.) Le principe de la traduction/transcription a été décrit en détail sur SO en 2013 par un des auteurs…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Curieux
Posté par barmic 🦦 . Évalué à 2.
OK je comprends mieux, c'est un gros hack (comme ça en donne l'impression) ou c'est relativement prévu par les développeurs de python ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Curieux
Posté par David Delassus (site web personnel) . Évalué à 3.
On va dire que c'est permis par CPython :
decompile(x)
de ponyorm, notamment la ligne :codeobject = x.gi_frame.f_code
opcode
de CPythonast
de PythonOn a même le module
dis
qui ne semble pas utilisé par contre.En regardant tout ça d'un peu plus près, cela me semble très spécifique à CPython. Quid de PyPy, Jython (JVM), et autres implémentations ?
Je n'irai pas jusqu'à dire que c'est un gros hack, car cela exploite les détails d'implémentations "interne" de CPython, mais je n'irai pas jusqu'à dire que c'est "prévu". C'est "permis" me semble un bon compromis.
En tout cas, si je comprends bien le code, il vont en chier pour assurer la compatibilité lors des montées de versions de l'implémentation, car rien ne garantie qu'elle ne bougera pas.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.