Opened 10 years ago

Closed 10 years ago

Last modified 8 years ago

#569 closed defect (wontfix)

[patch] better pluralization for table names

Reported by: hugo <gb@…> Owned by: adrian
Component: contrib.admin Version:
Severity: normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


I ripped off the inflector.pluralize function from Ruby on Rails and ported it over to python. This gives much better pluralization than the simple rule used by django. The source of the pluralize function can be found over here in my subversion tree.

Change History (2)

comment:1 Changed 10 years ago by adrian

  • Resolution set to wontfix
  • Status changed from new to closed

I'd prefer not to change Django's model pluralization scheme. Here's an explanation.

The "poor-man's" pluralization -- simply adding an "s" -- currently used by Django is intentional. Anything other than that would get confusing, because it would force programmers to guess-and-check whether the automatic pluralization was correct.

With the current solution (adding an "s"), the protocol is easy:

  • If the word is pluralized correctly by adding an "s", don't do anything.
  • Otherwise, specify verbose_name_plural in your model.

Both of these steps are done in the human brain, without having to check the output of any program.

With a more complex pluralizing solution, the protocol gets complex:

  • Check the output of the pluralization algorithm for the given word.
  • If the word is pluralized correctly, don't do anything.
  • Otherwise, specify verbose_name_plural in your model.

This requires the programmer to check the output of the algorithm for the given word (unless he happens to know the pluralization algorithm result for the given word). If you've read "The Design of Everyday Things," you'll note this example requires "knowledge in the world," rather than "knowledge in the head." The latter is much more efficient.

For example, say there *is* a pluralizer, and it doesn't correctly pluralize "criterion" (correctly pluralized "criteria"). If a Django programmer assumes the pluralization works, he will have made a wrong assumption. If a Django programmer assumes it doesn't work, the pluralization becomes more of a burden than a shortcut.

I don't follow Ruby on Rails at all, but I seem to recall hearing that community has debated this issue.

Finally, it's inefficient to run the pluralization algorithm each time Django models are loaded. Premature optimization is evil, but unnecessary overhead is, too.

comment:2 Changed 10 years ago by hugo <gb@…>

Hmm. I think at least adding the standard handlings for "...s" pluralized as "" and "...y" pluralized as "...ies" should be done, nonetheless - the current behaviour is rather annoying. Actually I would think that it would be better to drop pluralization altogether (and making the table_name a required attribute on model classes) than to let the current too-primitive algorithm stand. The current algorithm doesn't even get a rate of 50% right, so it's not that much of a help anyway. And I think the "look at output of tool" argument is a strawman: you will look at the output anyway, because of the sql* commands of - and the pluralized name is in there.

Note: See TracTickets for help on using tickets.
Back to Top