Thanks for your feedback, Karen. > http://code.djangoproject.com/ticket/8898 > > I suspect this one may be stalled because it is in design decision needed > state with a last comment that makes it sound like the existing patch (added > before the last comment) is not correct and that the right fix will require > changes that are potentially backwards-incompatible ("users should be guided > to use X if they want to use Y"...how is that different from what users are > guided to do today and is there something they can do today that won't be > allowed after this fix is made?) > > The bug sounds like it should be fixed, but that last comment makes it sound > like a proper fix is not yet available. Therefore not something that can > easily be simply committed but rather will require someone to spend some > time researching the history of this type of field to make sure the right > fix is developed. This rather conflicts with what you say above about this > being a simple fix, so please clarify in the ticket if that last comment and > move to design decision needed was not meant to raise a red flag that the > initially posted fix was not all that was necessary to fix this problem.
I've put this ticket back to "accepted" as per your comment that the bug should be fixed. As you say, the DDN and confused comments were not intended to raise a red flag, and should have been taken to a separate ticket. The suggested change would have been backwards incompatible, anyway. IMHO, the bug should be fixed as it is, regardless of any possible future changes. There's still no comment in the ticket from a core developer or anybody else, though. As this is a simple bug fix, can I (as the reporter) mark this ready for checkin, as there is a patch with tests? > >http://code.djangoproject.com/ticket/9482 > > This one is only two days old. Give it time. But there's an easy > workaround (set the environment variable yourself before calling whatever > script you are runnig), this is not something covered by the test suite so > can't be tested to ensure it really doesn't break anything ("I can't see how > this could possibly break anything" are some famous last words, and believe > me I've said them myself), and it seems like a bit of an edge case (I > haven't heard a lot of people needing to put code in a project's __init__.py > file) all of which argue to me that it might not be a good candidate for > 1.0.1. But that's just me, and it is only two days old. Famous last words, indeed. Can you see any way that setting DJANGO_SETTINGS_MODULE *before* importing the project module could break existing code? Wouldn't that mean that manually setting DJANGO_SETTINGS_MODULE before calling any management commands would also be broken? :) As you say, this one is not so easy to test that it won't break anything else (at least, I don't know how). Although it is easy to reproduce. Cheers. Tai. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
