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
On 9/28/05, could ildg <could....@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.
> On 9/28/05, could ildg <could....@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.
On 9/28/05, Simon Brunning <simon.brunn...@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.
Tony Meyer <t-me...@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.
On 9/28/05, Tony Meyer <t-me...@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).
Simon Brunning <simon.brunn...@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).
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 <could....@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.
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.
<"http://phr.cx"@nospam.invalid> wrote: > Steven D'Aprano <st...@REMOVETHIScyber.com.au> writes: > > Do you know any language that has real private and protected attributes?
> Java?
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 <simon.brunn...@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.
> 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 <could....@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:
<"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...
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.
>> 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.
Chris Gonnerman <chris.gonner...@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:
Name mangling is a poor substitute for private variables. If you want to be able to share private variables with other classes under certain circumstances, it's better to use something like C++'s "friend" declaration, where you can export the variables to a specific other class.
> On 9/28/05, Tony Meyer <t-me...@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, [...] """
Paul Rubin <http://phr...@NOSPAM.invalid> writes: > Chris Gonnerman <chris.gonner...@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:
> 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.
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.
> 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.
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, > [...] > """
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:
> 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.
Gregor Horvath <g.horv...@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.
|
