#2982: [patch] allow replacing models.py with a subpackage models/__init__.py
------------------------------------------------------+---------------------
   Reporter:  Bastian Kleineidam <[EMAIL PROTECTED]>  |                Owner:  
adrian          
     Status:  new                                     |            Component:  
Database wrapper
    Version:                                          |           Resolution:   
               
   Keywords:                                          |                Stage:  
Accepted        
  Has_patch:  1                                       |           Needs_docs:  
0               
Needs_tests:  1                                       |   Needs_better_patch:  
1               
------------------------------------------------------+---------------------
Changes (by anonymous):

  * needs_better_patch:  0 => 1
  * needs_tests:  0 => 1
  * stage:  Ready for checkin => Accepted

Comment:

 Not quite ready for checkin yet, upon examination (no fault of the
 triagers, I just was looking over it before checking it in)...
 
 In the past we've rejected this sort of approach because it required the
 redundant import statements in {{{models/__init__.py}}} (rather than just
 {{{from models.foo.bar import MyModel}}} in the code being sufficient).
 Ideally, it would be nice to descend from models (whether it's models/ or
 models.py) and extract all the models without needing the
 {{{models/__init__.py}}} import. I think {{{db.models.loading}}} is one
 place that needs fixing for that. I think it should be possible to make
 this work.
 
 We should be able to make a test for this one, since we have models.py
 files in the tests already (make a new test directory and have a models/
 directory in it). Need to make sure we test that it works sufficiently
 generally (models/foo/bar.py should work -- looks like it does, but
 testing makes perfect).
 
 I don't like the use of "assert" in this patch, since assert is for things
 that should never fail and we can "guarantee" will be true. We cannot make
 guarantees about the user's (programmer's) code, though; they do make
 mistake and it's not Django's internal fault if that happens. So we should
 do a normal check and raise a proper exception (not AssertionError) if
 there is a problem. Everywhere else in Django does this upon an end-user
 error, so it's consistent.
 
 I'll probably fix some/all of these problems myself on the next pass
 through if nobody wants to do it first. Just recording the problems for
 future triage benefit.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/2982#comment:8>
Django Code <http://code.djangoproject.com/>
The web framework for perfectionists with deadlines
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to