Does Python really follow its philosophy of "Readability counts"?
kyrie at uh.cu
Sun Jan 25 09:13:14 CET 2009
Quoting "Russ P." <Russ.Paielli at gmail.com>:
> On Jan 24, 9:54 pm, Luis Zarrabeitia <ky... at uh.cu> wrote:
> > Quoting "Russ P." <Russ.Paie... at gmail.com>:
> > It is. For starters, I'd lose the information of "this attribute was
> intended to
> > be internal and I'm accessing it anyway".
> Not really. When you get a new version of the library and try to use
> it, you will quickly get a reminder about the change (assuming your
> tests provide sufficient converage, and also assuming that the
> attribute is not made public in the new version). So you don't really
> even need to keep track of the change.
See? With every new version that doesn't change the behaviour, I have to modify
the source just to see if the tests run. That _is_ a fork. And that's assuming
the bright case where I have the source.
> > No. I am not dictating _anything_. The beauty of it, you don't have to do
> > _anything_ for this to happen.
> You are trying to dictate that the library implementer not be allowed
> to use enforced access restriction. And, in the larger sense, you are
> trying to dictate that access restrictions not be enforced in Python.
Now, please, explain to me, why are you so interested on preventing me from
using the internals on my computer? If you want controls in the code that runs
on your system, you can.
> > Or contacting him about it and maybe send him a patch, sure, why not. But
> > has nothing to do with enforced data hiding. Having obj._public_var is just
> > badly designed as having "private public_var".
> Sure, go ahead and contact him. If he agrees that a private attribute
> should be public, then the problem is solved. But if he does not
> agree, he should not be forced to bend to your desire.
Wait, if I change my project to ignore the data hiding (enforced or not), am I
forcing the author to bend for my desire? Please explain your reasoning.
Or better yet... don't. I will just give up, right now. This is no longer about
"security", "good practices", "software engineering", "bug catching" or "formal
proofs" as you've tried to paint it before. This is about you wanting to control
how others use your code. And while it may be your legal right, that isn't the
discussion I thought I was getting into.
More information about the Python-list