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

[Bengt Richter]

On 03 Oct 2005 00:22:22 -0700, Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:

>"El Pitonero" <pitonero at gmail.com> writes:
>> The thing is, there are two sides to every coin. Features surely can
>> be viewed as "goodies", or they can be viewed as "handcuffs".
>
>Let's see, say I'm a bank manager, and I want to close my cash vault
>at 5pm today and set its time lock so it can't be opened until 9am
>tomorrow, including by me.  Is that "handcuffs"?  It's normal
>procedure at any bank, for good reason.  It's not necessarily some
>distrustful policy that the bank CEO set to keep me from robbing the
>bank.  I might have set the policy myself.  Java lets me do something
>similar with instance variables.  Why is it somehow an advantage for
>Python to withhold such a capability?
>
>> Sure, in these very dynamic languages you can ACCIDENTALLY override
>> the default system behavior. How many Python programmers have once
>> upon a time done stupid things like:
>> list = 3
>
>That's just a peculiarity, not any deep aspect of Python.  Try it for
>'None' instead of 'list':
>
>    >>> None = 3
>    SyntaxError: assignment to None
>
>Why is 'list' somehow different from 'None'?  I'd say there's a case
>to be made for having the compiler protect 'list' and other builtins
>the same way it protects 'None'.  Python won't be any less dynamic
>because of it.
>
I think I can write you a custom import that will prevent the assignment of
a list of names you specify in the code of the imported module. Would that
be useful? Or would it be more useful to put that detection in py/lint/checker/etc
(where it probably already is?)?

Would you want to outlaw 'None' as an attribute name?
Python seems to be straddling the fence at this point:

 >>> class C(object): pass
 ...
 >>> c = C()
 >>> c.None = 'c.None'
 SyntaxError: assignment to None
 >>> vars(c)['None'] = 'c.None'
 >>> c.None
 'c.None'

;-)


>> The upside is exactly the same as the fact that you can override the
>> "list()" function in Python.  Python is dynamic language. 
>
>That's not exactly an upside, and it has nothing to do with Python
>being dynamic.  C is static but you can override 'printf'.  Overriding
>'list' in Python is pretty much the same thing.
>
>> In Python, if you have a private variable:
>> 
>> self._x = 3
>> 
>> and you, for curiosity reasons and DURING runtime (after the program is
>> already up and running) want to know the exact moment the self._x
>> variable is accessed (say, print out the local time), or print out the
>> calling stack frames, you can do it. And I mean the program is running.
>
>So let's see:
>
>  def countdown():
>    n = 3
>    while n > 0:
>       yield n
>  g = countdown()
>  print g.next()  # 3
>  print g.next()  # 2
>
>where's the Python feature that lets me modify g's internal value of n
>at this point?  How is that different from modifying a private
>instance variable?  "Python feature" means something in the language
>definition, not an artifact of some particular implementation.  Is
>Python somehow deficient because it doesn't give a way to do that?  Do
>you want to write a PEP to add a way?  Do you think anyone will take
>it seriously?
I could see it as part of a debugging interface that might let you mess more
with frames in general. I wouldn't be surprised if a lot of the under-the-hood access
we enjoy as it is was a byproduct of scratching debugging-tool-need itches.

Regards,
Bengt Richter