Why self?

[Tim Hammerquist]

Alex Martelli graced us by uttering:
> Robb Shecter wrote:
[ snip ]
>> Sounds like a difference in design philosophies.  In my code, private
>> everything is the norm, with a very thin/small public API.
> 
> Wise artisans learn a tool's strengths and use those strengths rather
> than fighting against the tool.  Your "design philosophy", *actively*
> _hiding_ information, may be OK with other languages (one could
> do a lot of debate about that -- see later for a start), but it's
> definitely not the most productive way to use Python (or several other
> tools with similar underlying philosophies).

Agreed. How many more times must we see, "Why can't Python be more like
X?"  If the desired feature of language X is valuable enough, it may be
worth simply using language X instead.

OTOH, one can always take a cue from Guido himself: create your own
language.

> What I see as the fallacy of "information hiding" as an active purview
> (having pursued it diligently for lo those many years) is that it
> reflects and responds to an assumed underlying "pecking order" which,
> upon reflection, is not a best fit for most projects.

Though admittedly a weak analogy, this rings of a certain software
company's claim of security through obscurity.  Anyone attempting to use
a security hole in an application to criminal ends is probably not above
decompiling a Redmond binary (which is also illegal) to discover/exploit
the security hole.

Trusting a language structure to protect against malicious or simply
incompetent users is bad design, and is likely to inhibit flexibility.
To the truly intent or truly clueless, strict typechecking (a la C/Java)
protects against misuse about as much as Python's __instancevar munge
technique.

> Alex

My $0.02,
Tim Hammerquist
-- 
guru, n: a computer owner who can read the manual.