SOLID principles

[median estuary]

Hello Folks I saw than for a better use and readability it's better to put the same logic in a class or a function. I just realised that I putted the choices variable for my fields having multiple choices in the same class model (see below)

class Project(models.Model):
    PERSONAL = "PERS"
    PROFESSIONAL = "PRO"
    FORMATION = "FORM"
    
    TYPE_OF_PROJECT_CHOICES = {
        "PERSONAL": "Personel",
        "PROFESSIONAL": "Professionel",
        "FORMATION": "Formation",
    }
    
    title = models.CharField(max_length=100)
    short_text = models.TextField(default="")
    text = models.TextField(default="")
    link = models.TextField(default="")
    client = models.TextField(default="")
    github_link = models.TextField(default="")
    image = models.ImageField(upload_to = "projects")
    type = models.CharField(choices =TYPE_OF_PROJECT_CHOICES, default= PERSONAL, max_length=100)
    date = models.DateField("date published")
    
    def __str__ (self):
        return self.title```

I asked Gemini about it and it was telling me that I am wrong. The class here contain to logics. (the choices + the model's field part).

Gemini proposed me to create an other file "choices.py" or if it's more general to put these variables in the "util.py" and import it to my model.py.

Can I trust Gemini ? What is the more commonly done about it by convention ?

[signal barn]

You are eapparently not re-using these chooses anywhere else, and it is also completely normal to do like this in Django. However, your hard coded choices does not match the ones in TYPE_OF_PROJECT_CHOICES

[shy knoll]

I would recommend having a sepetate file using a choice class

What you did is still valid but not the most up to date approach

[upbeat swallow]

I like to keep the choices as close as possible to the respective models and only bring them out when needed. Not really a common approach, but hey.

[sage lintel]

I'm with XTerm on that one. if it's a field used in several models I extract it into a mixin class to reuse

[acoustic ridge]

Since when?

[shy knoll]

Since choice classes become a thing?

[acoustic ridge]

That doesn't mandate moving them to their own file…

[acoustic ridge]

This is exactly how the docs show it btw https://docs.djangoproject.com/en/5.2/ref/models/fields/#enumeration-types

[shy knoll]

Yes? I was referring to tuple vs class

[shy knoll]

This doesnt give the best experience when you need to externally use the choices for things life filteirng

[sage lintel]

in general I do see 3 ways to define choices. everything one by one as variables and then build a choices list of tuples from it (first example in https://docs.djangoproject.com/en/5.2/ref/models/fields/#choices) or use an Enum or use the more modern models.TextChoices class or its Integer/number equivalent. I think we have all 3 somewhere. WHERE you define it is debatable, I prefer close to their use

[acoustic ridge]

Personally I think using ModelName.ChoiceOptions a perfectly nice way to refer to the choices outside the model. It makes it clear the relationship between the two

[shy knoll]

Agree to disagree 🌻 I find that usage redundant

[median estuary]

Haha I created a real battle here. What a monster I am

Lets Brandish our swords and shields !

https://tenor.com/view/the-simpsons-gif-6194237760116490386

Jokes appart 🤣

A friend told me that Python doesn't allow SOLID principles. As importing too much modules files when done redundantly, it can create an import loop wich can result to an error. Like Module A import Module B, wich import Module C wich import Module A. Python will search in an infinite loop.

[shy knoll]

it won't 🙂

[median estuary]

So I think I will let it like this

[shy knoll]

circular import is an error that causes program the crash, it can be detected and handled

a circular import at model level break django's init process

and I wouldn't say this is againist SOLID

[median estuary]

But it's not good even if it's not handled ? Isn't

[shy knoll]

I'm missing your point. If you write a bug, you will write a bug and you can do it in any language

[median estuary]

Not but what my friend would to say is that you can do SOLID principles but in the case you want to separate the logic Python have his own limitations because of circular import

[shy knoll]

circular imports are not a standard/normal thing in Python

Python doesn't force you to use circular imports, it's type of a bug. That friend sounds confused 🙂

[median estuary]

Like if you separate too much logic in many different files you will use them as a lot of modules and "can" create unfortunately circular import

[shy knoll]

which can be the case with any technology

if you don't organize your project structure properly, yes you will make mistakes

[median estuary]

Apparently PHP and other langage allow it because when it see that the next module has been already import it stop. It has been taken in charge to stop the circular import

[shy knoll]

how to intepret a dependency structure is one thing

but once again, Python doesn't force you to use circular imports or doesn't get stuck in an infinite loop when you accidentally create one

if anything, I'd prefer my language to not allow them - as Python does

to go back to the original point, how does this relate to SOLID?

[median estuary]

To separate the logic as my project class include only what need to be handed as the fields. And the choices function outside

[shy knoll]

your project components being in different files doesn't directly mean "SOLID" or vice versa