I'm creating this:
# models.py
class Item(models.Model):
sku = models.CharField(max_length=20)
class Attribute(models.Model):
item = models.ForeignKey(Item, related_name='items')
Is that开发者_开发知识库 going to cause naming collisions in Python? Like:
# views.py
some_object.items.create(sku='123abc')
# Is there a place / way that this could cause errors, like:
# AttributeError: Bound method 'items' has no attribute "create"
# Since items() on a dict-like object could be a method to return a list,
# and Django could add support for .items() on a queryset right?
If it's a bad idea, I could change the name.
It does seem a bit generic, but no more so than "Attribute". I would give it a prefix based on the app if possible.
A model isn't the same thing as a queryset, and neither of them is documented as being dict-like. There shouldn't be any problem with doing this.
If you are really worried, then make as much of this code public as possible, and get people using it :) If nothing else, the Django core team is really diligent about checking as much "in-the-wild" code as they can before extending the documented APIs in any way. They really do care about not breaking people's existing code, as much as possible.
If making it public isn't an option, then at least watch the mailing lists, so that when somebody proposes "Hey, let's add an .items method to Model!", you can at least chime in with a "that'll break my code" at the right time.
It's really not a problem. If you have some random object and feel 'items' is a suitable name for a method, then go ahead. It is not going to cause any collisions with names that happen to be used on other objects.
As long as you think the method name is not misleading and does not cause confusion, go ahead.
go with default item_set, problem-free :)
精彩评论