Système de tags

Salut,

J'aimerais créer un système de tags efficaces pour des articles. Je suis parti là-dessus :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

class Articles(models.Model):
    title = models.CharField(max_length=80)
    type = models.IntegerField()
    image = models.ImageField(upload_to="miniature", null=True)
    content = models.TextField()
    dateCreate = models.DateTimeField(auto_now_add=True)
    isActive = models.BooleanField(default=True)


class ArticlesTags(models.Model):
    article = models.ForeignKey(Articles)
    tag = models.ForeignKey(Tags)

class Tags(models.Model):
    name = models.CharField(max_length=30)

Est-ce que ça vous parait correct ou il y aurait une meilleure méthode ?

Merci

Ça n'est pas vraiment gênant, puisqu'il n'écrase pas cette fonction, il a juste un attribut du nom de type.

C'est juste une mauvaise pratique. Si tu commences à nommer des attributs type tu as de fortes chances de voir une variable nommée pareil à un endroit. Et ça c'est vraiment mal.

Je ne vois pas où est la mauvaise pratique. Il faut juste être conscient que tu touches là à un attribut, et qu'il n'en serait pas de même s'il s'agissait d'une variable.

Si tu t'interdis d'utiliser un nom de builtin comme attribut, alors plus d'id, de min ou de max, et que penser de la méthode format des chaînes de caractères ?

Je suis également pour les proscrire.

Merci beaucoup à vous !

Effectivement, j'ai repris un projet en cours, je dois retravailler pas mal de choses pour respecter la PEP-8, PyCharm est vraiment génial pour ça (entre autres).

Oui je m'inspire pas mal de Zds, même si ne comprends pas toujours tout.

C'est quand même une super mauvaise idée d'utiliser des noms de built-in comme identifiants (de variables, de fonctions, etc)…

Tu fais comment si t'en as besoin plus loin ?

1
2
3
4

def something(dict, sth):
    list = list(dict)
    max = max(list)
    return max/max(list(dict(sth)))

Enfin, tu peux te dire "Non mais quand j'écris une fonction dans laquelle je shadow un built-in, je SAIS que j'aurai pas besoin du built-in plus tard dans le code." Mais c'est absurde comme opinion. Tôt ou tard ton code sera modifié par toi ou quelqu'un, et il deviendra évident après quelques minutes/heures de débugging que c'était une idée à la con.

Quand je dis « Si tu t'interdis d'utiliser un nom de builtin comme attribut », je parle en fait d'attributs, donc je ne vois pas trop le rapport avec ton exemple. a.max = 0, ça ne fait de mal à personne.

Et si on reprend l'exemple initial :

1
2

class A:
    type = ...

Oui, tu pourras avoir un soucis si tu utilises type dans le corps même de ta classe :

1
2
3

class A:
    type = ...
    foo = type(0)

Mais à ce moment là, la mauvaise pratique est elle vraiment d'avoir créé un attribut de classe du nom de type ?

Bah oui. Ce serait quoi d'autre la mauvaise pratique dans ton exemple ?

Et gustavi a fait un commentaire très pertinent au dessus : on nomme généralement une variable d'après le nom de l'attribut auquel elle fait référence. Du genre name = user.name.

Il est nettement plus malin de faire type_ = truc.type_ que type_ = truc.type.

Et si tu fais type = truc.type, tu retombes pile dans l'exemple que j'ai donné. Tu vois le rapport ?

De mettre plus de code dans le corps de la classe que le strict nécessaire.

Ah ben si tu dis que c'est nettement plus malin, c'est sûrement que tu dois avoir raison. Mais, en quoi ? Et pourquoi ta variable ne s'appellerait pas truc_type si tu as à tout prix besoin de stocker ce type à l'extérieur de truc ?

Sauf que je n'ai pas parlé de faire ça, donc je ne vois toujours pas le rapport. Si tu fais type = truc.type_ tu retombes aussi sur ton exemple.

C'est du troll là, je vois pas trop l'intérêt de continuer cette discussion.