[Types-sig] private names (was: Type Inference II)

[Greg Stein]

I just wanted to jump in with a "me too!" :-)

On Mon, 20 Dec 1999, Laurence Tratt wrote:
> In message <385AE827.42ECB891@maxtal.com.au>
>           skaller <skaller@maxtal.com.au> wrote:
> > I note python currently supports privacy by name mangling, but really,
> > this is a hack: for Python 2, a more sophisticated architecture would be
> > better.
> 
> Nnngg. I'm not keen on Python ever gaining privacy (the __ name mangling is
> nasty, I agree). It just doesn't really seem in the spirit of things; I
> always tend to think of the Larry Wall quote "Perl would rather you kept out
> of its living room because you weren't invited, not because it has a
> shotgun".

That's an excellent quote :-). I agree. Guido has always phrased it as
"we're all adults here [so we know what to do and what not to do]."

But I agree: I never really liked the __ name mangling. I liked relying on
adulthood.

However, there was a secondary reason for the mangling, not just privacy.
It was added to help prevent conflicts between super/subclass' use of
attributes. Personally, I think that Python is transparent enough that a
subclass is going to know what attributes its parent class uses and will
avoid those.
[ this may also be a result of my tendency towards shallow hierarchies ]

> In my recent projects, I denote "private" (there's no distinction between
> private, protected etc as there is in, say, Java) by just preceeding names
> with a "_". I've actually found that highly effective, and it makes it
> obvious that "self._method()" and so on are private calls. This approach
> also tends to make modules fairly "from module import *" safe.

Same here.

> The only argument I can imagine for privacy is that "from module import *"
> tends to import module names etc as well which can make it confusing; but
> when we use that feature we deserve everything we get <wink>.

Absolutely! IMO, the construct should just go away.

I do believe that the following is goodness:

   from deep.package import subpackage

   subpackage.somefunc()

In this case, you are still importing a module, but you've stripped down
some of its hierarchy for easier access. But you *don't* import "somefunc"
directly, because then you would lose the "subpackage." when you call the
thing. I believe that people should always use "module.foo" references
rather than just "foo". About the only exception that I make for this is
with the "types" module.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/