You only say that because you assume private and protected give you a
security that they actually don't. They certainly make it more difficult
to *spot* the security errors.

regards
  Steve
--
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC                     www.holdenweb.com
PyCon TX 2006                          www.pycon.org

On 9/28/05, could ildg <could....@gmail.com> wrote:

My convention, attributes with names prefixed with a single underscore
are private. There's nothing to stop anyone using these, but, well, if
you take the back off the radio, the warranty is void.

If *real* private and protected are *enforced*, Python will be the
poorer for it. See
<http://groups.google.com/group/comp.lang.python/msg/b977ed1312e10b21>.

--
Cheers,
Simon B,
si...@brunningonline.net,
http://www.brunningonline.net/simon/blog/

On 28/09/2005, at 11:05 PM, Simon Brunning wrote:

I'm not sure why I haven't seen this mentioned yet, but a leading  
double-underscore does really make a member private:

 >>> class f(object):
...   def __init__(self):
...     self.__f = 1
...
 >>> a = f()
 >>> a.__f
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
AttributeError: 'f' object has no attribute '__f'
 >>> dir(a)
['__class__', '__delattr__', '__dict__', '__doc__',  
'__getattribute__', '__hash__', '__init__', '__module__', '__new__',  
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__',  
'__weakref__', '_f__f']

As you see, it's there in the dict, but it's obfuscated - but that's  
all that other languages do anyway.  Anyone that takes advantage of  
that to get hold of members like this should have a very good reason  
for doing so.

Just think of a single leading underscore as protected, and double  
leading underscores as private, and you'll be fine.  As Simon said,  
people can still access these, but the consenting adults rule applies.

=Tony.Meyer

On 9/28/05, Simon Brunning <simon.brunn...@gmail.com> wrote:

*By* convention, not *my* convention!

--
Cheers,
Simon B,
si...@brunningonline.net,
http://www.brunningonline.net/simon/blog/

No, that's false: in languages like Java, private variables are
actually private, and if functions in other classes can get to them,
it's an error in the Java implementation.  The security of things like
browser sandboxes depends on the privacy being enforced.

Python used to have something called Bastion which was intended to do
the same thing, but it didn't work and was removed.

On 9/28/05, Tony Meyer <t-me...@ihug.co.nz> wrote:

I thought about it, but I didn't mention it in the end because this
feature ("name mangling") isn't intended as a mechanism for making
things private - it's intended to prevent namespace clashes when doing
multiple inheritance. It can be used to make things private, true, but
that's abusing the feature, just as using __slots__ as a way of
"declaring variables" is an abuse - (__slots__ is a memory
optimisation feature).

--
Cheers,
Simon B,
si...@brunningonline.net,
http://www.brunningonline.net/simon/blog/

Good explanation.

For some reason, the original post never made it to my newsreader, so
apologies for breaking threading by replying to a reply when I mean to
answer the original post.

Do you know any language that has real private and protected attributes?

There may be some. I don't know. But anyone who says "C++" is fooling
themselves:

#define private public

And your "real private and protected" objects are no longer private or
protected.

That's a wonderful, if long, essay. I don't think the author is wrong, but
I think his choice of terminology does Python a disservice (it is hard to
argue in favour of anarchy and chaos even to enlightened sensible
managers, let alone old dinosaurs and control-freaks).

It is too easy to mistakenly read that essay as saying that Python finds a
middle ground between two binary opposites of control and chaos. That's
not the case: chaos is a privative, not an actual thing. Chaos is what
you have when you have zero control. The question should be, how much
control a language needs: control is a continuous variable, not a binary
on/off state. Less control gives more flexibility. More control reduces
opportunities.

That's a minor quibble really, the essay is grand and should be read by
all developers.

--
Steven.

Java?

On 28 Sep 2005 05:06:50 -0700, Paul Rubin

Oh, there are ways around private and protected, even in Java. CGLIB
spings to mind. But you'd be wise to follow the rules, especially if
you work in a team.

When writing Java, I write Java. When writing Python, I write Python.

--
Cheers,
Simon B,
si...@brunningonline.net,
http://www.brunningonline.net/simon/blog/

On 9/28/05, Steven D'Aprano <st...@removethiscyber.com.au> wrote:

That's the Martellibot for you. Never use a word where a paragraph
with explanatory footnotes will do.

Sigh. I miss him on c.l.py.

--
Cheers,
Simon B,
si...@brunningonline.net,
http://www.brunningonline.net/simon/blog/

I don't see anything on the CGLIB web page (in about 1 minute of
looking) that says it can get around private and protected.  It looks
like something that disassembles class files and reassembles them into
new classes from them with additional interfaces.  That's a lot
different than being able to reach into an already-existing class
instance and get at its private variables.

The Sun JVM has some setting that turns off strict enforcement but
with enforcement on, private is supposed to be private.  The whole
concept of applet security depends on that.

Steven D'Aprano a écrit :

#undef private

:)

On 28 Sep 2005 05:35:25 -0700, Paul Rubin

I've never directly used CGLIB myself, but I do use JMock and
Hibernate, and AFAIK both use CGLIB to modify private and protected
members. I could certainly be wrong, though. Anyway, this is getting a
bit OT...

--
Cheers,
Simon B,
si...@brunningonline.net,
http://www.brunningonline.net/simon/blog/

Python IS perfect.  Each new release makes it MORE perfect.  :)

There are two philosophies about programming:

-- Make it hard to do wrong.

-- Make it easy to do right.

What you are promoting is the first philosophy: Tie the programmer's
hands so he can't do wrong.  Python for the most part follows the
second philosophy, making writing good code so easy that the coder
is rarely tempted to commit any evil.

Like I said, Python IS perfect.

-- Chris.

On 28/09/2005, at 11:54 PM, Paul Rubin wrote:

I didn't say *all* other languages, and I meant many other languages,  
although that's not clear from what I wrote.

=Tony.Meyer

Unless you can show that all Python code is bug-free, you've got to
consider that there might be something to this private and protected
stuff.  See for example this message:

  http://groups.google.com/group/sci.crypt/msg/59516419dc874e63?dmode=s...

Name mangling is a poor substitute for private variables.  If you want
to be able to share private variables with other classes under certain
circumstances, it's better to use something like C++'s "friend"
declaration, where you can export the variables to a specific other class.

On 28/09/2005, at 11:55 PM, Simon Brunning wrote:

That's not what the documentation says:

"""
9.6 Private Variables

There is limited support for class-private identifiers.
[...]
Name mangling is intended to give classes an easy way to define  
``private'' instance variables and methods,
[...]
"""

<http://docs.python.org/tut/node11.html>

=Tony.Meyer

On 9/28/05, Tony Meyer <t-me...@ihug.co.nz> wrote:

So, either the docs are wrong, or I am. You be the judge. <wink>

--
Cheers,
Simon B,
si...@brunningonline.net,
http://www.brunningonline.net/simon/blog/

On Wednesday 28 September 2005 08:32 am, Paul Rubin wrote:

Of course, "unless you can show that all Java code is bug-free, you've got
to consider that this private and protected stuff might be bunk", too. ;-)

"never", "always", "-free" are very dangerous concepts. :-)

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com

Note that the quoted article only applies to *writing* attributes. It
doesn't say anything about needing accessors to *read* a
variable. This encourages me that the convention I use - adopted from
Eiffel, where the compiler enforces it - of freeling reading
attributes, but providing methods to write them - is a right way todo
things.

        <mike
--
Mike Meyer <m...@mired.org>                        http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Paul Rubin schrieb:

That assumes that you always know for sure that the given variable will
always be used as a private/friend variable in the lifecycle of the
software.

Software is too complictated to know everything in advance.
"Software lives" and totalitarian laws destroy easy living.

--
Greg

the sentence you're quoting the first part of continues:

    without having to worry about instance variables defined by derived
    classes

and the paragraph later says:

    Note that the mangling rules are designed mostly to avoid accidents

and both sentences are from the *tutorial*, which doesn't exactly
qualify as a design document.  if you want more rationale, here's the
post that led to the current design:

http://groups.google.com/group/comp.lang.python/msg/e79f875059d9a2ba

    "In my version, private data has it's own scope, so that name clashes
    will not occur if a private with the same name is used in a subclass."

see the rest of that thread for more about the history of __.

</F>

As long as the values are stored in memory, there's always a way to
alter and access them. So, IMHO, no program can have truely
private/protected values.

Obviously if you find you need to use it in another place later, you
update the declaration.  The idea is for you (or an automatic tool) to
be able to find all the uses of some instance variable.  In Python
(because of things like setattr), that can't be done.