Development #22106
Création paresseuse des variables de substitution
0%
Description
Aujourd'hui on calcule nécessairement tout et ça prend du temps, on doit pouvoir mettre en place de quoi calculer une variable uniquement quand elle est référencée.
Demandes liées
Révisions associées
Historique
Mis à jour par Frédéric Péters il y a environ 6 ans
- Lié à Development #22738: Visibilité dynamique de champs dans une page ajouté
Mis à jour par Frédéric Péters il y a presque 6 ans
- Statut changé de Nouveau à En cours
- Assigné à mis à Frédéric Péters
Je viens de pousser https://git.entrouvert.org/wcs.git/log/?h=wip/22106-lazy-variables qui assure ça; pour le moment la vue /inspect dépend encore d'une création statique/~exhaustive des variables possibles; ça reste encore à changer dans la branche.
A priori à venir aussi, il deviendra possible de dégager le code de cache de la création des variables de substitution.
Mis à jour par Frédéric Péters il y a presque 6 ans
À faire aussi, mettre en place des dictionnaires qui fournissent les clés sur un getattr, parce qu'en Python le mélange d'accès via . et [] n'est pas clair. (cela étant, en attendant, l'accès exclusif par _ fonctionne, je ne sais pas si on veut à la fois mettre en place ce ticket et se mettre à suggérer de ne plus utiliser les _).
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Lié à Development #436: Affichage conditionnel sur une même page ajouté
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de En cours à Solution proposée
La branche contient maintenant tests et cie. Aussi pour limiter les risques on passe par le mode lazy uniquement pour les conditions django; et ça se contrôle via site-options.cfg dans lazy-variables-modes, qui est une liste des endroits où on veut appliquer ce nouveau mode (et par défaut c'est juste django-condition).
Mis à jour par Thomas Noël il y a plus de 5 ans
- get_static_substitution_variables : toutes les variables, exhaustivement, donc "comme d'hab"
- get_substitution_variables : une source capable de réagir en lazy via l'usage d'un dico CompatibilityNamesDict
C'est cela ?
Sinon, j'ai l'impression que le mode python-conditions ne sera jamais vraiment fonctionnel, à cause de l'habituel et souvent nécessaire usage de la forme vars().get('form_var_chose')
. Me trompe-je ? Si oui, pourquoi ne pas activer le lazy en Django, toujours (et donc jamais pour Python) ?
Mis à jour par Frédéric Péters il y a plus de 5 ans
Sinon, j'ai l'impression que le mode python-conditions ne sera jamais vraiment fonctionnel, à cause de l'habituel et souvent nécessaire usage de la forme vars().get('form_var_chose'). Me trompe-je ?
D'une part il y a espoir de lentement faire évoluer les documentations et usages vers des formes plus réelles form.foo.bar, plutôt que ces underscores.
D'autre part, pour gérer le vars(), je pensais l'avoir fait mais c'est le locals() que j'ai touché,
return {'datetime': datetime, 'Decimal': Decimal, + 'locals': compat_locals, 'random': random.SystemRandom(), 're': re, 'date': utils.date,
Si oui, pourquoi ne pas activer le lazy en Django, toujours (et donc jamais pour Python) ?
Je pense qu'on peut y arriver pour le Python, un jour; et en même temps que côté django, frilosité au début, faire ça uniquement sur les conditions, pas sur les templates.
Mis à jour par Thomas Noël il y a plus de 5 ans
Frédéric Péters a écrit :
Sinon, j'ai l'impression que le mode python-conditions ne sera jamais vraiment fonctionnel, à cause de l'habituel et souvent nécessaire usage de la forme vars().get('form_var_chose'). Me trompe-je ?
D'une part il y a espoir de lentement faire évoluer les documentations et usages vers des formes plus réelles form.foo.bar, plutôt que ces underscores.
Yes.
D'autre part, pour gérer le vars(), je pensais l'avoir fait mais c'est le locals() que j'ai touché,
Ah oui en plus je l'avais vu... on pourrait faire pareil pour vars ? (c'est la pratique que j'ai répandue, parce que je pensais le nom vars un peu plus "compréhensible" que locals, mouaich mouaich)
[...]
Si oui, pourquoi ne pas activer le lazy en Django, toujours (et donc jamais pour Python) ?
Je pense qu'on peut y arriver pour le Python, un jour; et en même temps que côté django, frilosité au début, faire ça uniquement sur les conditions, pas sur les templates.
Effectivement.
(Je reprends la lecture de la branche)
Mis à jour par Frédéric Péters il y a plus de 5 ans
Ah oui en plus je l'avais vu... on pourrait faire pareil pour vars ? (c'est la pratique que j'ai répandue, parce que je pensais le nom vars un peu plus "compréhensible" que locals, mouaich mouaich)
Yes, ajoutée à la branche.
Mis à jour par Thomas Noël il y a plus de 5 ans
- Statut changé de Solution proposée à Solution validée
Rien d'autre à ajouter... c'est un ack.
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit fda6dd4a354eb5a90ce1edeacca0b03f290ea59a Author: Frédéric Péters <fpeters@entrouvert.com> Date: Mon May 21 10:35:37 2018 +0200 general: add lazy evaluation to substitution subvariables (#22106)
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Résolu (à déployer) à Solution déployée
general: add lazy evaluation to substitution subvariables (#22106)