data hiding/namespace pollution

[Alex Martelli]

Alex Hunsley <lard at tardis.ed.ac.molar.uk> wrote:

> There's no really specific questions in this post, but I'm looking for
> people's thought on the issues within...
> 
> 
> The two main versions I've encountered for data pseudo-hiding 
> (encapsulation) in python are:
> 
> method 1:
> 
> _X  - (single underscore) - just cosmetic, a convention to let someone
>        know that this data should be private.
> 
> 
> method 2:
> 
> __X - (double underscore) - mangles the name (in a predictable way).
>        Avoids name pollution.
> 
> 
> How often does either tend to get used? Personally, I'd be a little 
> worried about using method 1, because namespace clashes could happen. Is
> this overly paranoid?

Experienced programmers who know little Python tend to start with (2),
and mostly migrate to (1) with time (once they've had to hand-mangle
names a few times to work around (2)'s limitations for testing or
overrides they had not foreseen).  Accidental name clashes between
superclasses and subclasses tend to be caught very rapidly by unit tests
that are at all decent, anyway.


> Also, I presume that rather than people writing their own manual getter
> and setter methods, they tend to use either overloading on __getattr__
> and __setattr__, or the Property class (which itself uses aforementioned
>   methods). Overloading __getattr__ etc. seems more attractive to me, as
> then I can capture access to unknown names, and raise an exception!

If you AVOID overriding __getattr__, THEN you'll automatically get
exceptions; __getattr__ is called only when, were it absent, the
exception would get raised.  property does NOT use __getattr__ at all,
but rather each instance thereof is a descriptor and thus uses its own
__get__.  __setattr__ has very different semantics and is appropriate
only in very peculiar circumstances.


> (I really don't like the idea of random attribute name typos going 
> unnoticed when accessing attributes in a class!)

A common but unjustified paranoia.  I've been coding almost exclusively
(say over 90% of my work) in Python for over 5 years, and also teaching,
consulting, mentoring &c based on Python, and all the possible
"typo"-level bugs that so terrify so many new-to-Python programmers are
simply irrelevant -- they're not common in the first place, pychecker
and the likes make short work of them, and unit tests (which ARE
indispensable in any language anyway) catch them easily just as they
catch the really nasty typos possible in any language such as typing -=
where one meant +=, < where one should have coded <= (the one most
likely tiny-bug in any language, since it can be a thinko ever more
easily than a typo -- it once took me three days debugging a Fortran
program for extremely subtle corner-case errors that boiled down to a
miscoding of .LT. where .LE. should have been), and the like.


If you manage to do a significant poll of the community, don't forget to
correlate respondents' opinions with each respondent depth and length of
experience with real-world Python use...


Alex