Does Python really follow its philosophy of "Readability counts"?
Mark Wooding
mdw at distorted.org.uk
Sun Jan 25 20:49:08 EST 2009
"Russ P." <Russ.Paielli at gmail.com> writes:
> On Jan 25, 10:04 am, Mark Wooding <m... at distorted.org.uk> wrote:
>
> But what if you type "mumble._seekrit" in several places, then the
> library implementer decides to give in to your nagging and makes it
> "public" by changing it to "mumble.seekrit".
There's a possibly better fix: introduce a property `seekrit' (or
perhaps a better name!) which diddles the _seekrit attribute under the
covers.
> Now suppose you forget to make the corresponding change somewhere in
> your code, such as
>
> mumble._seekrit = zzz
>
> You will get no warning at all. You will just be inadvertently
> creating a new "private" attribute -- and the assignment that you
> really want will not get done.
True. That's a shame. It'd be nice if there were a way to fix that.
There's this __slots__ thing I keep hearing about...
> For that matter, the library implementer himself could make the same
> mistake and get no warning.
He could do. Why he didn't do a search and replace like any sensible
person is a mystery. Testing is good, too.
> When you think about it, you soon realize that the leading underscore
> convention violates the spirit if not the letter of one of the first
> principles of programming 101: if you have a constant parameter that
> appears in several places, assign the literal value in one place
> rather than repeating it everywhere.
You mean `once and only once'. Yeah, I like that one too.
> Then if you need to change the value, you only need to change it in
> one place. That reduces effort, but more importantly it reduces the
> potential for error. The same principle applies to "declaring" an
> attribute private.
Introducing a property hides the problem, but doesn't actually solve it,
because you're right on this. Fortunately the problem doesn't actually
come up that often. But yes, basically, I agree with you on this
particular point: it's easier to add an alias than to rename, which
avoids the problem but is error prone.
-- [mdw]
More information about the Python-list
mailing list