On Sat, Oct 2, 2010 at 7:05 PM, Patryk Zawadzki <pat...@pld-linux.org> wrote: > 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.
Ok, now show me keyword in Python that identifies a class as a "utility class". Or the page in the Python documentation where it talks about "utility classes" and how you identify them and use them properly. You can't, because Python doesn't make that distinction. Python has classes. Class instances have state. Period. People certainly write classes that are stateless. But providing a base API based around classes, encouraging people to subclass and add their own behavior, and expecting *documentation* to prevent them from using self is complete folly IMHO. An API that depends on an unenforced contract that you *don't* perform an action that is otherwise completely normal and accepted behavior is, in my opinion, prima facie broken. It rates somewhere between either a 3 and a -4 on Rusty Russell's API design scale [1][2], depending on how generous you're being. By my reckoning, the "init-disabled call+copy" rates somewhere in the 5-7 range. [1] http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html [2] http://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html > 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 :) Analogies only work when they: 1) make sense 2) are actually analogous. Neither of these appear to be the case here. The best way I can "fix" this analogy is to point out that every time you're walking into the bank, a completely new bank with a clean whiteboard is constructed for you, and you're the only patron who is allowed to use the bank before it is demolished. 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.
