One thing I noticed while running some performance profiling tests a while ago was that django.db.models.fields.related._get_related_query_name was being called approximately a zillion times, as was _curried from django.utils.functional.
Although _get_related_query_name is very simple (return self.rel.related_name or opts.object_name.lower()), it potentially calls lower() each time, which is somewhat redundant. Also, related_query_name is defined using curry, so each function call is really two function calls. Anyway, I wondered why related_query_name even needs to be a function at all. It seems like contribute_to_class could just calculate it once and set the value as a regular attribute on the field. (I did this with my local version of Django and it seems to work fine.) I can only think of a couple reasons not to change it: * field.rel.related_name or cls._meta.object_name might change after the related field is first added to the class. I don't know why that would happen, though. * Existing apps might rely on it being a function. But it's not documented anywhere, so it doesn't seem like apps should be using it directly. It seems like a similar thing could be done for m2m_db_table, m2m_column_name, and m2m_reverse_name (but I don't use ManyToManyFields, so I don't feel strongly about those). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
