Re: Will python never intend to support private, protected and public?
Steve Holden
> 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
> 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
> 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
> 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
> I'm not sure why I haven't seen this mentioned yet, but a leading
> 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
> 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
> 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
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
> Do you know any language that has real private and protected attributes?
Java?
Simon Brunning
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
> > 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
> 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
> 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
<"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
>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
> 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
> -- 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
> 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
> That's not what the documentation says:
So, either the docs are wrong, or I am. You be the judge. <wink>
Terry Hancock
> 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
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
>
> 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
>> 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>
ncf
alter and access them. So, IMHO, no program can have truely
private/protected values.
Paul Rubin
> > 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
> 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
> 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
> 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
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
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
> 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
> 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
> > 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
> 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
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
> 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
> 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
> 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
>
> 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
> 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
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
Paul Rubin
> 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
>
> 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
> > 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.
>
> 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
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
>
> 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
> 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
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
[psst ... do you think they've stopped now?]
Paul Boddie
> 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
Steven D'Aprano
>> 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
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
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
> 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
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
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
> 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
> 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
> 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
> 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
> 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
> 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.
Steven D'Aprano
> 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?
I either write buggy code that breaks when the class author changes the
variable, or I write code that is careful, does not make assumptions about
the nature of the variable, and fails gracefully when the author changes
or removes the variable.
In the first case, I'm responsible for the bug, and will hang my head in
shame. In the second case, I impress people with the quality of my code
and get surrounded by hundreds of adoring women who want to have my
children. (Well I can dream can't I?)
But either way, the original class author may never remove the variable,
in which case I have all the advantages of accessing that semi-private
variable with none of the disadvantages.
This, of course, assumes that there are some advantages of accessing the
variable. If there are none, then I would be foolish to make a rod for my
own back by bypassing the class author's supported API for no benefit.
>> 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.
Oh please, it does not. We hardly ever have people taken out and shot so
we can take their code. That's more Microsoft's way of doing business...
*wink*
> 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.
Perhaps I don't have access to the source code at all, only the .pyc file,
but I've learnt the secret name of the private attribute from the book
"Undocumented Tricks And Tips For Pythonistas".
Or I do have access to the source code, but under a licence that does not
allow me to legally modify the code and distribute it. Should I break the
law and risk a civil suit or even jail for copyright infringement?
Or maybe I just don't feel like taking on the responsibility of
maintaining the entire class, but feel that it is perfectly within my
capabilities to update my code if and when one specific private variable
gets modified or removed.
Or maybe I just don't like the idea of introducing bugs and duplicating
labour by copying and pasting code.
--
Steven.
Roel Schroeven
> 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 :-)
Some of us are!
Since we Belgians live so close to the Dutch, chances are that the
obvious way is obvious to us too. It's just that it's also obvious to us
that we're obviously not going to take the obvious route. We'll do it
our own way, thank you very much :)
I'm not taking it so far to start using Perl though.
--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton
Roel Schroeven
Steve Holden
I thought you'd know me well enough to know I'd *never* cheat :-)
Nice way to point out that Pythin is indeed a "consenting adults" language.
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
> **Encapsulation** is one of the 3 basic characteristics of OOP.
Pyhton has encapsulation. On objetcts members are encapsulated in a
namespace all of its own. You can't change these by accident.
> Every programmer is just a human being, but not God. Our life is limited,
> our time is limited, so we need to use convenient tools to save time.
> Private variables guarantee that we will never make stupid mistakes
Private variables prevent the developer of the *client* of a class
from making a small subset of all possible stupid mistakes. But if the
developer of the classitself is mistaken in marking a variable as
private, and if the language enforces this, then there is nothing at
all that the client can do to fix it. Why should the developer of the
class be more likely to be god-like than the user of the class? This
has happened to me more than once.
Bill Mill
> class a:
> i=0
> def setI(iii):
> if self.i!=iii:
> self.i=iii
> #do some extra works here, e.g, notify the observers that
> #this property is changed, or do some logging things.
> ___________________________________________
> In the class "a" above, when "i" is changed, I will do some extra works,
> the extra works could be very import, so I want to keep i invisible
> to some others, they can only change i by the method setI. But python
> can't ensure i to be invisible, everyone can change it whenever they
> want! This is dangerous.
>
>>> class test(object):
... __i = 0
... def incr(self, n): self.__i += 1; print "incremented i"
... def geti(self): print "got i"; return self.__i
... i = property(geti, incr)
...
>>> t = test()
>>> t.i
got i
0
>>> t.i += 5
got i
incremented i
>>> t.i
got i
1
>>> dir(t)
['__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__', '__hash_
_', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr_
_', '__setattr__', '__str__', '__weakref__', '_test__i', 'geti', 'i', 'incr']
>>>
>>> #here's how the crazy hackers subclassing your code can break your super
... #special private variable!
...
>>> t._test__i += 6
>>> t.i
got i
7
But, if your users can't figure out that they shouldn't be changing
the variable called t._test__i without expecting side effects, what do
you think of the users of your class?
Python is for consenting adults.
Peace
Bill Mill
bill.mill at gmail.com
Bill Mill
> >>> #here's how the crazy hackers subclassing your code can break your super
> ... #special private variable!
> ...
That should be "using your code" not "subclassing your code". D'oh!
sk...@pobox.com
>> **Encapsulation** is one of the 3 basic characteristics of OOP.
This isn't an encapsulation issue. From the first hit on Google for the
word:
In programming, the process of combining elements to create a new
entity. For example, a procedure is a type of encapsulation because it
combines a series of computer instructions. Likewise, a complex data
type, such as a record or class, relies on encapsulation. Object-
oriented programming languages rely heavily on encapsulation to create
high-level objects. Encapsulation is closely related to abstraction and
information hiding.
Python does encapsulation just fine. Your beef is with its information
hiding.
Skip
gsteff
interest, because we've been discussing the virtues of private
visibility ("information hiding") in one of my courses recently. Does
anyone know of academic papers that make the case against "private" in
languages?
Greg
Fredrik Lundh
> Encapsulation or information hiding or whatever
You've got to be very careful if you don't know where you're looking
for, because you might not find it.
</F>
Fredrik Lundh
>> Encapsulation or information hiding or whatever
>
> You've got to be very careful if you don't know where you're looking
> for, because you might not find it.
message.sub("where", "what") # argh!
sk...@pobox.com
Greg> Does anyone know of academic papers that make the case against
Greg> "private" in languages?
Nope. I'd be interested in seeing academic papers that make the case (with
data to back up the claims) that "private" is beneficial.
Skip
en.kar...@ospaz.ru
Fredrik Lundh wrote:
> 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...
Do you ever heard of that funny things named "an interface" and "an
implementation"?
--
jk
Fredrik Lundh
> Do you ever heard of that funny things named "an interface" and "an
> implementation"?
the "shared DLL:s ought to work" school of thought, you mean?
</F>
Paul Rubin
> Python is for consenting adults.
Python might be for consenting adults, but multi-person software
projects are supposed to be done in the workplace, not the bedroom.
So there are still some software constructs that are simply beyond the
bounds of propriety, and I think we're discussing one of them. ;-).
Terry Reedy
"could ildg" <coul...@gmail.com> wrote in message
news:311b5ce105092...@mail.gmail.com...
>why is rails written in Ruby
Because the several people and groups of people who have written web
frameworks in Python used other names.
Python on Rails just doesn't have the same alliterative zing.
>but not Python since python is such a good language?
I have seen mention of 5-10 web frameworks in Python.
>This kind of variables can only be modified by the
> functions of the class itself.
Reading a private variable does not change it.
I am sure this covers at least some use cases of private var access.
Terry J. Reedy
Mike Meyer
Bondage and discipline - even between consenting adults - is *usually*
considered beyond the bounds of propriety. Since that's what's being
discussed, I'd say "yup."
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Paul Rubin
> from yourcode import Secret
>
> class Secret(Secret):
> def gethidden(self):
> return self.__hidden
Heh, interesting, and it occurs to me that you could do that by
accident (A inherits from B, and then something imports B and makes an
inheriting class that inadvertently happens to be called A). I.e. the
name mangling can fail its intended purpose.
# your code:
class Secret:
def __init__(self):
self.__hidden = "very secret value"
class Parrot(secret): pass
# my code
from yourcode import Parrot
class Secret(Parrot): # I'm not aware that you also have a Secret class
def spam(self, x):
self.__hidden = zoo(x) # clobbers yourcode's version of secret
def eggs(self): # might inadvertently read your version's
try:
return self.__hidden
except AttributeError:
self.spam(cached_value)
Michael Schneider
Thank you very much for the info on properties, that is very useful.
Sorry about the public typo, that should have been protected. I should
not post before coffee hits :-)
Happy coding,
Mike
Michael Schneider
Thank you very much for the info on properties, that is very useful.
Sorry about the public typo, that should have been protected. I should
not post before coffee hits :-)
Happy coding,
Mike
en.kar...@ospaz.ru
Fredrik Lundh wrote:
> 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
It's not a cheat, it's an accident you have no protection against.
Consider:
class Secret(NotSoSecret):
# pass
Looks like you must know every one of the base classes of the NotSoSecret,
whether there is some base class named Secret? And, if so, you must also
know these classes _implementation_, every one of their attributes,
variables and methods, to avoid accidental overriding?
For me, it's not what inheritance is about. This accident should be rare,
but possible.
--
jk
en.kar...@ospaz.ru
No, the other way around: my app works when I upgrade libraries it depends
on.
--
jk
Fredrik Lundh
> Looks like you must know every one of the base classes of the NotSoSecret,
> whether there is some base class named Secret? And, if so, you must also
> know these classes _implementation_
that information isn't hidden, so there's nothing "you must know". finding out
is a matter of writing a very small program, or tinkering at the interactive prompt
for a couple of seconds. are you even aware that you're posting to a Python
group ?
</F>
Gregor Horvath
> Bill Mill <bill...@gmail.com> writes:
>
>>Python is for consenting adults.
>
> Python might be for consenting adults, but multi-person software
> projects are supposed to be done in the workplace, not the bedroom.
Are the numerous working python open source projects not multi-person
software projects? Even multiple persons that even dont know each other
and can discuss the latest news at the coffee machine?
The fact that they are working and there is not much demand for a
bastion is a strong signal that pythons attitude: advise but not enforce
is actually working.
--
Greg
Paul Rubin
No. You could poke at the implementation interactively to find out
that some __xyz attribute isn't in use by some superclass, then you
could write your code to use that attribute, and later the
superclasses change out from under you so that the name mangling fails
to protect you.
Paul Rubin
> Are the numerous working python open source projects not multi-person
> software projects? Even multiple persons that even dont know each
> other and can discuss the latest news at the coffee machine?
There are not that many such projects being done in Python. Maybe
this type of thing is the reason.
> The fact that they are working and there is not much demand for a
> bastion is a strong signal that pythons attitude: advise but not
> enforce is actually working.
I don't know of a single program that's actually relying on the
non-enforcement. I've asked for examples but have only gotten
theoretical ones. As far as I can tell, the feature is useless.
Fredrik Lundh
>> > Do you ever heard of that funny things named "an interface" and "an
>> > implementation"?
>>
>> the "shared DLL:s ought to work" school of thought, you mean?
>
> No, the other way around: my app works when I upgrade libraries it depends
> on.
yeah, because it's only the visible interface that matters. implementation semantics
don't exist. you're clearly very new to this thing called programming...
</F>
Gregor Horvath
>
> I don't know of a single program that's actually relying on the
> non-enforcement. I've asked for examples but have only gotten
> theoretical ones. As far as I can tell, the feature is useless.
Real open source live example from yesterdays mailinglists:
<Webware-discuss>
quick question:
I just updated both my python install (241->242) as well as updating
webware from the svn ( I know I should not have done both at the same
time) and when i tried to run webware (after running install.py again)
I received an error that in application.py at line 125 I could not do
float - none. It appears to me that the Profiles.starttime is not
being set and so it defaults to none. I added a line setting the
starttime to self._startTime which fixed the problem for me but I
thought I would pass the info to the group. Has anyone else had this
problem?
</Webware-discuss>
--
Greg
Paul Rubin
> Real open source live example from yesterdays mailinglists:
I don't see any use of name mangling in that example.
en.kar...@ospaz.ru
Fredrik Lundh wrote:
> en.kar...@ospaz.ru wrote:
>
> > Looks like you must know every one of the base classes of the NotSoSecret,
> > whether there is some base class named Secret? And, if so, you must also
> > know these classes _implementation_
>
> that information isn't hidden, so there's nothing "you must know". finding out
> is a matter of writing a very small program, or tinkering at the interactive prompt
> for a couple of seconds. are you even aware that you're posting to a Python
> group ?
So you have read every line of the python std library, I guess? (Not to
mention libc or kernel32.exe or whatever.)
--
jk
Gregor Horvath
> Gregor Horvath <g.ho...@gmx.at> writes:
>
>>Real open source live example from yesterdays mailinglists:
>
>
> I don't see any use of name mangling in that example.
Someone has a problem and tweaks a private variable as a workaround.
No python program will rely by definition on access to privat variables,
it just lets the door open, just for the case that the program is not
used in steril theoretical environment with a lot of flipcharts but in
real dirty live with bugs, version conflicts, changing demands, ill
spezifications, crazy public interfaces and so on.
--
Greg
Antoon Pardon
> On 9/29/05, could ildg <coul...@gmail.com> wrote:
>> **Encapsulation** is one of the 3 basic characteristics of OOP.
>
> Pyhton has encapsulation. On objetcts members are encapsulated in a
> namespace all of its own. You can't change these by accident.
>
>> Every programmer is just a human being, but not God. Our life is limited,
>> our time is limited, so we need to use convenient tools to save time.
>> Private variables guarantee that we will never make stupid mistakes
>
> Private variables prevent the developer of the *client* of a class
> from making a small subset of all possible stupid mistakes. But if the
> developer of the classitself is mistaken in marking a variable as
> private, and if the language enforces this, then there is nothing at
> all that the client can do to fix it. Why should the developer of the
> class be more likely to be god-like than the user of the class? This
> has happened to me more than once.
So, talk to the devloper. The developer of the class is more god-like
because it is his development. If something goes wrong with the class
he has to find out what and that is easier if he can assure that clients
didn't mess with certain implementation details.
Sure the developer can make a mistake here, just as he can mistakes
anywhere in his code. If that happens, you should report a bug.
--
Antoon Pardon
Antoon Pardon
>
> But, if your users can't figure out that they shouldn't be changing
> the variable called t._test__i without expecting side effects, what do
> you think of the users of your class?
>
> Python is for consenting adults.
No it is not. Consenting means you had the choice. Python doesn't
give you the choice not to consent. Unless of course you write
it as a C-extension, then you can hide all you want.
--
Antoon Pardon
Paul Rubin
> They did? Fine... Add another that Python names beginning with _ or
> __ are not to be accessed from outside the module/class that defined
> them. And if one is not the "owner" of that module/class, they should
> contact the responsible person and justify the need to have it made
> public, or to have access methods added.
People are much likelier than the compiler is, to make errors with
such policies. For example: someplace in the application it says
setattr(x, propname, 23)
where x is an ABC instance. You didn't expect propname to have the
value "_ABC__private_var" but somehow it got that way, maybe through
malicious input data. What coding standard is going to catch that?
Are you suggesting a coding standard that bans setattr?
I'm not proposing to change the behavior of a.__xyz even though that
behavior is currently broken. The question under discussion is about
adding a new feature to Python, e.g. a "private" declaration that's
orthagonal to __xyz name mangling. Whether such a feature is worth
implementing or not is questionable. I'm not even saying it's worth
doing. However, deciding to do it, and then doing it in a broken way,
is insane.
What "coding standards" let you do is review a piece of code and say
"the __xyz attribute didn't get clobbered, unless somebody, somewhere,
made an error with name mangling or the coding standard", which means
you have to consider that possibility anytime you're trying to debug
something related to the __xyz attribute.
OTOH, "private" lets you say 100% for certain that another class
didn't clobber __xyz, and that any bug that clobbered it MUST reside
in the class that declared it. That makes auditing for __xyz-related
errors a lot simpler since you only have to look in one class for them.
If "private" exists and you don't like it, you can solve that with a
coding standard that says not to use it. Any violation can be
instantly flagged by the build script. If "private" doesn't exist,
there is no reasonable coding standard that can substitute for it.
Antoon Pardon
> 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?
>
> method's documented parameters in the next version of the class, because
> he think it'll work better, or just because he can?
Changing an interface is different from changing the implementation.
A (documented) interface is like a contract. The implementation is
just one way to follow that contract.
> People who think that forbidding access to private variables/methods
> will save themselves from upgrade woes are deluding themselves.
It helps, just as locks wont save you from burglars if they really
want to rob you, but the locks do help.
--
Antoon Pardon