constant in python?

[Bernd Nawothnig]

On 19 Aug 2001 00:31:40 -0700, Paul Rubin <phr-n2001 at nightsong.com> wrote:

>  "Alex Martelli" <aleaxit at yahoo.com> writes:
>>> problem with enforcing privacy is that the designer can seldom
>>> anticipate all of the possible uses of their code and placing arbitrary
>>> access restriction can make it impossible for the user to accomplish
>>> their task.

Access restriction should never be used to arbitrarily prevent a user from
performing a task. The only idea behind restriction is to hide internal
details for having more stable code. If a class (by hiding details) is not
offering all the possibilities it clearly could offer, it is simply bad
designed (of course this happens). But to think removing all 'private' and
'protected' restrictions from such a bad designed class would really solve a
problem is foolish. You will only get deeper into the mess. One basic
priniple of OOP is providing a lot of methods - may be much more than you
actually need. Yes, good design isn't easy and nobody has ever said that OOP
alone is a guarantee for perfect code.

If you are missing feautures you can't easily implement, you should contact
the author - or use other code. Workarounds (or the possibility of doing so)
should never be a strong principle of software design. Almost every time one
is paying a high price for this behaviour - this may be years later.

The lack of access restriction possibilities should not be reinterpreted
into a feature. If it would be so ingenious _not_ to have them, a
substantial number of C++ programmers would put a 'public:' as first
statement in every class and never write a 'private:' or 'protected:'. I
never heard of this. It is a design decision to keep python simple and easy
to learn (and simplicity is a feature) - not more. One may say: "In my
opinion access restriction is not neccessary" - this is ok for many small
and medium projects. 

>> Hear, hear!  Designers aren't omniscient

They are not omniscient but they should have visions. And accepting these
visions and live and work with them (of course after choosing a suitable
design first) seems to me being far more better than using brute force and
quick hacks which only means: Only my point of view is right, nothing else
and my first choice would be programming against any idea which is not mine.

>> and a language that lets me workaround a limitation in the design of a
>> framework or library I need to use is just what I need.

> [...] the very existence of a workaround is sometimes itself a limitation,

Indeed. But this tends not to be seen by omniscient people :-)





Bernd