Produits Entr'ouvert » w.c.s.

Au détour de travaux sur le sujet, je tente de rendre les dates lazy (LazyFieldVarDate) plus souples quant aux comparaisons, notamment pour ne plus être embêté par les différences entre date et datetime.

Le patch ci-joint montre une limite que j'ai du mal à franchir : je peux faire un opérateur __eq__ pour lazyvar foo, mais ça ne marche pas pour foo lazyvar si foo a déjà un opérateur __eq__... comme c'est le cas pour datetime.date, et zut. Et donc, le test dans le patch joint échoue :

        # flexible date comparison
        for date in ('2018-07-31', '31/07/2018',
                     datetime.date(2018, 7, 31),
                     datetime.datetime(2018, 7, 31, 0, 0),
                     time.strptime('2018-07-31', '%Y-%m-%d')):
            assert lazy_formdata.var.datefield == date
>           assert date == lazy_formdata.var.datefield
E           assert datetime.date(2018, 7, 31) == <wcs.variables.LazyFieldVarDate object at 0x7f7470850c90>

Je ne suis pas sûr qu'on puisse sortir proprement de ce soucis ; si ça se confirme je préférerai revenir à l'idée de "pour comparer des dates il faut toujours utiliser |date ou |datetime" au lieu de tenter d'expliquer dans quel ordre il faut faire les comparaisons (ça sera inexplicable).

Mais peut-être que je rate quelque chose dans le LazyFieldVarDate::__eq__ ou ailleurs.

Et donc, curieux et un peu insomniaque, dans les sources de Python 2 sur la comparaison des date :

 ...
    else if (PyObject_HasAttrString(other, "timetuple")) {
        /* A hook for other kinds of date objects. */
        Py_INCREF(Py_NotImplemented);
        return Py_NotImplemented;
    }
 ...

et effectivement, si on ajoute un timetuple au LazyFieldVarDate, ça lève un NotImplemented sur le __eq__ des datetime, et hop, ça force notre __eq__ ! Le patch joint ajoute juste :

+    def timetuple(self):
+        return self.get_raw()

Mais j'ai maintenant un autre soucis amusant sur la comparaison avec un timetuple, qui redevient un simple tuple au moment d'être envoyé dans le __eq__ (et donc parse_datetime se plante) :

        # flexible date comparison
        for date in ('2018-07-31', '31/07/2018',
                     datetime.date(2018, 7, 31),
                     datetime.datetime(2018, 7, 31, 0, 0),
                     time.strptime('2018-07-31', '%Y-%m-%d')):
            assert lazy_formdata.var.datefield == date
>           assert date == lazy_formdata.var.datefield

tests/test_formdata.py:639: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
wcs/variables.py:447: in __eq__
    return parse_datetime(self.get_raw()) == parse_datetime(other)
wcs/qommon/templatetags/qommon.py:65: in parse_datetime
    return evalutils.make_datetime(datetime_string)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

datetime_var = (2018, 7, 31, 0, 0, 0, ...)

    def make_datetime(datetime_var):
        '''Extract a date from a datetime, a date, a struct_time or a string'''
        if isinstance(datetime_var, datetime.datetime):
            return datetime_var
        if isinstance(datetime_var, datetime.date):
            return datetime.datetime(year=datetime_var.year, month=datetime_var.month,
                                     day=datetime_var.day)
        if isinstance(datetime_var, time.struct_time):
            return datetime.datetime(*datetime_var[:6])
        if hasattr(datetime_var, 'decode'):
            return get_as_datetime(datetime_var)
>       raise ValueError('invalid datetime value: %s' % datetime_var)
E       TypeError: not all arguments converted during string formatting

wcs/qommon/evalutils.py:57: TypeError

Étonnant, non ?

Je suis tenté par patcher make_datetime avec if isinstance(datetime_var, (time.struct_time, tuple)): mais c'est pas très joli (et j'aimerai comprendre, aussi).

Voici mon idée pour que les form_var_date disposent d'opérateurs de comparaison leur permettant d'être comparer à des date, des datetime, des choses qui ressemblent à des dates (tant que c'est interprétable par parse_datetime)

• la création d'un LazyDate du même genre, mais pas lié à un formdata, à utiliser en résultat de |date, de now, de today, etc...
• et l'usage de ce LazyDate aussi en résultat des |add_days et |add_hours à venir

Hop go.

En fait je n'étais pas très satisfait par ce patch. En voici une nouvelle forme, qui permet une extension assez simple ensuite vers la lazyfication de "now" et "today" (patch 0002).

C'est poussé dans http://git.entrouvert.org/wcs.git?h=wip/29406-lazy-date-system

Ainsi donc ok.

Donc, d'abord valider #29887 pour se couvrir un peu (tests supplémentaires).

• 0002-variables-add-flexible-comparison-on-lazy-dates-2940.patch : lazy-fication des form_var_date
  • ici petit détail, dans le strftime on doit de-lazyfier avec un copy avant d'envoyer l'objet à datetime_safe.strftime de Django, qui joue avec type() (et les objects Lazy ne savent pas mentir sur leur type)
• 0003-misc-add-lazydateobject-use-it-for-today-and-now-glo.patch : création d'une classe LazyDateObject et utilisation par "now" et "today"
• 0004-make-date-and-datetime-templatetags-render-lazydate-.patch : utilisation de cette lazyfication dans |date et |datetime

La suite c'est l'arrivée des calculs autour des dates (add_days & co) dans #29337

Benjamin avait vu juste, l'affaire met un gros bazar dans les calculs en Python qui utiliserait today et now, parce que ce sont des variables d'un nouveau type Lazy. Et par exemple une condition du genre "utils.age_in_days(today) == 0" (un peu idiot mais bon) crashe sur un « TypeError: unsupported operand type(s) for -: 'datetime.date' and 'LazyDateObject' »

Pour corriger ça, je proposerai d'ajouter dans QommonPublisher une méthode pour re-proposer les vrais today et now en mode non-lazy :

+++ b/wcs/qommon/publisher.py
@@ -1061,6 +1061,12 @@ class QommonPublisher(Publisher, object):
         d['manager_homepage_title'] = d.get('portal_agent_title')
         return d

+    def get_static_substitution_variables(self):
+        return {
+            'today': datetime.date.today(),
+            'now': datetime.datetime.now(),
+        }
+

les tests sont ok, mais ... mon sentiment : tout ça devient assez illisible. Bien que pleine de tests, cette branche me semble un nid à bogues. Mais je suis de nature inquiète...?

Ci-joint le patch qui serait à inclure dans la branche, à merger dans « misc: add lazydateobject, use it for today and now global variables (#29406) ». Je l'ai ajouté dans la branche pour voir si les tests passent via jenkins2.

Author: Thomas NOEL <tnoel@entrouvert.com>
Date:   Mon Jan 21 22:44:35 2019 +0100

    evalutils: handle lazy dates in make_date and make_datetime (#29406)

commit 87cae6fbbcb44d5844b51304e021b7ce98ce6444
Author: Thomas NOEL <tnoel@entrouvert.com>
Date:   Thu Jan 17 17:19:42 2019 +0100

    make date and datetime templatetags render lazydate objects (#29406)

commit e2260c5ac07c1e4fb30484c81787068a59bd6374
Author: Thomas NOEL <tnoel@entrouvert.com>
Date:   Thu Jan 17 16:34:33 2019 +0100

    misc: add lazydateobject, use it for today and now global variables (#29406)

commit e6969acb1c1fbfb35aa990d26216c5865fa8d312
Author: Thomas NOEL <tnoel@entrouvert.com>
Date:   Wed Jan 2 23:54:03 2019 +0100

    variables: add flexible comparison on lazy dates (#29406)