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

bruno modulix onurb at xiludom.gro
Mon Oct 3 12:44:11 EDT 2005


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. 

I'm sorry but you're just plain wrong - at least according to Python's
"we're all consenting adults here" philosophy.

> 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,

No, it's just an obvious side-effect of the programmer messing with
implementation stuff. He knew from the start it was implementation
detail, so he accepted that this may change without notice and break its
code. period.

> 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.

Nope. *you* think it's better. Most of us here obviously think that
relying on convention is a good (and even better) solution - and the
fact is that it works just fine.


-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"



More information about the Python-list mailing list