On Sun, 2007-09-09 at 21:46 +0800, Russell Keith-Magee wrote: > On 9/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > > On Sun, 2007-09-09 at 15:58 +0800, Russell Keith-Magee wrote: > > [...] > > > - I'm also inclined to continue the similarities, and make the > > > assertion functions members on BaseForm. This would allow a > > > significant simplification of your proposal, as the data locations > > > (i.e., self.cleaned_data) can be implied. > > > > I'm not sure I understand this. Are you proposing putting some methods > > into newforms.forms.BaseForm that only exist for supporting the test > > framework? I'm usually not in favour of that type of change because it's > > leaking stuff from the test framework, which is ideally entirely > > independent of core functionality, into the core. > > No - this has nothing to do with the test framework. It's a set of > helper functions to support writing clean_XXX methods.
Okay. Then I'm mostly in agreement, except that I have two small problems with your "for consistency arguments": (1) They shouldn't be called "assertXYZ". Assertions are typically things that should never, ever fail. It's a programming error if they do. Passwords failing to match are not assertion failures. That's just a normal error checking path. It's correct to use "assert" in tests, since it's a failure if they aren't true. But I wouldn't want to encourage using that word in normal code that is expected to fail from time to time outside of the program's control. (2) We should use Django's normal naming scheme (underscores, etc), rather than camel case, because it's core code, so the author is not going to be thinking about how the unittest module names things. The fact that the unittest framework uses camel case is because it was modelled on JUnit. For functions that are useful in core, we should follow our standard naming practice. I feel that if we don't, people are continually going to be wondering whether the function is "normal" or has "that funky punctuation like the test code". Consistenty is important. However, I think you've focused on being consistent with the wrong piece of code; they will be used in normal code, so they should look like normal code, not stuff that has to conform to unittests slightly different naming standards. Once you move away from using "assert", confusion with the unittest names will fade and the methods will be more self-explanatory. Maybe call them validate_equal(), validate_not_equal(), etc. Regards, Malcolm -- Quantum mechanics: the dreams stuff is made of. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" 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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
