#569 closed defect (wontfix)
[patch] better pluralization for table names
Reported by: | Owned by: | Adrian Holovaty | |
---|---|---|---|
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: | no | UI/UX: | no |
Description
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 by , 19 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 19 years ago
Hmm. I think at least adding the standard handlings for "...s" pluralized as "...ses" 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 django-admin.py - and the pluralized name is in there.
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:
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:
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.