Projet

Général

Profil

Development #16109

Silencieusement donner une valeur à toutes les variables

Ajouté par Victor Claudet il y a presque 7 ans. Mis à jour il y a 9 mois.

Statut:
Fermé
Priorité:
Normal
Assigné à:
-
Version cible:
-
Début:
30 avril 2017
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

Description

Suite au ticket #16103 je me pose la question suivante.

ne pourrait-on pas à chaque fois qu'on appelle une variable, induire la vérification de l’existence de cette variable ?

et donc systématiquement quand j'écris form_var_mavariable, w.c.s. testerait vars().get('form_var_mavariable') avant d'essayer d'y lire une valeur.

Dans ma vision des choses w.c.s. se charge déjà d'analyser ce qui peut être saisie dans un champ où il est susceptible de trouver une expression alors je me dis que ça doit être faisable.

Historique

#1

Mis à jour par Victor Claudet il y a presque 7 ans

  • Sujet changé de Question interne suite à ce ticket à Question interne sur le test d'exitence d'une variable
#2

Mis à jour par Victor Claudet il y a presque 7 ans

  • Sujet changé de Question interne sur le test d'exitence d'une variable à Question interne sur le test d'existence d'une variable
#3

Mis à jour par Frédéric Péters il y a presque 7 ans

  • Tracker changé de Support à Development
  • Projet changé de Châteauroux Métropole à w.c.s.
  • Sujet changé de Question interne sur le test d'existence d'une variable à Silencieusement donner une valeur à toutes les variables
  • Privée changé de Oui à Non

Dans ma vision des choses w.c.s. se charge déjà d'analyser ce qui peut être saisie dans un champ où il est susceptible de trouver une expression alors je me dis que ça doit être faisable.

Deviner ce qui pourrait légitimement être une variable dans le cadre du formulaire/workflow en cours, ce n'est pas possible, notamment ici parce que les variables en question viennent de ce qu'a pu répondre un webservice extérieur, w.c.s. ne peut pas savoir qu'un appel à l'API fillslot de Chrono retournera en cas de succès telles données.

Ce qu'on peut imaginer, c'est être brutal et tout accepter, de manière sommaire ça serait :

--- a/wcs/qommon/publisher.py
+++ b/wcs/qommon/publisher.py
@@ -141,10 +141,12 @@ class QommonPublisher(Publisher, object):
         import re
         from decimal import Decimal
         from . import evalutils as utils
-        return {'datetime': datetime,
+        return collections.defaultdict(
+                lambda: None,
+                {'datetime': datetime,
                 'Decimal': Decimal,
                 're': re,
-                'utils': utils,}
+                'utils': utils,})

     def format_publish_error(self, exc):
         get_response().filter = {}

Ça rejoindrait un fonctionnement (un brin polémique) des templates django; la même chose (avec une chaine vide plutôt que None) serait-elle alors à également envisager pour l'ezt ?

Le gros inconvénient que je vois, c'est qu'on ne recevra plus d'alerte sur des erreurs de frappe dans le nom des variables.

#4

Mis à jour par Thomas Noël il y a presque 7 ans

Frédéric Péters a écrit :

Le gros inconvénient que je vois, c'est qu'on ne recevra plus d'alerte sur des erreurs de frappe dans le nom des variables.

Pour moi c'est sur cet aspect qu'il faut reflechir (et travailler) : remonter les erreurs au développeur du formulaire et de son workflows, au lieu d'envoyer les traces seulement au sysadmin comme actuellement.

#5

Mis à jour par Benjamin Dauvergne il y a presque 7 ans

Thomas, la discussion que tu souhaites ouvrir ici concerne le ticket #6844 il me semble.

#6

Mis à jour par Frédéric Péters il y a presque 7 ans

Non, #12566.

#7

Mis à jour par Frédéric Péters il y a presque 7 ans

+        return collections.defaultdict(
+                lambda: None,

Mais le résultat qu'on peut déjà voir, ça sera d'autres classes d'erreurs, genre Nonetype has no attribute .lower(), ou NoneType is not iterable, ou encore int() argument must be a string or a number.

#8

Mis à jour par Thomas Noël il y a presque 7 ans

Piste évoquée entre Fred et moi : compléter utils avec plein d'utils, aka "des macros excel".

Et parmi celles-ci, par exemple : utils.var(varname, value=None) qui est la même chose que vars().get(varname, value), en un peu moins cabalistique.

#9

Mis à jour par Benjamin Dauvergne il y a presque 7 ans

Je serai curieux de voir l'implémentation de utils.var, faut taper dans la pile python je pense.

#10

Mis à jour par Thomas Noël il y a presque 7 ans

Un sucre dans le genre :

def var(_varname, _default=None):
    return vars().get(_varname, _default)

Nan ? (je dois rater un truc, je sens que je vais m'en prendre une)

#11

Mis à jour par Benjamin Dauvergne il y a presque 7 ans

Thomas Noël a écrit :

Un sucre dans le genre :

[...]

Nan ? (je dois rater un truc, je sens que je vais m'en prendre une)

Dis en live, mais il me semble que le vars() ne renverra pas les variables locales.

#12

Mis à jour par Frédéric Péters il y a 9 mois

  • Statut changé de Nouveau à Fermé
  • Planning mis à Non

Obsolète, c'était pour des expressions python.

Formats disponibles : Atom PDF