tk-it / tktitler Goto Github PK

Skal tk.prefix, postfix, og de andre tage type som keyword-only-argument? Dvs. så tvinger vi folk til at skrive tk.prefix(t, year, type=tk.PREFIXTYPE_UNICODE) i stedet for blot tk.prefix(t, year, tk.PREFIXTYPE_UNICODE).

Fordelen er at vi slipper for at vedligeholde argument-rækkefølgen for parametre ud over title_tuple og year som en del af interfacet, da man ikke kan ødelægge eksisterende kode ved at ændre rækkefølgen af keyword-only-parametre.

Alternativt skal vi understøtte at man giver typen som positional-argument (uden "type="), og så sparer vi de 5 tegn hver gang vi skal bruge en tktitler-funktion.

Der skal skives dokumentation.

En mail til BEST2021 kan tolkes som enten til BEST 2020/21 (2x2-format) eller BEST 2021/22 (4-format). Hvilken en skal vi vælge?

I idm findes også formerne:

T2OFORM (11/12)
T2OBEST 2011/12

De bliver lavet af idm.models.Title.display_title_and_year() og idm.admin.period_display_prefix(). Er det brugbart nok til at vi skal inkludere en funktion til det i tktitler?

def tk_prepostfix(title, gfyear=None):
    _, period = title
    prefixAndName = tk_prefix(title, gfyear)
    postfix = tk_postfix(("", period), POSTFIXTYPE_LONGSLASH)
    return '%s %s' % (prefixAndName, postfix)

Vil vi understøtte Python 2? tktitler.py har pt. en __future__ import, men det er en leftover fra idm/models.py som havde det fra dengang TK-IT/web understøttede Python 2.

Det er pt. relativt nemt for os at understøtte Python 2 hvis vi bruger six. Se 7de471e 89afdee. Jeg ved dog ikke om det er nyttigt nok til at vi skal involvere six i kodebasen i de næste tre år (indtil Python 2 er EOL i 2020).

Se https://travis-ci.org/TK-IT/tktitler/jobs/190286109

Coverage.py warning: Module tktitler was never imported.

• tk.email(("FUÄU", 2021), 2021) should be "FUAEU21", not "FUÄU21". We should add a test for this in TestEmail.
• tk.parse("FUAEU", 2021) will return ("FUÆU", 2021). I suggest we handle this in the mail server by adding a special case in parse_alias_title:

diff --git a/tkmail/address.py b/tkmail/address.py
index f68d5e2..006efb2 100644
--- a/tkmail/address.py
+++ b/tkmail/address.py
@@ -181,5 +181,8 @@ def parse_alias_title(alias, db, current_period):
     elif base in BEST or re.match(r'^E?FU\w+$', base):
         def f():
-            return db.get_user_by_title(base, period)
+            res = db.get_user_by_title(base, period)
+            if not res and "Æ" in base:
+                res = db.get_user_by_title(base.replace("Æ", "Ä"), period)
+            return res
     else:
         return None, None

Vi skal:

• Implementere de meste funktionalitet,
• Skrive test,
• Prøve biblioteket af i en PR i tkweb for at se om alt funktionalitet der er brug for er der,
  • Merge
• Prøve biblioteket af i en PR i mail,
  • Merge
• Prøve biblioteket af i en PR i regnskab,
  • Merge
• Lukke alle issues i milestone v1.0.0-alpha
• #11 Skrive dokumentation.
• Release v1.0.0

Lige nu har vi postfix() typerne:

• FUHØ11, SINGLE
• FUHØ1112, DOUBLE
• FUHØ 11/12, SLASH
• FUHØ2011, LONGSINGLE
• FUHØ 2011/2012, LONGSLASH

Et alternativ der dukkede frem i #1 er

• FUHØ 2011/12

Der går knap 40 år inden man støder ind i tvetydigheder med de korte versioner. Er der nogen grund til at understøtte LONGSINGLE og LONGSLASH?

Public APIs are forever

N.B. Det er kun outputtet af postfix(). parse() skal selvfølgelig kunne håndtere dem.

Fra #2 (comment):

@neic skriver:

Hvad er brugsscenariet for parse_relative() uden for tktitler?

@Mortal skriver:

Det virker som en naturlig subrutine for parse, og det kan blive nyttigt hvis vi f.eks. vil lave en mere intelligent håndtering af EFUIT-titler (hvor det f.eks. kan gælde at GEFUIT14 er den samme som EFUIT12).

Funktionen parse er nok den mest anvendelige, men parse_relative er en lidt mindre lossy parsing af aliaset. Man kunne forestille sig at lave en lossless parser (så enhver streng der repræsenterer en titel, såsom "K2TOGFUET1516", parses til en struktur der indeholder nok information til at rekonstruere den præcis samme streng), og ud fra denne vil parse_relative være en simpel nedkogning af parserens output, og parse vil ligeledes (som nu) være en nedkogning af parse_relative.

I TK-IT/regnskab ser det ud til at der er brug for TeX output. Det gælder både prefix i superscript samt _funny_substitute().

Vi har følgende offentlige funktioner:

get_gfyear()
set_gfyear()
tk_prefix()
tk_kprefix()
tk_postfix()
email()
parse_relative()
parse()

set/get_gfyear(), email(), parse() er alle navne der også kunne bruges til andre funktioner der ikke har noget med tktitler at gøre.

Jeg forslår at vi enten bruger prefixet tk_ på alle funktioner, eller endnu bedere helt dropper prefixet og "tvinger" brugeren til at bruge tktitler.*() eller import tktitler as tk.

Hvordan skal vi håndtere mellemrum mellem root og postfix. Eks. skal postfix(("FUHØ, 2011), type=POSTFIXTYPE_LONGSLASH) returnerer FUHØ2011/2012, FUHØ 2011/2012 eller FUHØ 2011/2012 (nbsp)? En løsning kunne være et optional argument der kan gives en arbitrær streng der bliver indsat imellem root og postfix.

Med set_gfear() som context manager, virker følgende ikke:

set_gfyear(2016)
tk_prefix(("FUBØ", 2011))

Det kunne man godt forledes til at tro. Man skal kende til context managers eller nærlæse dokumentationen for finde ud af hvad man skal istedet. I et godt API design burde der ikke være overraskelser.

Er det muligt at lave en anden løsning så man kan sætte gfyear?

(Det her er mere et spørgsmål om hvilke muligheder der er, end et spørgsmål om at finde et alternativ.)

Den skal pakkes: https://packaging.python.org/

Currently the only non-ASCII characters we support are Æ, Ø, Å. We need support for Ü with FUOÜ 2017/18.

Nogle årtal giver ikke mening. Eks. EFUIT og gamle BEST årgange.

Skal vi undlade at udskrive år ved sådanne titler?

I tkweb.apps.idm.models.display_title_and_year(), som skal erstattes med tktitler.prepostfix(), checker vi for om det er en EFUIT titel og udlader at udskrive hvis det er tilfældet.

    def display_title_and_year(self, =None):
        if self.root == 'EFUIT':
            return self.display_title(gfyear)
        prefixAndName = self.display_title(gfyear)
        postfix = tk.postfix(("", self.period),
                             tk.POSTFIXTYPE_LONGSLASH)
        return '%s (%s)' % (prefixAndName, postfix)

Vi kunne lave det samme hvis period er før et givent år eller hvis root er EFUIT. Det kan gøres i postfix() og/eller prepostfix() og/eller email(…, type=EMAILTYPE_POSTFIX). Hvad postfix() og email(…, type=EMAILTYPE_POSTFIX)skal give ved sådanne titler ved jeg ikke. Alternativt kan også bare logge det.