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

[Russ P.]

On Jan 19, 7:13 am, Bruno Desthuilliers <bruno.
42.desthuilli... at websiteburo.invalid> wrote:

> I must be missing the point : if it's a public attribute, it doesn't
> need a "property" ? I guess we use the same words for different things here.

Yes, you are missing more than one point.

Scala automatically converts public data members into properties,
apparently to save the programmer the trouble of doing it manually. If
you are interested, I'm sure you can find publicly available
information on it.

> I definitively wouldn't bet my ass on language-level access restriction
> to protect software from fraud or sabotage.

You're missing the point here too. I'll try one more time to explain
it.

Access restriction enforced by the language is just one safeguard
among several that are usually available. I think the lock analogy is
very appropriate here. Think about door locks. Would you "bet your
ass" on them to keep you secure? Of course not. You might also have a
firearm or a dog. But even if you don't have those, you surely have a
police department, and surely they carry guns.

Because you cannot "bet your ass" on door locks for your security,
does that mean you just abandon them altogether? Maybe so, if you live
in a very remote place, but most people still seem to think they need
locks on their doors. Well, think of access restrictions enforced by
the language as analogous to door locks.

Let's take the analogy a bit further. Suppose you work in a secure
building with strict access control, and everyone in the building is
"trusted" (whatever that means). This situation is analogous to a
group of "trusted" developers working on a project together. Would you
feel comfortable having no locks on the doors?

Maybe you would, but I wouldn't. I wouldn't want to just let my co-
workers, trusted or not, have access to all my personal stuff. And
what if I need to store something of value from time to time? They may
be honest, but why even tempt them? What if one of them decides he
needs to borrow my favorite Python book while I'm gone, then forgets
to return it?

But what if you don't want your door locked? Well, you have the option
of not using your lock. You can get your way whether the doors have
locks or not. But if I want mine locked, and no locks are available, I
can't get what I want. When you say that a language should not even
have access control available, you are essentially saying that you
should get your way -- and to hell with anyone who disagrees with my
way.

> Yes. And I also think that trust (and even - to a certain extent -
> competence) is better built on trust than on distrust. When treated as
> an irresponsible morons just barely able to type code, most peoples tend
> to become just that : code-monkeys.

That may well apply in some environments, but it certainly does not
apply in all environments. It certainly does not apply in a defense
contracting environment, or a financial software development
environment, to give just two of many possible examples. Maybe you
don't personally care about such environments, but who are you to
decide what environments Python should or should not be suitable for?

> Take some not-that-trivial projects like Zope/Plone. There are quite a
> few lines of code involved, and quite a lot of programmers worked on it.
>   Some of them being very average joe programmer FWIW. Guess what ? From
> experience, it JustWork(tm). Granted, this is not a critical system -
> but that's not the point here. The point is that _from experience_, most
> programmers are wise enough to avoid doing stupid things.

And would data hiding have impeded those projects? Or could it perhaps
have helped? I don't know, but I don't think you can simply assume it
would have been a net minus. I know for fact that the strict access
restrictions in Ada were indispensable in the integration of the
flight software in the Boeing 777, for example. Without them, they'd
probably *still* be trying to get it right!

> > And even if all your developers were excellent, data hiding would
> > still be a convenient mechanism to simplify their jobs  so they can
> > focus on higher level problems
>
> Sorry, but this makes no sense. How could the lack of
> *language-enforced* access restriction  makes anything more complicated ???

Because it forces humans to check for access restrictions when the
language could do it.

> > -- and not have to rely on an ugly
> > naming convention.
>
> And here we are, finally : *you* don't like this convention (and we've
> aready been thru that discussion IIRC).
>
> Guess what ? As far as I'm concerned, I just *love* this convention.
> Because I *never* have to ask myself if some attribute is interface or
> implementation.

If you like it that much, you would be perfectly free to continue
using that convention even if access control was enforced.

> > Now, if developers become careless because they think data hiding will
> > save them, then that would be a problem.
>
> If you believe data-hiding will protect your code from fraud, sabotage
> or any other malevolence, then you already have this problem IMHO.

I addressed this red herring above.