On Mar 15, 8:56 am, "Rhodri James" <rho...@wildebst.demon.co.uk> wrote: > On Sun, 15 Mar 2009 13:26:17 -0000, Matthew Woodcraft > > <matt...@woodcraft.me.uk> wrote: > > [snip Gary Herron's explanation of instance attribute lookup > falling back to class attribute lookup] > > > It seems clear to me that Maxim understood all this when he asked his > > original question (you need to understand this subtlety to know why > > the trick he was asking about only works for immutable values). > > It seems equally clear to me that Maxim didn't understand any of this > when he asked his original question, since he appeared to view class > attributes purely as initialisers. > > Given that either of us could be right, Gary's assumption of less > understanding rather than more is clearly the safer one to take. > > -- > Rhodri James *-* Wildebeeste Herder to the Masses
It's interesting Rhodri chose the safety dimension as the deciding factor: Gary's assumption might have other faults, but it's safer, and (by Grice's maxim of quantity,) therefore better. In it's form: M: Safer is better. m: Gary's assumption is safer. C: Gary's assumption is better. There are two empirical claims, specifically the major and minor premises. It's not clear that either is true, but I think it's a mistake to make a blanket judgment of net safety between competing goods. Long story short, it's safe for our pride, by cutting down outsiders, but it's not safe for our publicity. As for the discussion, Gary said it: 'self.list = self.list + [i]' is a private write, but has other dangers such as running time and stored references. However, in my (opined) interpretation, 'list.append(...) is an in- place operation' is a factual error. In-place operations -also- rebind their 'argument' (FLOBW for lack of better words). 'append' is a by-side-effect operation. However colloquially it's mostly accurate. And to the OP, your method works for immutable class members, and even certain uses of mutable ones. -- http://mail.python.org/mailman/listinfo/python-list
