Protected Methods and Python

[Alex Martelli]

<posted & mailed>

srijit at yahoo.com wrote:

> I do not see a  concept of Protected Methods in Python 2.2 like C++ and

Right: you don't see it because it isn't there.

> Ruby. Is this a serious limitation for Object Oriented Programing with

Judge for yourself: the introduction of "protected" is one of the few
aspects of C++ which Stroustrup *regrets*, according to his excellent book 
on the design and evolution of the C++ programming language.

> Python? Or may be it is possible to emulated Protected Methods in Python.

To quote St. Paul out of context, everything is permissible, but not
everything is opportune.  And that is very much Python's philosophy:
rather than focusing on trying to make some things impossible (and
generally failing -- a simple cast in most implementations of C++ lets
you blast away any "protected" that a silly library designer may have
tried to impose on you;-), Python empowers and trusts the programmer.

At the recent ACCU (Association of C and C++ Users) conference in Oxford,
Greg Colvin gave a wonderful keynote speech titled "in the spirit of C".

The FIRST items on the list are to trust programmers, and not stand in 
their way.  I found it interesting that, while Greg doesn't even KNOW
Python (at least that's what he said more than once at the conference),
he was making a substantial part of the case for Python so well:-).

If you don't trust programmers' skills and good intentions, you should
not give them powerful tools at all -- then, C, C++, Java, Ruby, Python,
would ALL be totally inappropriate, as each of them is easily powerful
enough to let an unskilled or evil programmer make a horrid mess of
things.  If you DO trust programmers, then "not standing in their way",
letting them get the job done, is very important.

In practice, what happens in languages such as C++ or Java is a very
interesting, almost schizophrenic split -- the programmer is "trusted"
when he's WRITING a library or framework, but NOT trusted when he's
USING that library or framework.  The library designer must be so
omniscient as to KNOW all uses to which his code will be put, and in
particular what pieces of code, that he found useful and put in his
library, will NOT be useful to other programmers in slightly different
contexts.  The library user is presumed to be such an idiot that a
simple INDICATION of "this code is intended for internal library use
only" would not suffice -- nay, the using programmer must be "coerced"
to keep his grubby hands away from said code.  In practice, there is
no such split in the population of programmers -- authors and users
of libraries are drawn from the same pool.  The sociology implicit in
the language design just isn't a good match for reality.

In Python, the amount of trust vested in you, programmer, is just
about the same whether you're using an existing library or coding
up a new one (most of the time, you're doing both -- using some
existing libraries AND also producing code that you or somebody
else will want to reuse in the future in slightly different ways).

You indicate "this is meant for internal use only" by following the
convention of starting a name with a single underscore; you respect
that convention in libraries you use, unless you've got deucedly
good reasons not to (and can live with the consequences, such as
your code not working any more with a newer release of the library).

The latter possibility is basically the same thing as putting
#define private public
#define protected public
at the top of your .cpp file, before any #include, in most C++
implementations -- except that instead of this one lump reminder
that you're breaking conventions, you get reminded of the fact
throughout your code, whenever you refer to a name starting with
an underscore.

As for the specific indication "this name may be used by
derived classes but not by other code", there's never really any
particularly good reason for that (whence Stroustrup's regrets) --
public and private have reasons for existing (public is about
a library's interface to the world, private about its current
implementation), protected doesn't (no real need for a library
to distinguish SEVERAL "interfaces to the world" depending on
where inheritance is being used -- inheritance is just a tool
like many others and it's wrong to put it upon some altar...).


Alex