Python, ou l'art d'être astucieux

Pourquoi ne pas utiliser datetime.datetime.strptime pour parser les dates ?

Je n’y ai tout simplement pas pensé, ce qui prouve que je suis toujours un apprenti Python.

Petit orvet deviendra grand on fait la course ?!

C’est quand même pas très joli ces conversions de type et indexations à tout va. Le gars en Javascript il a déjà fini de taper et de débuguer son h2 -= h1; m2 -= m1; if (m2 < 0) { m2 += 60; h2--; } le temps que t’arrives à lire la doc puis à écrire datetime.datetime.strptime sans faire de faute de frappe. Après forcément il perd du temps sur les entrées/sorties, mais c’est normal il a pas printf.

Certes c’est plus court, mais est-ce vraiment plus intuitif, plus facile à lire et plus facile à écrire ? Et puis la lib datetime permet aussi de faire plus de choses merveilleuses (bien que pas toujours super intuitives) avec le temps. Par exemple, cette petite fonction que j’ai dans un projet perso, qui renvoie une liste de sept datetime.date qui sont les jours d’une semaine, à partir du datetime.date de n’importe quel jour dans cette semaine.

1
2
3
4
5
6
7
8
9

def days_of_week_from_day(dt):
    """
        Returns a list of seven datetime.date days representing a week
        from a day in this week.
    """
    if isinstance(dt, datetime.datetime):
        dt = dt.date()
    start = dt - datetime.timedelta(days=dt.weekday())
    return [start+datetime.timedelta(days=i) for i in range(7)]

Un postulat de base en Python veut qu’un code sera lu infiniment plus souvent qu’il ne sera écrit.

Et avec une autocompletion basique, ça se tape bien.

C’est un peu toujours la même question qui revient sur tous les sujets en ce moment (sur les billets du genre, et aussi sur le forum "Programmation" récemment) : jusqu’où est-ce qu’on est prêt à réinventer la roue ? Personnellement je fais plus confiance à mes capacités à écrire un petit algo de 2 lignes qu’à utiliser correctement une fonction de bibliothèque qui est potentiellement bien plus puissante que ce dont j’ai besoin. Donc plus facile à écrire et plus intuitif : je trouve que oui. Plus facile à lire, je suis d’accord que c’est le cœur du problème, et que c’est discutable.

Après effectivement, dès que ça se complique un peu, je cède volontiers ma place à des fonctions de bibliothèque pour faire des trucs non triviaux sur les dates.

Soit dit en passant, c’est pas vrai dans le cas précis de "Clash Of Codes". Mais effectivement j’oublie souvent que les gens de la vraie vie utilisent l’autocompletion.

En fait je suis d’accord avec toi et j’ai aussi tendance à réinventer sciemment la roue dans certains cas.

Je raisonne plus dans le cadre professionnel où le code va forcément passer par une review après avoir été commité, où dans ce cas même quand je comprends bien ce que fait un code, j’emmerde les gens en leur imposant des formulations et un nommage qui le rendent ultra-évident.

Dans le cas de ce billet, cela dit, le code d’informaticienzero serait passé tel quel dès le départ avec son split que je trouve beaucoup plus intuitif que strptime quand on a juste un HH:MM.

Dans ma tête, strptime ne commence à se justifier à partir de 3 champs.

Dans tous les cas, si la question ici est celle du code le plus court, datetime et ses noms à rallonge est disqualifié d’office.

1
2
3

h,m,H,M=map(int,input().replace(':',' ').split())
r=(H-h)*60+M-m
print(f'{r//60}:{r%60:02}')

Je n’ai pas précisé, mais il s’agissait ici d’être le premier à avoir un score de 100%, pas de faire le code le plus court.

.replace(':',' ').split())

Pourquoi pas .split(':')

EDIT: ah j’avais pas fait gaffe qu’il y a deux dates… Le boulet.