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.paie...@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.
--
http://mail.python.org/mailman/listinfo/python-list
