On Sat, Oct 2, 2010 at 12:49 PM, Russell Keith-Magee <russ...@keith-magee.com> wrote: > Python classes have state. People *will* assign variables to self, > because that's something they have done with every other Python class > in existence. And as soon as their code hits production, their code > will break, in unpredictable ways. Claiming that users should > RTFM/should know better isn't an acceptable excuse in this case, IMHO. > When an API will break when you use it in the obvious way, that isn't > something you can hide in documentation and say "we told you so".
Classes that represent real objects have state. Like cars have color, make and registration number, your models have attributes that differentiate them from other objects of same class. "Utility" classes (usually singletons) that represent a function (service) should not have state. Imagine walking into a bank and talking to a clerk. She asks for your name and purpose. You say you want to withrdraw some money. She then walks up to a giant whiteboard, wipes it and writes your name and your bank account number there. Then she yells "Joooeeeey" and walks away. But until Joey appears to give you money, you see another clerk walk up to the whiteboard, wipe your data and replace it with John Doe. She then proceeds to exclaim "Joooeeeey" and walks away. That's what a stateful view is :) -- Patryk Zawadzki -- 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.
