idm med tktitler

[neic]

Et første bud på hvordan idm kan bruge tktitler.

Jeg vil mene at de fleste funktioner under Title-classen skal fjernes. Ideen var at flytte valget af præsentationen af en titel længere op. Måske er Title.titletupel og Title.parse nok. Jeg er dog ikke sikker på hvordan regnskab afhænger af det endnu.

[neic]

Navnet Title.titletupel er også en del af debatten.

[Mortal]

"Tupel" er ikke engelsk. Jeg synes det bør hedde "title_tuple".

[Mortal]

Da prodekanus er firewalled bør vi bruge git+https i requirements.

[neic]

Måske er jeg on a limb: Hvis vi gør Title iterable kan vi give et Title-objekt direkte til tktitler-funktionerne uden at kalde .title_tuple() på det.

class Title(models.Model):
    #[…]

    def __iter__(self):
        return iter((self.root, self.period))

someTitle = Title.objects.all()[0]
tktitler.postfix(someTitle)  # "FUØP16"

Jeg ved ikke om der er nogle problemer i at gøre en Django model iterabel. Eller om det overhovedet giver mening.

[Mortal]

Jeg synes det er dårligt at gøre Title iterabel, fordi Explicit is better than implicit.

Jeg vil hellere have at tktitler tjekker for en titel_tuple metode på inputtet - og eventuelt kan tktitler erklære en abstrakt baseklasse som et objekt skal abstrakt nedarve fra før den tjekker om objektet har en titel_tuple(). Se collections.ABCMeta.

[neic]

Hvis jeg forstår ABC og metaklasser korrekt, så kunne en løsning være:

# tktitler.py
#[…]
class Title(metaclass=ABCMeta):
    @abstractmethod
    def title_tuple(self):
        pass

# idm/models.py
#[…]
class Title(models.Model, tk.Title):
    #[…]
    def title_tuple(self):
        return (self.root, self.period)

Det virker dog ikke fordi Django selv bruger metaklasser og det er ikke entydigt hvilken metaklasse der skal bruges:

class Title(models.Model, tk.Title):
TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases

En 'løsning' er måske:

class MyMeta(ABCMeta, models.base.ModelBase):
    pass

class MyTitle(metaclass = MyMeta):
    pass

class Title(MyTitle, models.Model, tk.Title):

men jeg er ude på dybt vand. Desuden bliver det for kompleks til at det giver mening.

Er der noget jeg har overset?

[Mortal]

Beklager jeg ikke linkede præcist nok. Jeg mener at vi kan bruge ABCMeta.register. https://docs.python.org/3.6/library/abc.html#abc.ABCMeta.register

Så behøver vi ikke ændre på hvilke klasser Title rent faktisk nedarver fra.

[neic]

Om virtual subclasses:

[…] these and their descendants will be considered subclasses of the registering ABC by the built-in issubclass() function, but the registering ABC won’t show up in their MRO (Method Resolution Order) nor will method implementations defined by the registering ABC be callable (not even via super()).

Med tk.Title.register(Title) retunerer isinstance(Title.objects.all()[0], tk.Title) godt nok True, men den giver ingen fejl på instantiation hvis title_tuple() ikke er overskrevet i idm.models.Title. (Som den ville have gjort hvis det ikke var virtuel, men alm. subklasse.)

Den eneste fordel er vel så at man kan bruge isinstance(title_parameter, Title) istedet for hasattr(title_parameter, 'title_tuple') eller try…catch i prefix() et al.?

[Mortal]

Ja, det er kun issubclass der ændres når man registrerer en ny subklasse.

Forskellen på hasattr og issubclass er at issubclass (EDIT: hasattr) ikke har nogen forståelse for navnerum, hvorimod register/issubclass har. Derfor er register bedre.

Hvis et andet interface i verden bruger metodenavnet titel_tuple, og vi blot tjekker efter metodenavnet, så kan det være at vi accepterer objekter der ikke burde accepteres. Med register skriver forfatteren bag klassen eksplicit, at de understøtter vores interface.

Det er mere kompliceret at bruge register og issubclass end at bruge hasattr, så hasattr er bedre i dén anseende. Hvad synes du er bedst?

[neic]

ABCMeta.register og issubclass() er fint. Man behøver ikke at forstå metaklasser for at anvende det. Det havde bare været rart hvis vi også kunne få checket på instantiation med. Jeg laver det imorgen.

[Mortal]

Jeg er tilfreds sålænge vi giver en meningsfyldt fejlmelding når argumentet ikke implementerer klassen. Hvis argumentet implementerer det, men ikke har den rigtige metode, så er det (efter min mening) i orden at give en fejlmelding der ikke giver mening.

[Mortal]

Jeg har implementeret en tk.title_class decorator i tktitler/#20.

Done

[Mortal]

Hvad med at sætte tktitler gfyear i en middleware? Så kan vi gå fra et sted mellem 0 og 100 kald til config.GFYEAR pr. view til (næsten) altid ét kald pr. view, og vi kan slippe for at henvise til constance de fleste steder.

Ulemperne er 1) vi tilgår databasen selv på views der ikke bruger config.GFYEAR til noget, og 2) det fremgår ikke af koden at året hentes via constance.