Does Python really follow its philosophy of "Readability counts"?

[Russ P.]

On Jan 20, 5:33 am, Luis Zarrabeitia <ky... at uh.cu> wrote:
> On Tuesday 20 January 2009 05:00:34 am Paul Rubin wrote:
>
> > Luis Zarrabeitia <ky... at uh.cu> writes:
> > > No wonder you can't get Bruno's point. For the second, static checks
> > > to prevent accidents, you have pylint. For the first, not only you
> > > are using the wrong tool, but you are barking at python for not
> > > having it. Assuming that pylint is perfect (big assumption, but it
> > > is up to you to prove where it fails),
>
> > Whaat?  Assuming a program is perfect unless a failure is proven
> > is not at all a sane approach to getting reliable software.  It is
> > the person claiming perfection who has to prove the absence of failure.
>
> No, no. I meant that if pylint works as its specification says it would.
>
> Russ says (or seems to say, I don't know, I'm confused already) that it is not
> good enough, that what pylint says it does is not what he wants (otherwise,
> this subthread would have died a long time ago). So, assuming that pylint
> works as specified (its up to "you" to find out if it doesn't and file
> bugreports about it, just like you would do if you find out that the
> static-checker for your enforced-static-checks-language is buggy), what
> would be the difference between only accepting/running "pylint-authorized
> code" and the enforced hiding you desire?
>
> Sorry, I didn't realize that perfect was a too strong word for that. "I speaks
> english bad" :D
>
> Cya!
>
> --
> Luis Zarrabeitia (aka Kyrie)
> Fac. de Matemática y Computación, UH.http://profesores.matcom.uh.cu/~kyrie


Hey, if pylint can reliably detect private data access violations,
that's good news to me. I haven't used it, so I don't know. (I used
pychecker a while back, but I haven't used that for a while either.)

If pylint can check access violations, then it seems to me that
someone (who is familiar with the internals of the Python interpreter)
should be able to integrate that feature into Python itself relatively
easily.

Actually, in addition to the enforcement of "private," you also need
the enforcement of "protected." If you only enforce "private," derived
classes will not have access to data they need. And if you don't
enforce "protected," then anyone can trivially gain access to private
data by simply deriving a new class. It would be like having a lock on
the door with the key hanging right there on a string.

I realize that this complicates matters. As I said before, I am not
claiming that Python should necessarily get enforced data hiding. All
I am saying is that, if it doesn't get it, it will never be
appropriate for certain domains. But maybe nobody cares about that
except me.

The other problem with the pylint approach is aesthetic: the
requirement for a leading underscore to indicate private data. I
realize that some actually like that convention, but I don't. I spend
most of my development time working with "private" data, and why
should I have to look at that litter everywhere? I use Python in part
because I want clean looking code, and leading underscores bother me
-- just as the leading dollar signs in Perl bother many Python
programmers.