views:

65

answers:

4

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.

+3  A: 

It does seem a bit generic, but no more so than "Attribute". I would give it a prefix based on the app if possible.

Ignacio Vazquez-Abrams
"A bit generic"? I'd say that it's so vague as to be meaningless. Surely there are far more clear and precise names than "Item" and "Attribute".
S.Lott
"Attribute" isn't in the application. It's just for the example. The class in question was "Item". If somebody has an "item" in their store, it doesn't lend itself to the term "meaningless" very well, does it? The reason for possible use of this term is that "Item" tends to be more ubiquitous in the e-commerce world than "Product", and although "Product" doesn't necessarily infer the probability of confusion, I'm keeping an open mind when it comes to naming conventions.
orokusaki
+2  A: 

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.

+2  A: 

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.

Ian Clelland
+1  A: 

go with default item_set, problem-free :)

Dmitry Shevchenko