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

148 views
Skip to first unread message

Steve Holden

unread,
Sep 28, 2005, 6:56:06 AM9/28/05
to pytho...@python.org
could ildg wrote:
> Python is wonderful except that it has no real private and protected
> properties and methods.
> Every py object has dict so that you can easily find what fields and
> methods an obj has,
> this is very convenient, but because of this, py is very hard to support
> real private and
> protected?
> If private and protected is supported, python will be perfect.
>
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

Simon Brunning

unread,
Sep 28, 2005, 7:05:21 AM9/28/05
to Python Users
On 9/28/05, could ildg <coul...@gmail.com> wrote:
> Python is wonderful except that it has no real private and protected
> properties and methods.
> Every py object has dict so that you can easily find what fields and methods
> an obj has,
> this is very convenient, but because of this, py is very hard to support
> real private and
> protected?

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 private and protected is supported, python will be perfect.

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/

Tony Meyer

unread,
Sep 28, 2005, 7:15:05 AM9/28/05
to coul...@gmail.com, Python Users
On 28/09/2005, at 11:05 PM, Simon Brunning wrote:

> On 9/28/05, could ildg <coul...@gmail.com> wrote:
>
>> Python is wonderful except that it has no real private and protected
>> properties and methods.
>> Every py object has dict so that you can easily find what fields
>> and methods
>> an obj has, this is very convenient, but because of this, py is
>> very hard
>> to support real private and protected?
>
> 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.

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

Simon Brunning

unread,
Sep 28, 2005, 7:49:41 AM9/28/05
to Python Users
On 9/28/05, Simon Brunning <simon.b...@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.

*By* convention, not *my* convention!

Paul Rubin

unread,
Sep 28, 2005, 7:54:23 AM9/28/05
to
Tony Meyer <t-m...@ihug.co.nz> writes:
> I'm not sure why I haven't seen this mentioned yet, but a leading
> double-underscore does really make a member private:...

> As you see, it's there in the dict, but it's obfuscated - but that's
> all that other languages do anyway.

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.

Simon Brunning

unread,
Sep 28, 2005, 7:55:58 AM9/28/05
to Tony Meyer, Python Users
On 9/28/05, Tony Meyer <t-m...@ihug.co.nz> wrote:
> I'm not sure why I haven't seen this mentioned yet, but a leading
> double-underscore does really make a member private:

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

Paul Rubin

unread,
Sep 28, 2005, 8:01:13 AM9/28/05
to
Simon Brunning <simon.b...@gmail.com> writes:
> 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).

Good explanation.

Steven D'Aprano

unread,
Sep 28, 2005, 8:30:23 AM9/28/05
to
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.

On Wed, 28 Sep 2005 12:05:21 +0100, Simon Brunning wrote:

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

>> Python is wonderful except that it has no real private and protected
>> properties and methods.

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.

Simon wrote:

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

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.

Paul Rubin

unread,
Sep 28, 2005, 8:06:50 AM9/28/05
to
Steven D'Aprano <st...@REMOVETHIScyber.com.au> writes:
> Do you know any language that has real private and protected attributes?

Java?

Simon Brunning

unread,
Sep 28, 2005, 8:17:25 AM9/28/05
to pytho...@python.org
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.

Simon Brunning

unread,
Sep 28, 2005, 8:28:10 AM9/28/05
to pytho...@python.org
On 9/28/05, Steven D'Aprano <st...@removethiscyber.com.au> wrote:
> > 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>.
>
> That's a wonderful, if long, essay.

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.

Paul Rubin

unread,
Sep 28, 2005, 8:35:25 AM9/28/05
to
Simon Brunning <simon.b...@gmail.com> writes:
> 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.

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.

Christophe

unread,
Sep 28, 2005, 8:43:41 AM9/28/05
to
Steven D'Aprano a écrit :

> 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.
>
> On Wed, 28 Sep 2005 12:05:21 +0100, Simon Brunning wrote:
>
>
>>On 9/28/05, could ildg <coul...@gmail.com> wrote:
>
>
>>>Python is wonderful except that it has no real private and protected
>>>properties and methods.
>
>
> 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

#undef private

:)

Simon Brunning

unread,
Sep 28, 2005, 8:52:44 AM9/28/05
to pytho...@python.org
On 28 Sep 2005 05:35:25 -0700, Paul Rubin

<"http://phr.cx"@nospam.invalid> wrote:
> 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.

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

Chris Gonnerman

unread,
Sep 28, 2005, 9:14:50 AM9/28/05
to pytho...@python.org
could ildg wrote:

>If private and protected is supported, python will be perfect.
>

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.

Tony Meyer

unread,
Sep 28, 2005, 9:25:51 AM9/28/05
to pytho...@python.org
On 28/09/2005, at 11:54 PM, Paul Rubin wrote:

> Tony Meyer <t-m...@ihug.co.nz> writes:
>
>> I'm not sure why I haven't seen this mentioned yet, but a leading
>> double-underscore does really make a member private:...
>> As you see, it's there in the dict, but it's obfuscated - but that's
>> all that other languages do anyway.
>>
>

> No, that's false: [snip]

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

=Tony.Meyer

Paul Rubin

unread,
Sep 28, 2005, 9:32:13 AM9/28/05
to
Chris Gonnerman <chris.g...@newcenturycomputers.net> writes:
> -- 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.

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=source

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.

Tony Meyer

unread,
Sep 28, 2005, 9:29:29 AM9/28/05
to si...@brunningonline.net, Python Users
On 28/09/2005, at 11:55 PM, Simon Brunning wrote:

> On 9/28/05, Tony Meyer <t-m...@ihug.co.nz> wrote:
>
>> I'm not sure why I haven't seen this mentioned yet, but a leading
>> double-underscore does really make a member private:
>>
>

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

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

Simon Brunning

unread,
Sep 28, 2005, 10:06:06 AM9/28/05
to Python Users
On 9/28/05, Tony Meyer <t-m...@ihug.co.nz> wrote:
> That's not what the documentation says:

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

Terry Hancock

unread,
Sep 28, 2005, 11:26:28 AM9/28/05
to pytho...@python.org
On Wednesday 28 September 2005 08:32 am, Paul Rubin wrote:
> 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.

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

Mike Meyer

unread,
Sep 28, 2005, 11:28:32 AM9/28/05
to

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.

Gregor Horvath

unread,
Sep 28, 2005, 11:31:18 AM9/28/05
to
Paul Rubin schrieb:

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

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

Fredrik Lundh

unread,
Sep 28, 2005, 11:45:37 AM9/28/05
to pytho...@python.org
Tony Meyer 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.
>

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

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>

Message has been deleted

ncf

unread,
Sep 28, 2005, 12:43:49 PM9/28/05
to
> Do you know any language that has real private and protected attributes?
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.

Paul Rubin

unread,
Sep 28, 2005, 5:32:13 PM9/28/05
to
Gregor Horvath <g.ho...@gmx.at> writes:
> > 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.
>
> 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.

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.

Paul Rubin

unread,
Sep 28, 2005, 5:37:23 PM9/28/05
to
Mike Meyer <m...@mired.org> writes:
> 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.

Generally that sounds reasonable. Obviously there are other examples
when (e.g. for security) you have to make sure that variables can't be
read by other classes, e.g. you have a class that stores a capability
(or a password) in an instance variable, and uses it for privileged
operations.

Gregor Horvath

unread,
Sep 28, 2005, 5:56:28 PM9/28/05
to
Paul Rubin schrieb:

> Gregor Horvath <g.ho...@gmx.at> writes:
>
>>>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.
>>
>>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.
>
>
> 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

If its your code this is possible, but if not and the maintainer is not
willing or able to change it, then you have a problem.

The fact that in other languages there are wired tricks to get to
private instance variables is a strong indicator that there is a need
for that.

Guided freedom is better than enforced authority.

--
Greg

Paul Rubin

unread,
Sep 28, 2005, 6:23:07 PM9/28/05
to
Gregor Horvath <g.ho...@gmx.at> writes:
> If its your code this is possible, but if not and the maintainer is
> not willing or able to change it, then you have a problem.

Perhaps the maintainer has good reason for not wanting to change it.
After all, he's maintaining the code and you're not. In the course of
that maintenance he might change the internal usage of the private
variable that messes up the way you use it. He's supposed to be
allowed to do that--that's why the variable is private. Is he
supposed to get your permission every time he wants to change how the
private variables in his class work?

> The fact that in other languages there are wired tricks to get to
> private instance variables is a strong indicator that there is a need
> for that.

Java has some JVM switches that open ways to get at private variables
so things like debuggers can work. In production code you'd turn that
stuff off. And it's certainly not intended for normal classes in an
application to get at the private variables of other classes.

> Guided freedom is better than enforced authority.

The obvious way to provide that guidance is to declare variables to be
private if other classes shouldn't mess with the variables. There is
still the freedom to change the declaration if necessary. Unless of
course you don't have the source code. Where there is no source code,
there is no freedom, no matter what features the language has.

Mike Meyer

unread,
Sep 28, 2005, 6:35:50 PM9/28/05
to
Paul Rubin <http://phr...@NOSPAM.invalid> writes:

One of the advantages of avoiding boilerplate is that you avoid the
need to maintain it.

It's not clear that tracking all uses of a variable in Python can't be
done. It's clear that it's *difficult* - you have to track the objects
bound to both arguments for ever setattr call - but that's not the
same thing as impossible. My gut says "halting problem", but I haven't
proved it. Most other languages aren't that different - unless you
place serious restrictions on them. For instance, most languages will
let me pass a reference to an instance variable to a method of another
object. If that method then stores the reference in a global (or
class, or instance) variable, you suddenly have to track the value of
that new variable to figure out if the variable of interest is being
used whenever the new one is used. Which is pretty much the same place
you get with setattr.

Mike Meyer

unread,
Sep 28, 2005, 6:40:06 PM9/28/05
to
Paul Rubin <http://phr...@NOSPAM.invalid> writes:

If you can't trust the code that shares your address space, you're in
a world of hurt for security. Compile-time restrictions don't matter
for squat - you need serious restrictions on what the program can do
at runtime.

Steven D'Aprano

unread,
Sep 28, 2005, 7:33:51 PM9/28/05
to
On Wed, 28 Sep 2005 15:23:07 -0700, Paul Rubin wrote:

> Gregor Horvath <g.ho...@gmx.at> writes:
>> If its your code this is possible, but if not and the maintainer is
>> not willing or able to change it, then you have a problem.
>
> Perhaps the maintainer has good reason for not wanting to change it.
> After all, he's maintaining the code and you're not. In the course of
> that maintenance he might change the internal usage of the private
> variable that messes up the way you use it. He's supposed to be
> allowed to do that--that's why the variable is private. Is he
> supposed to get your permission every time he wants to change how the
> private variables in his class work?

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.

--
Steven.

Paul Rubin

unread,
Sep 28, 2005, 7:36:03 PM9/28/05
to
Steven D'Aprano <st...@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.

Paul Rubin

unread,
Sep 28, 2005, 7:39:32 PM9/28/05
to
Mike Meyer <m...@mired.org> writes:
> > Generally that sounds reasonable. Obviously there are other examples
> > when (e.g. for security) you have to make sure that variables can't be
> > read by other classes, e.g. you have a class that stores a capability
> > (or a password) in an instance variable, and uses it for privileged
> > operations.
>
> If you can't trust the code that shares your address space, you're in
> a world of hurt for security. Compile-time restrictions don't matter
> for squat - you need serious restrictions on what the program can do
> at runtime.

You need both.

Tony Meyer

unread,
Sep 28, 2005, 8:11:29 PM9/28/05
to Fredrik Lundh, pytho...@python.org
On 29/09/2005, at 3:45 AM, Fredrik Lundh wrote:

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

>> 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,
>> [...]
>> """
>

> the sentence you're quoting the first part of continues:
>
> without having to worry about instance variables defined by
> derived
> classes

That elaborates on the intent, it doesn't change it. The sentence
clearly says that the intent is to easily define private variables,
whereas Simon said that it the intent was not to provide a mechanism
for making variables private.

> and the paragraph later says:
>
> Note that the mangling rules are designed mostly to avoid
> accidents

That's explaining why you can still access the variables if you want
to, not saying that this feature isn't meant to be used to indicate
that a variable is private.

> and both sentences are from the *tutorial*, which doesn't exactly
> qualify as a design document.

A tutorial should not encourage users to use a feature in the wrong
way, though. If leading underscore(s) were not meant to indicate
privateness, then the tutorial should not state that - this is where
a large proportion of users learn Python; it's nonsensical to teach
them something that's incorrect.

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

Disagreeing with someone who actually took part in the discussion may
not be a sensible idea but...

It's pretty clear to me from that thread that using a single/double
underscore with variables *is* intended to indicate that the variable
is private in some fashion. As Guido pointed out:

'*leading* underscore has a long tradition (in the C world,
anyway, but we don't really want to ignore that here) of meaning
"internal use" (of some kind)'

<http://groups.google.com/group/comp.lang.python/msg/edecfde2141f642b>

The name mangling lets one use private variables without having to
worry about name clashes, but the purpose of the leading underscore
(s) is to indicate that the variable is private

"private seems to be useful because it offers a form of data
hiding that's currently absent in Python"

<http://groups.google.com/group/comp.lang.python/msg/593533b57662438f>

as many people in that thread indicated that they were doing before
this was proposed as an addition.

The OP wanted to know how to use private (and protected) variables in
Python. Even the FAQ has this answer:

'Variables with double leading underscore are "mangled" to provide
a simple but effective way to define class private variables.
[...]
This doesn't guarantee privacy: an outside user can still
deliberately
access the "_classname__spam" attribute, and private values are
visible
in the object's __dict__."

<http://www.python.org/doc/faq/programming.html#i-try-to-use-spam-and-
i-get-an-error-about-someclassname-spam>

Which is basically what I said in my reply to the OP. If this isn't
the intent, then there's a lot of incorrect documentation, and a lot
of incorrect c.l.p answers to this question in the past*.

=Tony.Meyer

* Well, there are no doubt a lot of incorrect c.l.p answers to any
question :). But anyway...

Mike Meyer

unread,
Sep 29, 2005, 12:54:24 AM9/29/05
to
Paul Rubin <http://phr...@NOSPAM.invalid> writes:

Yup. Any language besides Java even *try* to provide both for a
production environment? Lots of languages do runtime checking that can
be disabled for production compilation - which makes it's worthless in
this case.

Of course, at this point you're no longer talking about a general
purpose programming environment. Language design decisions that are
correct for this environment aren't necessarily correct for general
purpose programming languages. Trying to tweak some exiting general
purpose language to make it suitable for use in the kind of
environment where you can't trust the code you share your address
space with is the wrong way to go about it. You want to design such a
language to fit your secure environment, *after* you've designed that
environment.

At that point, things which are unrelated to the security of the
environment may be more attractive than they would be in a general
purpose programming language. A number of runtime checks have to be in
place to insure that semantics of the language stay "correct". Since
we're going to have those, I would like constructs I can use to ensure
that the semantics of the program stay correct, like function
entry/exit conditions, loop and object invariants, and so
on. Basically, the whole DbC thing.

Gregor Horvath

unread,
Sep 29, 2005, 12:58:27 AM9/29/05
to
Paul Rubin schrieb:

> allowed to do that--that's why the variable is private. Is he
> supposed to get your permission every time he wants to change how the
> private variables in his class work?
>

No, but the assumption here is that the maintainer / designer of a class
alaways knows everything and things are static. Unfortunatly this is
wrong in real live.

When you use a _ variable in python you know that this may break in the
future because of changing interfaces. Thats a typical engineering Trade
Off on my side.
One that is in other languages not even possible. A clear disadvantage.
Python gives me power and does not take it away like the others.


> stuff off. And it's certainly not intended for normal classes in an
> application to get at the private variables of other classes.
>

So is in Python. It is certainly not intended to use _ variables.
But you can do it, at your own risk. I do not need an authority that
forbiddes things, but one that guides in the correct direction without
coming in my way.
The engineering decisions regarding my application should be on my side,
not the language lawyers.


--
Greg

Paul Rubin

unread,
Sep 29, 2005, 1:07:56 AM9/29/05
to
Gregor Horvath <g.ho...@gmx.at> writes:
> No, but the assumption here is that the maintainer / designer of a
> class alaways knows everything and things are static. Unfortunatly
> this is wrong in real live.

I'd say it's pretty far removed from how multi-person software
projects actually work.

> When you use a _ variable in python you know that this may break in
> the future because of changing interfaces. Thats a typical engineering
> Trade Off on my side.
> One that is in other languages not even possible. A clear disadvantage.
> Python gives me power and does not take it away like the others.

Huh? If my car has a "feature" that lets someone blow it to
smithereens from hundreds of miles away without even intending to,
that's somehow an advantage?

> The engineering decisions regarding my application should be on my
> side, not the language lawyers.

No problem, but any decision like that should be expressed in
"writing", by re-declaring the variable so it's no longer private.

Fredrik Lundh

unread,
Sep 29, 2005, 1:11:10 AM9/29/05
to pytho...@python.org
Tony Meyer wrote:

> That elaborates on the intent, it doesn't change it. The sentence
> clearly says that the intent is to easily define private variables,
> whereas Simon said that it the intent was not to provide a mechanism
> for making variables private.

Are you aware of the fact that computer terms might have slightly different
meanings in different languages, due to differences in language details and
semantics? Of course they're "private variables", but they're "private" in the
Python sense, and they were added to Python to solve problems that were
observed in Python, not because someone thought it was important to cater
to confused C++ or Java programmers.

And as Simon said, and the original thread showed, the problem they were
(and are) intended to address is accidental namespace collisions when sub-
classing.

If we'd really needed "true" private variables, don't you think we would have
been able to come up with a design that provided that? It just wasn't important,
because Python is Python.

</F>

Gregor Horvath

unread,
Sep 29, 2005, 2:15:11 AM9/29/05
to
Paul Rubin schrieb:

>
> Huh? If my car has a "feature" that lets someone blow it to
> smithereens from hundreds of miles away without even intending to,
> that's somehow an advantage?

I would not accept a car that does constraint my driving directions. I
want to drive for myself, because its fun.

>
> No problem, but any decision like that should be expressed in
> "writing", by re-declaring the variable so it's no longer private.

Remember, its Python not Java.
Tastes are different and so are programming languages, but please do not
make Python to a Java Clone.

I love python because of its simplicity, freedom, power and because its
fun to program.
One reason is that it does not restrict the programer to tight und has
genuine simple solutions, like the one with "private" instance variables.

--
Greg

Paul Rubin

unread,
Sep 29, 2005, 2:37:54 AM9/29/05
to
Gregor Horvath <g.ho...@gmx.at> writes:
> One reason is that it does not restrict the programer to tight und has
> genuine simple solutions, like the one with "private" instance
> variables.

If you don't want the compiler to make sure your private instance
variables stay private, then don't declare them that way. You're the
one asking for less flexibility.

Kay Schluehr

unread,
Sep 29, 2005, 2:39:06 AM9/29/05
to

Steve Holden wrote:
> could ildg wrote:
> > Python is wonderful except that it has no real private and protected
> > properties and methods.
> > Every py object has dict so that you can easily find what fields and
> > methods an obj has,
> > this is very convenient, but because of this, py is very hard to support
> > real private and
> > protected?
> > If private and protected is supported, python will be perfect.
> >
> 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.

Honestly I like to use private/protect/public modifiers in C++ for the
sake of code documentation. I like to know which attributes are
dedicated to be known by other objects, which ones are for internal use
only and which ones should be at least publicly accessible within a
class hierarchy. This helps structuring code in the large and spotting
attention. Code becomes easier accessible. But if we have Sunday or I
get asked by serious programmers I also know the right technical
answers about protection rights, security etc.

Kay

Message has been deleted

Paul Rubin

unread,
Sep 29, 2005, 3:49:47 AM9/29/05
to
Dennis Lee Bieber <wlf...@ix.netcom.com> writes:
> Ah, but in the way of your code -- it is not "your car"... It is the
> car you supplied to someone "hundreds of miles away"... And they are
> perfectly free to open the hood... tamper with the engine programming, etc.

I don't understand what you're getting at. If they're free to edit
the code, then why should they complain about private variables? They
can change the declaration if they need to.

Gregor Horvath

unread,
Sep 29, 2005, 4:47:07 AM9/29/05
to
Paul Rubin schrieb:

>
> If you don't want the compiler to make sure your private instance
> variables stay private, then don't declare them that way. You're the
> one asking for less flexibility.

I want to declare them as privat, but want to give the flexibilty to
access them at the users own risk.

Declaring everything as public is nonsene, because there should be a
garanteed stable interface.

--
Greg

Paul Rubin

unread,
Sep 29, 2005, 4:57:07 AM9/29/05
to
Gregor Horvath <g.ho...@gmx.at> writes:
> > If you don't want the compiler to make sure your private instance
> > variables stay private, then don't declare them that way. You're the
> > one asking for less flexibility.
>
> I want to declare them as private, but want to give the flexibilty to

> access them at the users own risk.

What else do you want to let users do at their own risk? Treat
integers as pointers, like in C? Both are violations of type safety.

> Declaring everything as public is nonsene, because there should be a
> garanteed stable interface.

You could have a "friend" declaration like in C++, if you want to let
some class see the private instance variables of another class.

I can't think of a single time that I've ever seen a legitimate use of
name mangling to reach from one class into another in a Python
application (I don't count something like a debugger). If you're got
some concrete examples I wouldn't mind looking.

en.kar...@ospaz.ru

unread,
Sep 29, 2005, 6:07:48 AM9/29/05
to pytho...@python.org
On Wed, 28 Sep 2005 08:14:50 -0500
Chris Gonnerman wrote:

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

So it is for the very this reason there is no assignment operator in the
Python?

--
jk

Gregor Horvath

unread,
Sep 29, 2005, 6:52:48 AM9/29/05
to
Paul Rubin schrieb:

>
> You could have a "friend" declaration like in C++, if you want to let
> some class see the private instance variables of another class.

Everything is said on this topic. There are two ligitimate solutions to
the problem of private instance variables. Its a matter of taste, and
mine is the pythonic one.

--
Greg

Paul Rubin

unread,
Sep 29, 2005, 7:22:14 AM9/29/05
to
Gregor Horvath <g.ho...@gmx.at> writes:
> Everything is said on this topic. There are two ligitimate solutions
> to the problem of private instance variables. Its a matter of taste,
> and mine is the pythonic one.

The Pythonic solution is to have both solutions available, and Python
in fact used to have both (name mangling and the Bastion class). But
Bastion turned out not to work, and it's not easy to fix that under
CPython, so it was removed. Now the Bastion class is gone, and only
name mangling is left. Maybe Bastion can come back under Pypy.

Steve Holden

unread,
Sep 29, 2005, 7:30:11 AM9/29/05
to pytho...@python.org
If you are really asking whether assignment was deliberately designed as
a statement rather than an operator, the answer is "yes".


http://www.python.org/doc/faq/general.html#why-can-t-i-use-an-assignment-in-an-expression

Note also that the Python alternative is now rather out of date: rather
than writing

while True:
line = f.readline()
if not line:
break
...do something with line...

We would nowadays write

for line in f:
...do something with line...

which seems to feel quite natural to most Python programmers.

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

Steve Holden

unread,
Sep 29, 2005, 7:33:24 AM9/29/05
to pytho...@python.org

[psst ... do you think they've stopped now?]

Paul Boddie

unread,
Sep 29, 2005, 9:41:48 AM9/29/05
to
Paul Rubin wrote:
> 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.

The problem with Python's compiler as it is today is that it can't
generally detect private attribute access: information about an
object/class being accessed is only guaranteed to be available at
run-time. Of course, Bastion and its peers [1] "solve" this by
introducing run-time environments which seek to guarantee attribute
privacy.

As for the merits of private/protected/final attributes and methods,
I've seen enough time-wasting and premature "security" optimisations to
know that such facilities can also waste a tremendous amount of time in
multi-person projects.

Paul

[1] At EuroPython there was a talk about protecting object attributes
in Ubuntu Launchpad [2], for which the slides are apparently
unavailable, and while chatting about this later on I noted that I'd
seen something like it before. The realisation that mxProxy [3] was
this apparently often overlooked thing occurred more or less
simultaneously with the realisation that I was talking to its author.
:-)

[2]
http://www.python-in-business.org/ep2005/talk.chtml?talk=1610&track=692

[3] http://www.egenix.com/files/python/mxProxy.html

Steven D'Aprano

unread,
Sep 29, 2005, 10:16:02 AM9/29/05
to
On Wed, 28 Sep 2005 22:07:56 -0700, Paul Rubin wrote:

>> One that is in other languages not even possible. A clear disadvantage.
>> Python gives me power and does not take it away like the others.
>
> Huh? If my car has a "feature" that lets someone blow it to
> smithereens from hundreds of miles away without even intending to,
> that's somehow an advantage?

Funny you should mention that.

The other day I stopped at a service station to fill up. I noticed a line
of cars at a bowser over in the corner. The bowser was wrapped in a big
yellow tape saying "Caution!!! Warning!!! Experimental Petrol, for private
use only!!! USE AT OWN RISK!!! CAUTION CAUTION CAUTION Read the Manual
Before Using!!!"

So naturally I filled up with my car with this private petrol, because I
hoped that it would give me more power when accelerating.

Well, it certainly did that, wow you should have seen my car go! But alas
I should have read the manual first, just like they said. It turned out
that this experimental petrol contained an additive that did not suit my
car's engine. Three days later, smoke started pouring out of the engine
and then it caught fire.

I could have read the manual, which I later found out was aware of the
risk of fire and gave simple instructions for how to avoid it (adding a
cup of ethanol to a full tank of petrol was all it would have taken to
prevent the harmful chemical reaction). Instead I made the decision to
ignore it, and suffered the consequences.

Now, I could take responsibility for my own stupidity in ignoring the
warnings and just assuming that there would be no side-effects.

Or I could stamp my feet and holler at the top of my voice that it is the
petrol seller's fault, and that he should have locked this special fuel
away and banned everyone else from using it, to protect idiots like myself
from shooting myself in the foot. (Or setting my car on fire, as the case
may be.)

After all, while I made a free choice to use the private petrol, despite
all the warnings and all the reasons why I should not, it certainly
shouldn't be my responsibility to deal with the consequences of my own
choice.


>> The engineering decisions regarding my application should be on my
>> side, not the language lawyers.
>
> No problem, but any decision like that should be expressed in
> "writing", by re-declaring the variable so it's no longer private.

How do you see this working in practice?

Say you have written a class, with a private variable. I decide that I
need access to that variable, for reasons you never foresaw. What happens
next? I ask you nicely to please change your class and turn that private
attribute into a public one. What happens if you refuse? Can I have you
taken out and shot and seize ownership of your class, or do I have to
copy and paste your class into my code, creating a duplicate class I can
modify as much as I like?

--
Steven.

Michael Schneider

unread,
Sep 29, 2005, 10:08:28 AM9/29/05
to
I have been following this thread with great interest.

I have been coding in C++ since the late 80's and Java since the late 90's.


I do use private in these languages, with accessors to get at internal
data.

This has become an ingrained idiom for me. When I create a python
object, it is natural for me to want to use familiar idioms.


Hare are the places where private is useful to me:


Design Intent:

1) mark an object as dirty in a setter (anytime the object is changed,
the dirty flag is set without requiring a user to set the dirty flag

2) enforce value constraints (even if just during debugging)

3) lazy init, don't bring the data in until needed

4) adding debug info

5) .... more here????


I do write code that violates private
- memory ptr access in C++
- reflection in java
- aspects in java

I usually violate private when adding an aspect to a class, and
I don't want this code in every class. Example, persistence.


I really like the C# properties, you can access data with a data
accessor, but add functionality is triggered when accessing the data.

I like the data access syntax, better then the set/get functions. I
need the functionality to achieve the design goals above, so i use
function, but the are ugly, especially in math code.


It would be easy for me to say "Add public and private to python so I
can code the way that I am used to". What are some python alternatives
to achieve the design intents specified above above?

Thanks
Mike

en.kar...@ospaz.ru

unread,
Sep 29, 2005, 10:29:36 AM9/29/05
to pytho...@python.org
On Fri, 30 Sep 2005 00:16:02 +1000
Steven D'Aprano wrote:

> Say you have written a class, with a private variable. I decide that I
> need access to that variable, for reasons you never foresaw.

What if the access to that variable was forbidden for reasons you never
foresaw? What if the class author decide to remove the variable in the next
version of the class, because it's not an interface, but only a part of the
class implementation?

> What happens
> next? I ask you nicely to please change your class and turn that private
> attribute into a public one. What happens if you refuse? Can I have you
> taken out and shot and seize ownership of your class, or do I have to
> copy and paste your class into my code, creating a duplicate class I can
> modify as much as I like?

Yes, that's how it works in the open source. What's wrong with it? You
don't need _this_ class, because it's functionality doesn't fit to you. So
you take the source code and write another class, doing exactly what you
want it to do.

--
jk

Michael Ekstrand

unread,
Sep 29, 2005, 10:34:40 AM9/29/05
to pytho...@python.org
On Thursday 29 September 2005 03:57, Paul Rubin wrote:
> I can't think of a single time that I've ever seen a legitimate use
> of name mangling to reach from one class into another in a Python
> application (I don't count something like a debugger). If you're got
> some concrete examples I wouldn't mind looking.

I've done it in one project, my YaPIE library
(http://sourceforge.net/projects/yapie). But it's kinda ugly, and
probably not the right way to do things, and I don't even use the
library myself anymore (it grew out of frustration with some XML
parsing issues, before I did a little Java and learned to use SAX).

-Michael

Steven D'Aprano

unread,
Sep 29, 2005, 11:04:27 AM9/29/05
to

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.

Steve Holden

unread,
Sep 29, 2005, 10:39:04 AM9/29/05
to pytho...@python.org

Similarly they can rewrite it in Perl if they don't like it being in
Python. So what? Most people have *zero* interest in looking behind the
interface of the code they use, whether it's an API or a GUI.

Effectively this whole thread seems to have become an argument about
what kind of boxes you can have around namespaces. For the vast majority
who don't care the discussion will seem a little academic.

Should namespaces be protected? The lazy Pythonista's answer to that
question is:

>>> import os; f = os.popen("python -m this")
>>> for l in f:
... if "namespaces" in l.lower().split(): print l[:-1]
...
Namespaces are one honking great idea -- let's do more of those!
>>>

[note that my laziness extends to the gratuitous introduction of a
separate process to produce the source data. Can I claim extra points
for that?]

So it should come as no surprise to anyone that namespaces appear in
many contexts in Python. So, why this sudden urge (you may wonder, if
you don't think much about code purity) to have "private" and its
buddies. The security police have arrived, and you can be pretty sure
nothing much is going to be fun from here on in.

Think about it: we have a language that has an eval() function and an
exec statement, and people are concerned that some service consumer
shouldn't be allowed to go poking around inside namespaces? What do we
have to do, put up signs saying "do not stab yourself with a knife"? If
people want control without discipline (which is effectively what
private and the like purport to do) then Python just may not be your
language ...

Access to another object's namespace is almost invariably all-or-nothing
in Python, which (it should not be overlooked) has introspection
capabilities. With this ability to poke around in the bowels of the
system to perform deep magic comes a corresponding responsibility: don't
abuse the privilege, and behave in a disciplined (sort of) way.

To avoid naming conflicts, Python provides a mechanism (name mangling)
which pretty much guarantees that your names won't conflict with anybody
else's, *even if you subclass a class whose methods use the same name*.
This was a thoughtful addition, widely ignored by experienced
programmers. It was never intended to stop people from poking around
under the hood - simply to ensure that you wouldn't *accidentally* start
poking around under the hood of a parent class's implementation because
of a name clash.

C++ and cronies are not introspective languages (Java is and, like
Python, can mess about with its own workings; because of Java's many
constraints this turns out to be much less fun than in Python, but of
course Jython will give you access to many useful Java resources in a
much saner context) and non-introspective programmers frequently recoil
in horror when faced with the prospect of losing the training wheels :-)

Given the denizens of this particular list/newsgroup I am sure I will be
bombarded by a host of ways I could have produced the output of "import
this" without creating a new process. So, to try and forestall various
further expansions of this thread, let me produce a FAQ (which is
clearly quite bogus, since I am still writing it) for this post.

Q: It's inefficient to start another process.

A: When I need to do it six million times a second I'll remember that.
This was a one-off example. I have already wasted more time
discussing this issue than I would have saved in the first
thousand runs of a rewrite.

Q: It isn't cross-platform.

A: Well it runs on Windows, Cygwin and Linux, so it doesn't do badly.

Q: You could have done it some other way.

A: Please get over this obsession. There will always be more than
one way to do most things despite the output from a simpler (but
non-portable) solution

$ python -m this | grep way
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.

Note that word "obvious": nobody says you *have* to do things the
obvious way.

Q: Are you Dutch or something?

A: No such luck. But I'm not Belgian either :-)

a-voice-said-smile-things-could-be-worse-so-i-smiled-and-sure-enough-things-got-worse-ly
y'rs - steve


--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com

PyCon TX 2006 www.python.org/pycon/

Michael Ekstrand

unread,
Sep 29, 2005, 10:44:44 AM9/29/05
to pytho...@python.org
On Thursday 29 September 2005 09:08, Michael Schneider wrote:
> Design Intent:
>
> 1) mark an object as dirty in a setter (anytime the object is
> changed, the dirty flag is set without requiring a user to set the
> dirty flag

2 ways: wrap every attribute that is to be set in a property object (in
new-style classes), and set it in the setter there.

Or override __setattr__ to set the dirty flag.

Or, if you want overkill, but a potentially cleaner interface in some
cases, a metaclass could also be contrived to accomplish this (crud,
you can do _anything_ with a metaclass).

> 2) enforce value constraints (even if just during debugging)

Python's property objects

def _get_foo(self, foo):
return self.__foo
def _set_foo(self, foo, val):
if self.__is_valid_foo(val):
self.__foo = foo
else:
raise ValueError("Invalid foo")
foo = property(_get_foo, _set_foo, doc="Foo property")

> 3) lazy init, don't bring the data in until needed

Define __getattr__. Or use a metaclass (but I tend to think of
metaclasses as a solution to too many things - see previous thread
about synchronization for details).

> 4) adding debug info

A metaclass to do tracing, whatever - they let you modify the nature of
your class greatly on the fly.

> 5) .... more here????

Overriding magic methods (esp. getattr/setattr), various decorators
(ether existing or custom for your purposes), metaclasses, etc.

> I usually violate private when adding an aspect to a class, and
> I don't want this code in every class. Example, persistence.

Persistence can be done with subclassing, with a base class that sets up
persistence (I did this in PHP4 once, an ugly object model if I've ever
seen one). Metaclasses might be cleaner.

> I really like the C# properties, you can access data with a data
> accessor, but add functionality is triggered when accessing the data.

Python has these - use property objects. property() is documented under
Built-In Functions

> I like the data access syntax, better then the set/get functions. I
> need the functionality to achieve the design goals above, so i use
> function, but the are ugly, especially in math code.

Yes, get/set is highly ugly IMHO. I have to do Java for one of my
classes now... I frequently want to gag over the forced usage of such
things.

> It would be easy for me to say "Add public and private to python so I
> can code the way that I am used to". What are some python
> alternatives to achieve the design intents specified above above?

See above :-). I think you'll find that you can accomplish most or all
of your purposes, and then a few you may not have thought of yet.

- Michael

Simon Brunning

unread,
Sep 29, 2005, 10:52:08 AM9/29/05
to pytho...@python.org
On 9/29/05, en.kar...@ospaz.ru <en.kar...@ospaz.ru> wrote:
> What if the access to that variable was forbidden for reasons you never
> foresaw? What if the class author decide to remove the variable in the next
> version of the class, because it's not an interface, but only a part of the
> class implementation?

Then your code breaks. You can't say you weren't warned.

But if too much is made private, chances are you could never get your
code working in the first place. This has happened to me several times
when using 3rd party Java components. Serves us right for using closed
source libraries, I suppose, but that wasn't my decision.

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

Fredrik Lundh

unread,
Sep 29, 2005, 10:47:15 AM9/29/05
to pytho...@python.org
Michael Schneider wrote:

> 1) mark an object as dirty in a setter (anytime the object is changed,
> the dirty flag is set without requiring a user to set the dirty flag

properties.

> 2) enforce value constraints (even if just during debugging)

properties. (when you no longer need to enforce things, switch back
to a plain attribute).

> 3) lazy init, don't bring the data in until needed

properties.

> 4) adding debug info

properties.

> 5) .... more here????

properties.

> It would be easy for me to say "Add public and private to python so I
> can code the way that I am used to".

huh? what do "private" and "public" have to do with what you're describing?

> What are some python alternatives to achieve the design intents specified
> above above?

properties.

http://users.rcn.com/python/download/Descriptor.htm#properties

</F>

Fredrik Lundh

unread,
Sep 29, 2005, 10:59:01 AM9/29/05
to pytho...@python.org
Steve Holden wrote:

> To avoid naming conflicts, Python provides a mechanism (name mangling)
> which pretty much guarantees that your names won't conflict with anybody
> else's, *even if you subclass a class whose methods use the same name*.

as long as you don't cheat, that is:

# your code

class Secret:
def __init__(self):
self.__hidden = "very secret value"

# my code

from yourcode import Secret

class Secret(Secret):
def gethidden(self):
return self.__hidden

s = Secret()
print s.gethidden()

</F>

Fredrik Lundh

unread,
Sep 29, 2005, 11:03:00 AM9/29/05
to pytho...@python.org
en.kar...@ospaz.ru wrote:

> What if the access to that variable was forbidden for reasons you never
> foresaw? What if the class author decide to remove the variable in the next
> version of the class, because it's not an interface, but only a part of the
> class implementation?

you mean when he breaks into your computer and installs the new version
without you noticing?

if you think that once you've put private labels on all accidental stuff, nothing
will break during upgrades, you're clearly very new to this thing called pro-
gramming...

</F>

Rocco Moretti

unread,
Sep 29, 2005, 11:03:41 AM9/29/05
to
en.kar...@ospaz.ru wrote:
> On Fri, 30 Sep 2005 00:16:02 +1000
> Steven D'Aprano wrote:
>
>>Say you have written a class, with a private variable. I decide that I
>>need access to that variable, for reasons you never foresaw.
>
> What if the access to that variable was forbidden for reasons you never
> foresaw? What if the class author decide to remove the variable in the next
> version of the class, because it's not an interface, but only a part of the
> class implementation?

What if the class author removes a non-private variable or changes a
method's documented parameters in the next version of the class, because
he think it'll work better, or just because he can?

People who think that forbidding access to private variables/methods
will save themselves from upgrade woes are deluding themselves.