You are right, I should have tried out the trunk much earlier. And I agree that Python is a language for consenting adults (ad pretty much everything you said) so I won't hash it out. I went outside the interface, and now I have to deal with it.
I think this came about because I really never communicated the "field based save" paradigm (discussed in my previous response) that I am trying to implement in an effective way. I did mention it in bug posts, but the developer response always focused on the details of the "bug" I was reporting, and never on the paradigm. Perhaps i didn't describe the paradigm well enough. For example, take a look at http://code.djangoproject.com/ticket/12337, which relates to me trying to change exclude dynamically. In that bug I did try to describe the field-based save paradigm I was trying to implement, but I didn't get anywhere. Perhaps I was to focused on the details of the "bug", and instead I should create a more general ticket that discusses the paradigm I am trying to implement? It just hasn't seemed like I've gotten any sort of acknowledgement that this paradigm is useful. I don't know if that's because I haven't explained it well, or I haven't focused on it enough, or it's just too complex for folks to think about, or if everyone is just busy. No doubt some combination. Would you suggest I create a bug ticket that describes this "field based save" paradigm and asks if there is an interface we could develop to formalize it? I don't know exactly what that interface would be yet, so I feel like it would be somewhat premature for me to suggest the actual interface without some acceptance that the paradigm is a good one, but if folks think the paradigm is a good one, I would be happy to work on the interface. Thanks for your comments. Margie On Jul 13, 6:46 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > 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.
