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

Luis Zarrabeitia kyrie at uh.cu
Wed Jan 21 17:10:18 EST 2009


On Wednesday 21 January 2009 04:16:38 pm Russ P. wrote:
> On Jan 21, 9:34 am, Luis Zarrabeitia <ky... at uh.cu> wrote:
> > But you keep failing to explay why do you need it to be _part of the
> > standard_ library (or whatever).
>
> Technically, it doesn't need to be. But if someone proposes using
> particular language for a major safety-critical project, the critical
> features realistically need to be part of the standard language or at
> the very least in the standard library.

I assume, then, that no safety-critical project uses any external tool for 
checking anything important.

> The requirements are different for government-regulated code than they
> are for non-critical commercial code, as well they should be. Imagine
> trying to explain to the FAA that you are going to use a language that
> is inappropriate by itself for a safety-critical system but will be
> appropriate with the addition of third-party software. That just won't
> fly.

Then it wont fly, period.
If you start explaining that the language is inappropriate, then you've 
already made the case. I would argue that the language _is_ appropriate 
_because_ all your concerns can be solved. (assuming, of course, that the 
theoretically-solvable concerns are can actually be solved). 

But as you haven't stated yet any specific concern other than silly 
locked-doors analogy and "you are crazy if you think that a nuclear blahblah 
don't use private variables", this is kind of pointless.

> Then again, the FAA might not approve Python for flight-critical or
> safety-critical code even if it gets enforced data hiding, so perhaps
> the point is moot.

Most likely. For what you've said, if the use of an external tool would make 
it inappropriate, I highly doubt that they'll like an informally-developed 
community-driven open source language who's developers and a good portion of 
its community consider silly the idea of using enforced data-hiding for 
anything other than debugging.

> > If you need it in your project, _use_ it. If you don't, then don't use
> > it. If _you_ need that thing you call security, just use it already and
> > quit complaining that we don't use it. Is there a policy in your project
> > that you can't use any external?
>
> I don't recall complaining that anyone doesn't use something.

Well, you want it on the python compiler I use. That seems awfully close.

Funny thing... if pylint became part of the standard library, I may welcome 
the change. I certainly wouldn't be complaining about it unless it was 
enabled-by-default-and-can't-disable-it. 

> In fact, 
> in the unlikely event that enforced data hiding is ever added to
> Python, nobody would be forced to use it (except perhaps by your 
> boss or your customer, but that's another matter).

No one is now. And no one is forced to not use it either (except perhaps by 
your boss or your customer, but that's another matter).

-- 
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
http://profesores.matcom.uh.cu/~kyrie



More information about the Python-list mailing list