is python Object oriented??

[Bruno Desthuilliers]

Steven D'Aprano a écrit :
> On Tue, 03 Feb 2009 03:48:58 +0000, Rhodri James wrote:
> 
>> On Tue, 03 Feb 2009 02:16:01 -0000, Russ P. <Russ.Paielli at gmail.com>
>> wrote:
>>
>>> Here we go again. If you have access to the source code (as you nearly
>>> always do with Python code), then "breaking the language-enforced data
>>> hiding" is a trivial matter of deleting the word "private" (or
>>> equivalent).
>> If it's that trivial to defeat something that its proponents appear to
>> want to be close to an iron-clad guarantee, what on earth is the point
>> of using "private" in the first place?
> 
> Well, that is a good question.
> 
> Since it is even more trivial to defeat Python's private-by-convention 
> data hiding, why even bother? Just make everything public. What on earth 
> is the point of prefixing an attribute with an underscore?

To make clear it is *not* part of the API. The point is about enforced 
access restriction, not encapsulation.

> 
> I think this debate has a lot to do with people's attitudes towards "No 
> User Serviceable Parts". Some people are comfortable using black-boxes, 
> and if (enforced) data hiding makes it easier for others to build safe, 
> efficient black-boxes, then they're willing to give up that a little bit 
> of flexibility/freedom for the benefit of safe, efficient black-boxes.
> 
> Others prefer white-boxes, and are willing to give up some safety and 
> efficiency, and live with increased risk and lower performance, just in 
> case some day they might want to open up the white-box and replace the 
> widget with a gadget.

I don't see how this relates to efficiency.

> Some of us consider that a black-box sealed with regular Phillips head 
> screws is still be an effective black-box.

And most of us here go as far as considering that something as simple as 
a "warranty broke if unsealed" label is enough.

> It's not hard to find a screw 
> driver and open the box, but it's still an effective barrier against 
> casual and accidental tinkering while allowing deliberate tinkering.

Idem for a label. You *see* it, don't you ? So you cannot pretend you 
"accidentaly" opened the box.


> Others take the attitude that anything short of resistance to oxy torches 
> and diamond-tipped drills might as well be in a paper bag, and therefore 
> there's no point to black-boxes at all.

straw-man argument once again. No one here says taht there's no point to 
black-box - just that there's no point having to resort to any special 
screw-driver if and when we want to treat it as a white box.

> I find this extreme position is rather incoherent.

It's *your* oversimplification of the point against *enforced* access 
restriction that makes it incoherent.


(snip)

> Another extreme position is that enforced data hiding is useless, that 
> there is *never* any need for it *at all*, and therefore Python doesn't 
> need it, there's no reason except stupid PHB's belief in cargo-cult 
> coding why Python couldn't be used for controlling nuclear reactors or 
> the Space Shuttle.

There may be quite a lot of reasons to think (rightly or not) that 
Python is not suited for such tasks. Anyway, I personnaly don't care 
whether Python would be the right tool for such cases, because - like 
probably more than 99.99% of Python users - that's not what I'm using it 
for, and I don't see any reason to add such useless arbitrary 
restrictions just because 2 or 3 persons claims that it's "how it should 
be". FWIW, since anything dynamic would be considered unsafe in the 
mentioned use cases, the next point would be to make Python as static as 
Java. Yeah, great.

> There's been some claims remarkably close to that in 
> this or the previous thread. I trust that nobody really believes this 
> extreme position -- it's not that far off claiming that procedures and 
> functions are pointless and stupid because we have GOTO.

yet another straw man argument.

> I love Python, and I'm greedy and want it all: I want a dynamic, easy-to-
> use language *and* a compiler that can protect me from myself

That's not what compilers are for.

> and bad 
> data.

I definitly fail to see how a compiler could protect you from *runtime* 
issues ???

> I'm envious of Haskell's type-inference. I want the option to have 
> the compiler warn me when some function is messing with my classes' 
> internals as soon as I hit Enter,

May I remind you that "def" and "class" are executable statements ?

> 
> I'm not going to *demand* the choice of white-box or black-box classes. I 
> don't have the right to demand anything. But I can ask, I can try to make 
> my case (to those who will listen), and I refuse to be brow-beaten by 
> those who think Python is Just About Perfect Just The Way It Is into 
> feeling *ashamed* for wanting that choice.

It's not about Python being "Just About Perfect Just The Way It", it's 
about deciding whether enforced access restriction is of any use (at 
least for a very large majority of it's users), and if it's worth 
imposing design changes so fundamuntal they would just turn Python into 
a totally different language just because a couple guys ask for it.

Anyway: the choice is neither yours nor mine, so all this discussion is 
more than pointless. If you really want such drastic changes in Python's 
design and implementation, submit a PEP.