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