On Thu, 2007-05-17 at 10:52 -0400, Etienne Robillard wrote: > > I dont understand that changes. For me thats just odd, and > a royal pain to update lots of sites just for renaming clean_data to > cleaned_data.
It's good programming practice that when a backwards incompatible change is introduced (and sometimes they can't be avoided), potentially broken code does not keep working silently. Originally, I didn't follow this practice as well as I could have. John pointed out where it would be a problem in the exact fragment you quoted. Nobody came up with a better solution that preserved both backwards-compatibility for clean_data and non-silent breakage for existing code relying on the old, no longer present behaviour. > > I really think thats odd and a better rationale would take in consideration > that already working and defined functions should try to keep at least some > kind > of backward compatible hooks at least for being nice to users of clean_data! That was what we originally tried to do and it would lead to the silent failure that John pointed out. We have been quite up front about the fact that there will be backwards compatible changes to Django leading up to 1.0. They aren't incredibly common, but they sometimes cannot be helped. If you have code that is already running on Django and working correctly, that code isn't affected by these changes because you don't need to update the Django version it is running against. When you do want/need to update the underlying Django framework for a particular project, it will be because you are doing other development work anyway, so a global search and replace changing clean_data to cleaned_data is only 10 seconds extra work. We're not breaking backwards compatibility in security updates to 0.95/0.96 or anything like that, after all. By its very design, this change was designed to break code that hasn't been upgraded, so it's easy to tell when you have forgotten to do the upgrade because your tests will fail. > Why not incorporating the semantics or desired logic of cleaned_data into > clean_data, so > that at least that part of the newforms api would stay as in the > documentation ? The attribute "cleaned_data", which contains the normalised form data is quite different from the function clean_data() which takes unsanitised data and validates and normalises it. Combining those to together is not very good separation of purpose. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
