Will python never intend to support private, protected and public?

[Steven D'Aprano]

On Wed, 28 Sep 2005 16:36:03 -0700, Paul Rubin wrote:

> Steven D'Aprano <steve at REMOVETHIScyber.com.au> writes:
>> No, but that is precisely why Python's semi-private variables are
>> usually better. Names like _X and class.__X are warnings to the developer
>> "use these at your own risk", without preventing developers who need them
>> from using them. You have most of the benefits of private variables with
>> none of the disadvantages.
> 
> I'm sorry but I thought the idea was to actually reduce the risk of
> bugs, not merely attach the risk to the right person.  If changing the
> way a class uses its own private variables breaks an application
> because another class was using the private variable unexpectedly,
> then that's bad, regardless of whether the other class's author was
> notified or not.  It's better to let the compiler automatically flag
> these things, than to depend on conventions.

Better for who? The idiot who doesn't take even a modicum of attention to
the class creator who warns "Use these variables with care because they
are subject to change without notice"?

Or better for the developers who were prevented from making careful,
intelligent use of the variables because of an misguided attempt to
protect them from changes to the code that may or may not ever take place?

You count the risk of bugs from semi-private variables, but you don't
count the cost of lost opportunities caused by preventing access to those
variables. Nor do you count the cost of "copy and paste" coding, both in
extra development time and extra maintenance.

Of course if you ignore the costs and lost opportunities of locked-down
private variables they will be "better".


-- 
Steven.