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

[Steven D'Aprano]

That would be a backward incompatible change to a published interface,
something that should not be done without a good reason, and which was
mostly avoided through the whole Python 2.x series (incompatible changes
were saved for Python 3.0). Changing an undocumented and supposedly
private interface is something different entirely.

We're not talking specifically about Python standard library changes,
we're talking about any project which may have more entertaining *cough*
policies regarding API changes.

Or if you prefer... some projects take the philosophy that the API isn't
fixed until version 1.0, and so they can change anything until then.

It seems to me that Russ' latest objection to _private names is not
specific to _private names. The same problem:

"You will get no warning at all. You will just be inadvertently
creating a new "private" attribute -- and the assignment that you
really want will not get done."

occurs with public names as well.

However, I do see his point that if we take the presence of a leading
underscore in the name as semantically significant, then we're recording
that information *everywhere* instead of in one place. That is a lesser
version of Hungarian notation -- not as bad as redundantly storing type
information that the compiler already knows, but still not ideal.

 

[Paul Rubin]

We're not talking specifically about Python standard library changes,
we're talking about any project which may have more entertaining *cough*
policies regarding API changes.

Oh, yes, I see what you mean. That's a problem even in small
projects, sometimes even in 1-person projects.

 

[Mark Wooding]

But what if you type "mumble._seekrit" in several places, then the
library implementer decides to give in to your nagging and makes it
"public" by changing it to "mumble.seekrit".

There's a possibly better fix: introduce a property `seekrit' (or
perhaps a better name!) which diddles the _seekrit attribute under the
covers.

Now suppose you forget to make the corresponding change somewhere in
your code, such as

mumble._seekrit = zzz

You will get no warning at all. You will just be inadvertently
creating a new "private" attribute -- and the assignment that you
really want will not get done.

True. That's a shame. It'd be nice if there were a way to fix that.
There's this __slots__ thing I keep hearing about...

For that matter, the library implementer himself could make the same
mistake and get no warning.

He could do. Why he didn't do a search and replace like any sensible
person is a mystery. Testing is good, too.

When you think about it, you soon realize that the leading underscore
convention violates the spirit if not the letter of one of the first
principles of programming 101: if you have a constant parameter that
appears in several places, assign the literal value in one place
rather than repeating it everywhere.

You mean `once and only once'. Yeah, I like that one too.

Then if you need to change the value, you only need to change it in
one place. That reduces effort, but more importantly it reduces the
potential for error. The same principle applies to "declaring" an
attribute private.

Introducing a property hides the problem, but doesn't actually solve it,
because you're right on this. Fortunately the problem doesn't actually
come up that often. But yes, basically, I agree with you on this
particular point: it's easier to add an alias than to rename, which
avoids the problem but is error prone.

-- [mdw]

 

[Russ P.]

It seems to me that Russ' latest objection to _private names is not
specific to _private names. The same problem:

"You will get no warning at all. You will just be inadvertently
creating a new "private" attribute -- and the assignment that you
really want will not get done."

occurs with public names as well.

That is true. Any name change could cause that sort of problem. But I
brought it up specifically in reply to Mr. Wooding, who pointed out
that it is hard to "accidentally" type a name with a leading
underscore without realizing what you are doing.

You may fully understand what you are doing when you type it, but you
may not realize what has happened later when you forget to change it
to be consistent with the new version of the library (or another
module in an application).

To change an attribute from private to public, the leading-underscore
convention requires that every occurrence of the name be changed. That
is more error prone than if the change only needs to be done in one
place. And the fact that Python allows you to create new attributes on
the fly also contributes to this problem, of course. That makes
renaming and refactoring riskier in general in Python than in
statically typed languages with enforced access restrictions. More
care and attention to detail is needed to do it right in Python.

 

[Mark Wooding]

[snip stuff I don't disagree with]

That makes renaming and refactoring riskier in general in Python than
in statically typed languages with enforced access restrictions. More
care and attention to detail is needed to do it right in Python.

In fact, I don't disagree with this statement either. It's just that I
think there's a legitimate tradeoff between the assurances you can get
from a language designed for static analysis and strictness, and the
freedom and dynamicness of languages like Python. It's just that I
rather like where Python is now on this continuum, and disagree that
shifting it is necessarily a good idea.

-- [mdw]

 

[Russ P.]

[snip stuff I don't disagree with]

That makes renaming and refactoring riskier in general in Python than
in statically typed languages with enforced access restrictions. More
care and attention to detail is needed to do it right in Python.

In fact, I don't disagree with this statement either.  It's just that I
think there's a legitimate tradeoff between the assurances you can get
from a language designed for static analysis and strictness, and the
freedom and dynamicness of languages like Python.  It's just that I
rather like where Python is now on this continuum, and disagree that
shifting it is necessarily a good idea.

-- [mdw]

I would like to have the option to use Python either way, if possible
-- and I honestly don't know if it is possible. The new type
annotations are a step in that direction. They are optional, but if
used they could make refactoring safer and facilitate static analysis.
Enforced access restrictions, if they can be added to Python, would be
optional too -- as they are in any language.

 

[Hendrik van Rooyen]

Oh, yes, I see what you mean. That's a problem even in small
projects, sometimes even in 1-person projects.

I think it is more prevalent in single person projects than what we
have the honesty to admit -

After all, if *I* am writing the code, then *I* can do what *I* want,
and often *I* do, much to *my* chagrin, when the effects strike
home. Do I talk about it? - No way! I just quietly fix it.

Sometimes too much freedom is not such a good thing - it leads
to all sort of effects of which API spec. creep is one of the least.

- Hendrik

 

[Bruno Desthuilliers]

Russ P. a écrit :

For crying out loud, how many private attributes do you need to
access?

May I remind you that this is an hypothetical use case ?

If it's a dozen, then you and your library developer are
obviously not on the same page. If it's one or two, then it's hardly a
"fork." Just take note of the one or two places where you needed to
remove the access restriction and you're done.

Yeah, fine. And doing it each and any release. A fork is a fork is a fork...

OK, fine, you can change the code of another member of the team.

No. I can change the *team's* code. Please *read*. "team's ownership",
ok ? Or do I have to spell it out loud ? TEAM'S OWNERSHIP. Uh. You get
the message, now ?

Are
you going to check with him first, or just do it?

<despair>I give up.</despair>

(snip)

Are you seriously saying that if you were managing the production of a
major financial software package with hundreds of developers, you
would just "trust" them all to have free access to the most sensitive
and critical parts of the program? Now *that's*, well, kind of funny,
you know?

A remote web service - for example - is a far better blackbox when it
comes to this kind of "sensitive and critical parts". If I can't trust
someone wrt/ "this" part of the code, then he won't even have it as a
binary package. Period.

Would you give all those developers your password to get into the
system? No? Wait a minute ... you mean you wouldn't "trust" them with
your password? But what about "openness"? Are you some sort of fascist
or what?

Goodwin point. You loose. Good bye again, Mr P.

 

[Bruno Desthuilliers]

Russ P. a écrit :

If the original author provides you with the source code and the right
to modify it, he cannot possibly control how you use the library. You
can trivially disable any access controls. But for some reason that's
not enough for you.

Has it occurred to you that some users might actually *want* access
controls?

Then they'll have to choose a language which provides it.

Maybe some users want to actually use the library as the
author intended it to be used.

And ? Strange enough, that's usually what happens - using the official,
documented API. Strange enough, it seems that Python programmers are
mostly wise enough to not break encapsulation (nor abuse any of the
highly dynamic features of Python) without pretty good reasons, lots of
thought and attention, clear documentation of the fact, and possibly
exchanges with the library author (or maintainer) to discuss the problem.

 

[Steve Holden]

Russ P. a écrit :

Then they'll have to choose a language which provides it.


And ? Strange enough, that's usually what happens - using the official,
documented API. Strange enough, it seems that Python programmers are
mostly wise enough to not break encapsulation (nor abuse any of the
highly dynamic features of Python) without pretty good reasons, lots of
thought and attention, clear documentation of the fact, and possibly
exchanges with the library author (or maintainer) to discuss the problem.

Quite. Python is a language "for consenting adults". It has perceived
deficiencies for certain software engineering environments. Can we drop
the subject now? This horse was flogged to death long ago, and it's
pointless and cruel to keep on beating the remains.

regards
Steve

 

[Paul Rubin]

Quite. Python is a language "for consenting adults".

Shouldn't such a language allow consenting adults to enter a BDSM
scene without being moralized at, if that's what they want to do? ;-)

 

[Tim Rowe]

Shouldn't such a language allow consenting adults to enter a BDSM
scene without being moralized at, if that's what they want to do? ;-)

The language doesn't stop you. You can shift all of your code over to
Ada if you want to, and although /some/ Pythonistas might shake their
heads in bewilderment, I don't think there would be any moralising.
The question is whether Python has to /provide/ the BDSM scene for
you. I don't think it's realistic for a language to provide every
possible degree of BDSM from BCPL to Ada, Eiffel and beyond. A
language has to be positioned somewhere on the scale, and deciding
whether that's the right point on the scale for you and your project
is part of what being a grown-up programmer is about. One size does
not fit all, one language is not ideal for all applications.

 

[Steve Holden]

Shouldn't such a language allow consenting adults to enter a BDSM
scene without being moralized at, if that's what they want to do? ;-)

Yes, but you know what moralizers are like ...

regards
Steve

 

[Bruno Desthuilliers]

Russ P. a écrit :
(snip)

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.

FWIW, it's actually *you* who are trying to dictate that access
restrictions should be enforced in Python.

 

[Russ P.]

No. I can change the *team's* code. Please *read*. "team's ownership",
ok ? Or do I have to spell it out loud ? TEAM'S OWNERSHIP. Uh. You get
the message, now ?

Team ownership doesn't necessarily mean that you can just change code
at will. In industry, teams usually have a leader that you need to
check with before you can change an interface. A language with
enforced access restriction merely provides language support for such
coordination. That was my only point.

Goodwin point. You loose. Good bye again, Mr P.

You missed the point once again. In asking if you are a "fascist," I
was *parodying* your attitude that languages with enforced access
restrictions are for "fascists" who don't trust their co-workers or
employees. [I don't recall if you actually used that word or if it was
someone else, but you did use "B&D", which carries the same general
impression.]

So I parodied your hyperbole, and you dismiss me for it. Without
realizing it, you just dismissed yourself, sir. Thanks for saving me
the trouble.

 

[Bruno Desthuilliers]

Russ P. a écrit :

Team ownership doesn't necessarily mean that you can just change code
at will.

Nope, but it surely means that I'm *not* changing "someone else's" code.

In industry, teams usually have a leader that you need to
check with before you can change an interface.

This is totally unrelated.

Goodwin point. You loose. Good bye again, Mr P.

You missed the point once again. In asking if you are a "fascist," I
was *parodying* your attitude that languages with enforced access
restrictions are for "fascists" who don't trust their co-workers or
employees. [I don't recall if you actually used that word

I did not, and you should know better.

or if it was
someone else, but you did use "B&D", which carries the same general
impression.]

Can't you tell the difference, really ?

So I parodied your hyperbole,

Still not. But it's interesting to note that you consider everyone
disagreeing with you as basically the same person.

 

[Luis Zarrabeitia]

Still not. But it's interesting to note that you consider everyone
disagreeing with you as basically the same person.

Hehe. At the beginning of this thread, I also thought that Russ P. and Paul
Robin were the same person. I have serious problems with names.

[My apologies to both of you, if I said something that made you notice my
confusion].

P.S: Just to be clear, I'm neither Russ P. nor Paul Robin

 

[Hendrik van Rooyen]

Hehe. At the beginning of this thread, I also thought that Russ P. and Paul
Robin were the same person. I have serious problems with names.

*nods in agreement, because the man's surname is Rubin, not Robin*



- Hendrik

 

[Michele Simionato]

CLOS is much more complex and dynamic than Python's object system; > but it can be compiled very aggressively.

I agree that CLOS is complex and that it can be compiled very
aggressively, but I do not think that it is more dynamic than Python.
What feature are you alluding to? Multimethods? There are many Python
implementations of them, they are just not in the standard library.
Or are you referring to interactive facilities, such as the one
discussed in this recipe http://code.activestate.com/recipes/160164 ?

 

[Russ P.]

Quite. Python is a language "for consenting adults". It has perceived
deficiencies for certain software engineering environments. Can we drop
the subject now? This horse was flogged to death long ago, and it's
pointless and cruel to keep on beating the remains.

Judging from this thread, not everyone got the memo yet. At least
three or four people on this thread alone have argued that enforced
data hiding is of no value whatsoever for any application or domain.
And more than one of them has argued that Python is perfectly
appropriate for even the largest and most safety-critical projects.

We are moving into an era of increasing dependence on computers and
software for safety-critical, mission-critical, and financial
systems. If people who do not understand the principles necessary for
ultra-reliable software get in charge of developing these systems, we
will have serious problems that could have been avoided.

I suggested that maybe -- maybe! -- the versatility of Python could be
enhanced with enforced data hiding. I was careful to say several times
that I don't know if that can even be done in Python (with all its
introspection and so forth). And it would always be optional, of
course (as far as I know, no language forces anyone to declare
anything private).

Several people here seem to take that suggestion as an assault on
Python and, by projection, an assault on their worldview. We all know
that Python is a fantastic language for many purposes, but it is only
a language, and failing to recognize and address its limitations
serves no useful purpose.