| 131 | | |
| 132 | | === App loading === |
| 133 | | * '''Complexity:''' Medium |
| 134 | | |
| 135 | | Django currently assumes that an application will only ever be loaded once, and that the name of that application will be determined solely by the package name holding the models.py file. However, this has several consequences; |
| 136 | | * You can't deploy several instances of the same application |
| 137 | | * You can't deploy two applications with the same name |
| 138 | | * There is no convenient interface for internationalizing application names |
| 139 | | * There is no way to rename an application with a name that isn't helpful from a UI perspective. |
| 140 | | |
| 141 | | This project would address these limitations by changing the way applications are loaded. Ticket #3591 contains a description of one proposal. |
| 142 | | |
| 143 | | Issues to consider: |
| 144 | | * How can we change the app loading mechanism without breaking every existing use of INSTALLED_APPS in the wild? |
| 145 | | * How should two instances of the same application be differentiated during runtime -- especially during URL reversal? |
| 146 | | |
| 147 | | See also: |
| 148 | | * #3591, and any discussion on [http://groups.google.com/group/django-developers django-developers] that references it. |
| 149 | | * [source:django/trunk/django/db/models/loading.py The current app loading mechanism] |
| 150 | | * Ideas on a InstalledAppsRevision collected during Pycon 2008 development sprint |
| 180 | | |
| 181 | | === Housekeeping === |
| 182 | | * '''Complexity:''' Minor |
| 183 | | |
| 184 | | Django has gone through three recent cycles of rapid change, culminating in the release of versions 1.0, 1.1 and 1.2. These releases have all been feature heavy, which is good for ticking off checkboxes on feature lists, but it does mean that some internal housekeeping and code cleanup tasks have been avoided in order to deliver new features. These housekeeping issues would be well suited to a Summer of Code student wishing to gain a deep understanding of the internal workings of the Django framework. |
| 185 | | |
| 186 | | Issues to consider: |
| 187 | | * Django's Model._meta class is officially internal API, but in practice, many parts of _meta are in such common use that they couldn't be changed without causing major problems to Django users. The contents of _meta should be surveyed, cleaned up where necessary, documented and tested as part of formal API. |
| 188 | | * While the public API for foreign keys and m2m relations in Django is quite elegant, the implementation is anything but. This implementation should be cleaned up. |
| 189 | | * There are several internal components (such as the datastructures library) that are heavily used, but have not been extensively profiled to ensure that they are efficient. Profile the Django test suite to find the areas of code that are performance bottlenecks, and optimize them. |
| 190 | | |
| 191 | | See also: |
| 192 | | * Trac, bugs by component. Any component with lots of bugs is potentially a candidate for inclusion in this project. |
| 193 | | * [source:django/trunk/django/db/models/options.py The Model._meta class definition] |
| 194 | | * [source:django/trunk/django/db/models/fields/related.py The related fields implementation] |