80 | 80 | This might not be a big problem if we already used consistent import statements. However, it is convenient to be able to leave off the project name inside an application, so that we can move the application between projects. Also, although we might import something from a particular path, if Django imports it as part of working out all the installed models (which it has to do to work out reverse related fields, again), it might be imported with a slightly different name. This "slightly different name" is used to derive the application name and so, if we are not careful, we might end up registering the same model under two or more different application names: such as registering Example under ''application'' and ''project.application'', even though it is the same {{{Example}}} class. And this leads to problems down the line, because if the reverse relations are computed as referring to the ''project.application'' {{{Example}}} class and we happen to have a copy of the ''application'' {{{Example}}} class in our code or shell, things do not work. |