On Tue, Jul 13, 2010 at 5:10 PM, Margie <margierogin...@gmail.com> wrote: > Hi developers, > > I would suggest considering making this new model validation code path > optional. IE, give users a way to stay with the old form validation. > Or better yet, keep the idea of model validation, but make it more > transparent by not actually saving the ModelForm to the instance. > It's hard for me to believe that no other developers have encountered > this same problem (the problem of having a ModelForm saved at a point > in the code where you have no control). But my app may very likely > present more dynamic and sophisticated functionality, used in a > heavily multiuser environment, than many apps that are developed, so > perhaps I am the only one that will have an issue with this.
Given the remainder of your message, this request is likely to get lost. I'd suggest raising this as a separate thread, wherein you just describe the specific use case and your proposed solution. > In any case, I hope this nail doesn't come across poorly. I respect > the Django developers immensly, but I just want to go on record by > lettting you know that you have at least one user that has been caused > a lot of pain by this change. I don't want to appear rude, but I'm not sure what response you're looking for. I'm not insensitive to the fact that you have code that requires refactoring as a result of the upgrade from 1.1 to 1.2. However, by your own admission, this was a problem of your own making. We have a documented interface. You're not using the documented interface. And as a result, code broke when you upgraded. Python is a language for "consenting adults" -- you have the liberty to modify the internals of anything you can see if you so wish. There's no such thing as a truly 'private' or inaccessible internal. However, just because you *can* tinker with the internals doesn't mean that it's good engineering practice to do so, or that it's our fault when that tinkering ends badly. > I also hope that you will accept me posting this on this "developers" > board. I think it is important that you get feedback from someone who > is using django heavily, in behalf of a large corporation. I find > that when I post tickets, if there is any hint of me doing something > out of the ordinary, that my ticket is always closed with the comment > that "I shouldn't be doing that". I understand that of course you > cannot accommodate everyone, and that you are working as volunteers > and I totally respect that. But there is little ability for someone > like me - basically one of your power users - to give feedback in any > sort of useful forum. So I hope you can spend a few moments thinking > about what it feels like to be in my shoes. Without a history of specific tickets to reference, it's difficult to say what has happened with your tickets in the past. All I can say is that in general terms, the way in which a ticket is phrased can make a big difference to the way it is handled. In this specific case, you claimed there was a backwards incompatibility. That's a pretty big stick to shake -- we take backwards compatibility seriously -- so when it was discovered that you were using a private API, you were shown that it wasn't a backwards incompatibility, and the ticket was closed. By contrast, if your ticket had asked for a specific interface to be formalized or exposed, including the reasons why that interface needed to be formalized, your ticket wouldn't have been shot down immediately. "X doesn't work" is a bug claim that is easy to refute. "It should be possible to do X" is a feature request that at least requires consideration. Of course, a feature request can still be shot down; that's why the very best way to propose a feature is to start with a discussion on Django-developers, so you get the eyes of the entire development community, and you can have an active discussion with that community. Even then, you may find that some features get rejected. Django can't be all things to all people. If you really do have extreme use cases, and your proposal is especially invasive or complex, you may find that we say "no" in the interests of keeping things simple for the 90% of users that don't have extreme use cases. And finally -- sometimes the rejection will be along the lines of "well, it might be a nice idea, but it's a complex issue and we're not intending to look that any time soon". In that case, you will often find that offering to help out (both with your specific itch, and with other related tickets) will grease the wheels immensely. > As django moves forward, I think it might be useful to find a way to > partner with corporate developers such that you get feedback like this > at an earlier point. While I try to keep an eye out for where things > are going with django, this change and it's impact on me just was not > at all clear. Django 1.2 was in development for 9 months. The feature you're describing was committed 5 months before the final release, and was in public development for *years* prior to that. We made several calls for public comment and feedback prior to the patch being merged in, as well as during the 5 months that the ticket was in trunk, including a full alpha, beta and RC release, and weekly calls for testing on our blog during the final release phase. What exactly do you think we should have done differently? Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
