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

[Roy Smith]

I can claim that Python is not strictly object oriented until it
gets encapsulation (in the sense of data hiding). That is simply a
fact, and no amount of pleading or obfuscation will change it.

I have no idea if Python is strictly anything. What I do know is that it's
a useful tool. I'll take useful over OOO (Object Oriented Orthodoxy) any
day.

People get all worked up over OO as if it were some kind of religion. If I
want religion, I'll go to shul. What I want from a programming language is
a tool that lets me get my work done. If I transgress against some sacred
tenet of OO religion, it is, as Rev. Dupas would say, all right.

Earlier in this thread, somebody (name elided to avoid me getting pegged
for a indulging in a spelling flame):

Bare in mind also, that enfocing access control / policing as you
called it has a performance hit as the machine (the Python vm)
has to perform checks each time members of an object are accessed.

All I can say to that is, "He who bares his mind, soon gets to the naked
truth".

 

[Russ P.]

Is this seriously your argument?  Python must be moving towards data
encapsulation because there is a line in Python.org that, if you
blindly accept the Wikipedia definition as truth, indirectly implies
that it is?

Are you *seriously* arguing this?

Did you read what I wrote? If so, you apparently didn't understand it.

The argument is too ridiculous to deserve a refutation, so I'll just
point out two things:

1. Wise people don't believe everything that is written on Wikipedia.

Nice try at diverting attention. The issue is not Wikipedia. As far as
I know, the definition of OOP given on Wikipedia is not controversial
-- at least not anywhere but here.

2. The person who wrote that line in Python.org is a wise person.

Oh, isn't that wonderful. Wow, I sure wish I was wise like that
person!

You know what?  Computer science buzzwords mean jack squat to me.  I
don't give a horse's tail whether some people label it a fundamental
concept of object-oriented programming or not.  I think it's a bad
thing.  And it's a bad thing for exactly the reason I said: it gives
the library implementor the power to dictate to the user how they can
and can't use the library.  The cultural impact that would have on the
community is far worse, IMHO, than any short-sighted benefits like
being able to catch an accidental usage of an internal variable.
Trust would be replaced by mistrust, and programming in Python would
go from a pleasant experience to constant antagonism.

No thanks.  "Software engineering" be damned.  Python is better off
the way it is.

Now that's just classic. "We have Python and we don't need no stinkin'
software engineering." Well, you may not need it in your line of work,
but I need it in mine. In my line of work, Python is a tool, not a
religious faith.

 

[r]

Here is a piece of C code this same guy showed me saying Pythonic
indention would make this hard to read -- Well lets see then!

I swear, before god, this is the exact code he showed me. If you don't
believe me i will post a link to the thread.

// Warning ugly C code ahead!
if( is_opt_data() < sizeof( long double ) ) { // test for insufficient
data
return TRUE; // indicate buffer empty
} // end test for insufficient data
if( is_circ() ) { // test for circular buffer
if( i < o ) { // test for data area divided
if( ( l - o ) > sizeof( long double ) ) { // test for data
contiguous
*t = ( ( long double * ) f )[ o ]; // return data
o += sizeof( long double ); // adjust out
if( o >= l ) { // test for out wrap around
o = 0; // wrap out around limit
} // end test for out wrap around
} else { // data not contiguous in buffer
return load( ( char * ) t, sizeof( long double ) ); // return
data
} // end test for data contiguous
} else { // data are not divided
*t = ( ( float * ) f )[ o ]; // return data
o += sizeof( long double ); // adjust out
if( o >= l ) { // test for out reached limit
o = 0; // wrap out around
} // end test for out reached limit
} // end test for data area divided
} else { // block buffer
*t = ( ( long double * ) f )[ o ]; // return data
o += sizeof( long double ); // adjust data pointer
} // end test for circular buffer


if i where to write the same code in a 'Python style" it would look
like below. And personally i would never use that many comments in my
code. I normally in a situation as this one would only comment each
major conditional code block, and only if it contains code that is not
completely obvious. Commenting is important, but it *can* be over
done.

#-- Python Style --#
if is_opt_data() < sizeof(long double):
return TRUE
if is_circ():
if i < o: #test for data area divided
if (l-o) > sizeof(long double): #test for data contiguous
*t = ( ( long double * ) f )[ o ]
o += sizeof( long double )
if o >= l:
o = 0
else: #data not contiguous in buffer
return load((char*) t, sizeof(long double))
else: #data are not divided
*t = ((float*) f)[ o ]
o += sizeof(long double)
if o >= l: #test for out reached limit
o = 0
else: #block buffer
*t = ((long double*) f)[ o ]
o += sizeof(long double)

WOW!, without all the braces, and over commenting, i can actually
read this code now! Of course it would not run in C or Python but the
point here is readability. Python forged the path for all 21st century
languages. Get on board, or get on with your self.extinction() -- Your
Choice!

 

[Russ P.]

Wrong. Not having strict and enforced access control 9_NOT_ encapsulation)
(Please stop confusing the two) is not a strict requirements of the OO model.

I think you are the one who is confused. Part of the problem here is
that the term "encapsulation" has at least two widely used meanings
(in the context of programming). In one sense, it just means grouping
data and methods together. In another sense, it means restricting the
client's access to data or methods. Someone earlier on this thread
tried to claim that the first meaning applies to OOP, but Wikipedia
(and many other sources) say just the opposite.

People here are trying to claim that the leading underscore
conventions used with Python are essentially equivalent to
encapsulation. That is nonsense, of course.

Others are arguing against encapsulation altogether. That is a bit
like being against locks or passwords because they create a lot of
hassle. Now locks are not needed everywhere, of course, but certainly
they have their place. But the point is that if you don't like
encapsulation, then by definition you don't like OOP. You may like
certain features of OOP, but you don't like it in general. That's
about all their is to it.

And by the way, please don't bring up the canard that I am some kind
of OO zealot. I think OO is overrated, and I don't Java, in part
because it forces everything to be OO. The issue here is not my
personal opinion of OOP. This issue is one of widely accepted
definitions within the OO community.

Remember that it is a model and not a strict set of requirements that
programming
languages must implement.

Of course it's not a "requirement that programming languages must
implement." It's only a requirement if they want to be OO languages.

In fact, Python borrows features from the Functional Paradigm. Does this
make it a Functional Language ? No. Why ? Because one of the clear
requirements of the Functional Paradigm is that functions cannot have
side affects.


In fact this is true, C can be seen as an programming language
that has features of the OO model.

I think one of the things you guys are missing out
here is that there are really only two Paradigms
or Machines. Functional and Imperative. And guess
what ? As it turns out we can implement functional
machines that run on top of imperative ones!


Again, stop confusing terminology.

Should Python get strict and enforce access control
of object members ? No. Why ? I can think of several
reasons.

Give me one use-case where you strictly require
that members of an object be private and their
access enforced as such ?

You're kidding, right? Think about a ten-million line program being
developed by 100 developers.

 

[James Mills]

You're kidding, right? Think about a ten-million line program being
developed by 100 developers.

No I"m sorry this is not a valid use-case.

cheers
James

 

[Russ P.]

You know what?  Computer science buzzwords mean jack squat to me.  I
don't give a horse's tail whether some people label it a fundamental
concept of object-oriented programming or not.  I think it's a bad
thing.  And it's a bad thing for exactly the reason I said: it gives
the library implementor the power to dictate to the user how they can
and can't use the library.  The cultural impact that would have on the
community is far worse, IMHO, than any short-sighted benefits like
being able to catch an accidental usage of an internal variable.
Trust would be replaced by mistrust, and programming in Python would
go from a pleasant experience to constant antagonism.

No thanks.  "Software engineering" be damned.  Python is better off
the way it is.

You know what? The more I think about the kind of nonsense you and
others are spouting here, the more annoyed I get. I will gladly agree
that encapsulation may be more trouble than it's worth for small
applications, maybe even some medium sized ones, but you and others
here are making blanket proclamations that are just plain nonsense.

I suggest you call Boeing and tell them that encapsulation is more
trouble than it's worth for their 787 flight software. But please
don't do it if you ever wish to work for them, because you will be
proving conclusively that you don't have a clue about the kind of
software systems they produce.

I've wasted more than enough time with this nonsense.

 

[James Mills]

I think you are the one who is confused. Part of the problem here is
that the term "encapsulation" has at least two widely used meanings
(in the context of programming). In one sense, it just means grouping
data and methods together. In another sense, it means restricting the
client's access to data or methods. Someone earlier on this thread
tried to claim that the first meaning applies to OOP, but Wikipedia
(and many other sources) say just the opposite.

People here are trying to claim that the leading underscore
conventions used with Python are essentially equivalent to
encapsulation. That is nonsense, of course.

Others are arguing against encapsulation altogether. That is a bit
like being against locks or passwords because they create a lot of
hassle. Now locks are not needed everywhere, of course, but certainly
they have their place. But the point is that if you don't like
encapsulation, then by definition you don't like OOP. You may like
certain features of OOP, but you don't like it in general. That's
about all their is to it.

And by the way, please don't bring up the canard that I am some kind
of OO zealot. I think OO is overrated, and I don't Java, in part
because it forces everything to be OO. The issue here is not my
personal opinion of OOP. This issue is one of widely accepted
definitions within the OO community.

Russ:

1. Quit while you're ahead.
2. OOP is encapsulating data and functionality into a single grouping (object).
3. Other features more recently developed by OO languages such as
Polymorphism, Access Control (a type of encapsulation), Inheritance
and Multiple Inheritance are all irrelevant and OO languages either
implement all or a subset of these features and each do so
differently.

Fundamentally it all boils down to4 things (which all of you -
including you Russ - just completely miss the point):

READ
UPDATE
ADVANCE

These are the 3 operations of a Turing machine of which all
computer algorithms can be defined. We usually define a 4th operation
called HALT.

Now go ponder on that a while and come back and tell
me whether you think you really need such things as
Abstract Base Classes, Interfaces, Access Control,
Static Typing, and so on and so forth ...

You're kidding, right? Think about a ten-million line program being
developed by 100 developers.

And what is your point exactly ? Like I said, this is _not_ a valid
use case. A language that implements all of the features descirbed
in academic texts on OOP will not help you build such a system
any faster.

I should also point out that building such a system in Python would
most likely result in 1/3 of the size in terms of LoC.

I should also point out that your numbers you pulled out of your
hat would require 22years of development time given the industry
standard of 5 LOC/hg per developer. Good luck with that.

cheers
James

 

[James Mills]

You know what? The more I think about the kind of nonsense you and
others are spouting here, the more annoyed I get. I will gladly agree
that encapsulation may be more trouble than it's worth for small
applications, maybe even some medium sized ones, but you and others
here are making blanket proclamations that are just plain nonsense.

I suggest you call Boeing and tell them that encapsulation is more
trouble than it's worth for their 787 flight software. But please
don't do it if you ever wish to work for them, because you will be
proving conclusively that you don't have a clue about the kind of
software systems they produce.

I've wasted more than enough time with this nonsense.

I am 100% confident that those same systems could be
well written in a language such as Python and would very
likely end up being much smaller and more manageable.

I have a question for you:

All your arguments seem to lean towards size and the
importance of encapsulation. What is the largest system
you have worked on - that has been written entirely in Python ?

cheers
James

 

[Steven D'Aprano]

No I"m sorry this is not a valid use-case.

Why not? Just saying it isn't doesn't make it not.

 

[Carl Banks]

I suggest you call Boeing and tell them that encapsulation is more
trouble than it's worth for their 787 flight software. But please
don't do it if you ever wish to work for them, because you will be
proving conclusively that you don't have a clue about the kind of
software systems they produce.

That's funny. I worked for four years at a GE Aviation subcontractor
on their jet engine control software, so I think do I have a clue
about how flight control software systems work.

At GE there was no encapsulation in sight on any system I worked on.
In fact, our engine simulation was a special-purpose object-oriented
language with--get this--no private variables. Some other systems I
worked on didn't even use scoping, let alone encapsulation.

Looks like my anecdote cancels out yours! Got any more?


Carl Banks

 

[Steven D'Aprano]

And I'll give you a perfect example:

XML-DOM versus ElementTree

XML-DOM is the sort of standard that is borne of a culture that values
encapsulation, strict type safety, and so on. It's the way it is
because designers were allowed to distrust the user, and the culture
said that it was good to distrust the user. Consequently, the interface
is a pain to use, with all kinds of boilerplate and iterator types and
such.

ElementTree was borne out of an environment where implementors are
forced to trust the user. As a consequence it was free to create an
interface that was natural and straightforward and pleasant to use,
without having to be guarded.

Which is all well and good, but there are circumstances where you *don't*
want to trust arbitrary parts of your code to change other parts of your
code, for good reason. In other words, you don't always want to trust
your users.

Forget copy protection and DRM. Think about the software controlling a
radiation machine for cancer treatment, with a limit on the number of
rads it fires at any one time. It would be disastrous for any arbitrary
function in the machine's software to be able to mess with that limit,
accidentally or deliberately. People will die if you get it wrong.

My attitude when programming in Python is to accept that if the caller
passes an inappropriate argument to my function, my function may crash
(raise an exception). That's the caller's responsibility. I can get away
with this laissez faire attitude because I don't have to worry about my
software crashing at the wrong time and causing a plane filled with 500
nuns and orphans suddenly flip upside down and nose-dive into a mountain.
Or the nuclear reactor to suddenly drop all the fuel rods into the core
simultaneously. Sometimes "oh, just raise an exception and exit" is
simply not good enough.

Security/safety and freedom/flexibility are sometimes in conflict. There
are plenty of languages which enforce access. It is a good thing that
Python allows more flexibility. That's why I use Python. The traditional
answer to this "if you need Java, you know where to get it".

But, gosh darn it, wouldn't it be nice to program the critical parts of
your code in "strict Python", and leave the rest as "trusting Python",
instead of having to use Java for the lot just to get strictness in the
critical parts? If only there was a way to do this, and ensure people
won't abuse it.

 

[Paul Rubin]

At GE there was no encapsulation in sight on any system I worked on.
In fact, our engine simulation was a special-purpose object-oriented
language with--get this--no private variables. Some other systems I
worked on didn't even use scoping, let alone encapsulation.

Where my officemate used to work, the simulation stuff was written in
Matlab, but the actual flight stuff was written in Ada. I wonder
if GE did something similar.

 

[Carl Banks]

Which is all well and good, but there are circumstances where you *don't*
want to trust arbitrary parts of your code to change other parts of your
code, for good reason. In other words, you don't always want to trust
your users.

Forget copy protection and DRM. Think about the software controlling a
radiation machine for cancer treatment, with a limit on the number of
rads it fires at any one time. It would be disastrous for any arbitrary
function in the machine's software to be able to mess with that limit,
accidentally or deliberately. People will die if you get it wrong.

I'm on record saying Python shouldn't be used for systems with the
possibility of catastrophic failure: that's with or without
encapsulation. Too much happening internally to account for it all.

Frankly I'm not sure that C++ and Java's encapsulation is good enough,
either. Software-enforced encapsulation can be subverted, and
sometimes invalid access can happen from within the protection zone.
If something's that important, it needs to be running with redundancy
and lots and lots of fault tolerance, and it needs to have the hell
tested out of it. If it's critically important, the code should be
storing the critical information in a separate data area with a higher
privledge level than the rest of the program. The simpleminded
encapsulation schemes of C++ and Java are weak compared to these
methods, and probably wouldn't add much.

As I said, I've worked on flight control systems that didn't use any
data hiding at all. Even if a drastic coding mistake like you
mentioned was able to make it though dozens of peer reviews and
hundreds of tests, it still might not result in catastrophic failure
because of all the fault tolerance built-in.



Carl Banks

 

[Russ P.]

Where my officemate used to work, the simulation stuff was written in
Matlab, but the actual flight stuff was written in Ada.  I wonder
if GE did something similar.

I was going to suggest the same thing. An engine *simulation* is one
thing; the actual engine control code is another. And the interface
between the engine control code and the rest of the flight software is
yet another. The FMS should be setting the throttle level, but I doubt
it should be fooling around with the guts of the engine control
software.

 

[Russ P.]

But, gosh darn it, wouldn't it be nice to program the critical parts of
your code in "strict Python", and leave the rest as "trusting Python",
instead of having to use Java for the lot just to get strictness in the
critical parts? If only there was a way to do this, and ensure people
won't abuse it.

Yes, that would indeed be nice. I am certainly not the only one who
could use a language that is excellent for both research prototyping
*and* the final, safety-critical system. Then perhaps the prototype
could just be cleaned up and "hardened" for the end product rather
than rewritten in another language -- by programmers in another state
who may fail to understand many of the details that the prototype
developer agonized over.

I don't know if such a versatile language could even exist, but it
would sure be valuable. Maybe it's like asking for a football player
who can excel as both a wide receiver and a guard. But players who
weigh 280 pounds and run a 4.4 40 are hard to find.

 

[Carl Banks]

I was going to suggest the same thing.

I thought you were done wasting time with this nonsense.

An engine *simulation* is one
thing; the actual engine control code is another.

Guess what systems I worked on that didn't even use scoping? I wrote
code for the GP7000 (equipped on some Airbus 380s) and the F-136
(which will be equipped on some F-35 fighters) engine controllers.
Neither one used any data hiding. The language was C (not C++), but
it was generated from schematic diagrams.

Would you like to adopt GE's practice of schematic-generated C with no
namespaces or data hiding? No? Then don't be telling me I have to
embrace Boeing's.


Carl Banks

 

[Bruno Desthuilliers]

Russ P. a écrit :
(snip)

I think the issue here is the distinction between hacking and software
engineering. I may be misusing the term "hacking," but I do not mean
it in a pejoritive sense. I just mean getting things done fast without
a lot of concern for safety, security, and long-term maintainability
and scalability.

I do feel concerned by these issues.

I'm not a computer scientist, but it seems to me that
Python is great for hacking and good for software engineering, but it
is not ideal for software engineering.

What Paul is suggesting, I think, is that Python should move in the
direction of software engineering. Whether that can be done without
compromising its hacking versatility is certainly a valid question,
but if it can be done, then why not do it?

Certainly one basic principle of software engineering is data
encapsulation. Tacking new attributes onto class instances all over
the place

There's a clear distinction between "making wise use of dynamicity" and
"tacking new attributes onto class instances all over the place".

may be convenient and useful in many cases, but it is not
consistent with good software engineering.

simplicity is "good software engineering". Accidental complexity is not.
Dynamism _can_ greatly reduce accidental complexity.

If the programmer could
somehow disallow it in certain classes,

Already possible - you just have to provide your own implementation of
__setattr__.

that could be useful,
providing that those who wish to continue doing it would be free to do
so. If class attributes could somehow be declared private,

The important point is to make implementation distinct from interface -
which we already know how to do -, and sometimes to prevent _accidental_
overriding of some critical implementation attributes - which is also
already implemented. Enforcing access restriction is, from experience,
just pointless.

"""
patient : doctor, when I do this, it hurts
doctor : well, don't do it, then.
"""

 

[Marc 'BlackJack' Rintsch]

Why not? Just saying it isn't doesn't make it not.

Because "developer" means people who don't mess with implementation
details. So they respect the leading underscore convention. No use case
for enforced access restriction.

Ciao,
Marc 'BlackJack' Rintsch

 

[Terry Reedy]

But, if something is done by convention, then departing from the
convention is by definition unconventional. If you do something
unconventional in a program, it could be on purpose for a reason, or
it could be by accident indicating a bug.

I don't understand why some folks spew such violent rhetoric against
the idea of augmenting Python with features to alert you automatically
when you depart from the convention, so that you can check that the
departure is actually what you wanted. A lot of the time, I find, the
departures are accidental and automated checks would save me
considerable debugging.

The question is where such checks should be. Guido prefers separate
checkers (PyChecker, PyLint) rather than in the interpreter. If you
think they are incomplete, help improve one of them.

 

[Steven D'Aprano]

Because "developer" means people who don't mess with implementation
details. So they respect the leading underscore convention. No use
case for enforced access restriction.

O rly? *raise eyebrow*

http://www.clausbrod.de/cgi-bin/view.pl/Blog/
WebHome#DefinePrivatePublic20080413_This

or http://snipurl.com/a0ujm

Sometimes developers have to work around encapsulation in their own code:
http://www.gamedev.net/community/forums/topic.asp?topic_id=386856

Sometimes they do it just because they can:

http://java-interview-faqs.blogspot.com/2008/08/hacking-by-reflection-
accessing-private.html
or http://snipurl.com/a0tox

And try this:

http://www.google.com/codesearch?q="#define+private+public"