Alex Martelli wrote: > I like to present code that seems like it should work, but has some kind > of relatively subtle problem, either of correctness in some corner case, > or of performance, etc -- and I ask them what they would say if they > were to code-review that code, or how they would help a student who came > to them with that code and complaints about it not working, &c.
[snip] > Not sure whether you think this count as "tricky"... they're typically > problems that do come up in the real world, from (e.g.): > for string_piece in lots_of_pieces: > bigstring += string_piece > (a typical performance-trap) to > for item in somelist: > if isbad(item): > somelist.remove(item) > (with issues of BOTH correctness and performance), to Those two are easy. However, and this is where I show my hard-won ignorance, and admit that I don't see the problem with the property examples: > class Sic: > def getFoo(self): ... > def setFoo(self): ... > foo = property(getFoo, setFoo) > to > class Base(object) > def getFoo(self): ... > def setFoo(self): ... > foo = property(getFoo, setFoo) > > class Derived(Base): > def getFoo(self): .... Unless the answer is "Why are you using setters and getters anyway? This isn't Java you know." Oh wait! Yes I do... the setter doesn't actually take an argument to set the property too. Is that it, or have a missed a cunningly hidden deeper problem? -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
