Tricky Areas in Python

[Steven D'Aprano]

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.