19đź‘Ť
- It’s always a bad idea to have a variable name that shadows one of
python’s built-ins. It will confuse people reading your code, who expect type to mean something specific. Less important than readability to other users it can also throw off syntax highlighting. - Rename the variable. (really it’s the best thing to do – you could leave it, but rename now while it’s easy)
- There are lots of potential options, perhaps
classificationorcategory. I know you said you don’t likecategory, but I can’t see what’s not generic about it?
It might be that it would be overkill for your specific application (would need to know more), but django does support model inheritance.
23đź‘Ť
I disagree with the other answers. There’s no need to change this.
In my opinion, there is little risk of confusion, as you will never access the attribute except via an instance. my_vehicle.type is not easy to confuse with (eg) type(my_vehicle).
- [Django]-In-Memory broker for celery unit tests
- [Django]-How should I use DurationField in my model?
- [Django]-Django switching, for a block of code, switch the language so translations are done in one language
1đź‘Ť
Well, warning or error, i’d avoid always to risk a situation like yours 🙂 The better thing in my opinion you can do is change the variable name without losing any meaning nor cohesion. You could call it “v_type” meaning vehicle type in a shortened way, if it’s used only for that particular class. If you’ll extend that class, you’ll extend it with another vehicle type, so in your case “v_type” would fit.
- [Django]-Django role based views?
- [Django]-Examples of Django and Celery: Periodic Tasks
- [Django]-Is Tornado a replacement to Django or are they complementary to each other?