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

[Steven D'Aprano]

On Fri, 23 Jan 2009 10:54:53 +0100, Bruno Desthuilliers wrote:

>> In context, I had just mentioned that lists' internals were
>> inaccessible from Python code. I neglected to give an example at the
>> time, but a good example is the current length of the list. Consider
>> the experience of Microsoft and Apple.
> 
> Yes, two great examples of freedom champions.

What does that little dig at Microsoft and Apple have to do with what 
we're discussing? I dare say Linux has private internals too. Let's see 
if we can find some in 30 seconds of googling.

http://forum.soft32.com/linux2/Bug-406747-linux-kernel-headers-private-
symbols-u16-u32-asm-ftopict67443.html

http://groups.google.com/group/linux.kernel/browse_thread/thread/
a08fd6423204e918

Those fascists! Private data in the kernel!!! Why can't my userland app 
mess with the kernel's private data??? It's so unfair!!!



>> No matter how often
>> they tell people not to mess with the internals, people do it anyway,
>> and always believe that their reason is a good reason.
> 
> And who are *you* to pronounce any judgement about that ?

Did I pronounce any judgement?


...
>> [Any] library writer must assume
>> that if he changes his so-called "private" attributes, he will break
>> other people's code.
> 
> You still don't get the point. If someone's code breaks because he
> messed with my implementation code, then *he* is responsible. The
> contract is very clear : "warranty void if unsealed".

You've built something full of user serviceable parts. You've insisted, 
publicly and loudly, that the ability to modify those parts is absolutely 
essential, you've rejected every effort to lock down those internals, and 
then when somebody does exactly what you encourage, you suddenly turn on 
them and say they're on their own.

That's pretty irresponsible behaviour. 

As an aside, Apple and Microsoft have opposite approaches to dealing with 
this problem. Apple hangs the developer out to dry, which is why there 
are so few developers who make Mac software, while Microsoft goes to (or 
at least did) heroic efforts to protect developers from their mistakes, 
which is why the Windows internals is a dog's breakfast but there are 
more Windows developers named "Steve" then there are Mac developers in 
total. (BTW, I'm not one of them.)

http://www.joelonsoftware.com/articles/APIWar.html



> Now that you've exposed your opinions, let's face reality (I mean,
> *facts*): Python developpers very rarely mess with implementation,
> usually do so for very good (and documented) reasons, and from what I've
> seen usually tend to get in touch with the library author to explain
> their case and find a better solution.

Facts, are they? Care to provide some reputable sources for these facts?

 
> Funny enough, it looks that the more you treat programmers as
> responsible, normally intelligent adult person, the more they tend to
> behave as such. And the other way around, too.

You're the one who repeatedly declared that programmers who modified 
internals were cretins who should be fired. I never said such a thing -- 
in fact, I defended them.


> Now, you comprehensively exposed your personnal distaste for Python's
> and more generally OSS philosophy. 

Really? I did? Fancy that.


> So I can only - as I already did way
> before in this thread - wonder *why* are you using Python ?

Ah yes, the old "if you're not 100% for us, you must be 100% against us" 
argument. Anyone who thinks that there are costs as well as benefits to 
dynamic programming must be a freedom-hater, and probably kicks puppies 
too.

 
> I mean, is it because your bosses forces you to do so ? 

Yeah, my mean old boss forces me to write Python scripts in my spare 
time, he forces me to spend my personal time on comp.lang.python, he 
forces me to write things like:

[quote]
Oh yes, it is liberating to say "I don't care if my method crashes 
(raises an exception), it's the caller's fault for messing with my class' 
internals, and he can deal with it". I'm not being sarcastic by the way. 
It really is liberating not to have to deal with unexpected input or 
broken pre-conditions. Just let the caller deal with it!
[end quote]

What a mean old boss!


> If yes, then,
> I'm truly sorry for you - I sometimes have to work with languages I
> really dislike so I can feel your pain (but OTHO, I never complained on
> these languages newsgroups about how wrong they were nor how they should
> IMHO be).

If people hadn't complained about missing features/misdesigns, would 
Python have:

generator expressions
print as a function
booleans
nested scopes
None as a keyword
ABCs
closures

to name just a few?

I am curious though... you've made a few comments that suggest that your 
in favour of more freedom, rather than less: you've made a disparaging 
comment about Microsoft and Apple, you apparently think highly of Open 
Source software, and more. Does this freedom extend to people who have 
criticisms -- even mild criticisms -- of Python?

 
> Else, well, I just don't get the point. What you are fussing about are
> fundamental design choices (and philosophic points) that are well known,
> explained, advertized, etc. - and are really not likely to change
> anytime soon.

No, probably not. Any such changes would have to start off as an external 
tool first. I'd guess that it couldn't even be considered as part of the 
base language until Python 4, which is probably a decade away.

This is a good thing. There are, as you have so often pointed out, many 
B&D languages out there, and they are a PITA to use. Nobody wants to make 
Python unpleasant to use, but if you think data hiding is automatically 
unpleasant, then you must *hate* calling len() on a list, because that 
uses private data inaccessible to Python code. That's data hiding.

It will probably take a decade of experiments to find a way to get as 
many of the benefits of data hiding as possible with as few of the costs 
as we can get away with. It may even be that it is impossible to do so, 
that you can't get the safety of data hiding without the pain. Who knows? 
I think it's an experiment worth trying.

And for all those who insist that Python will never have data hiding 
except by convention, a few years ago I was saying that Python would 
never have static types, because of fundamental design choices to make 
Python a dynamic typed language. And now Python has ABCs, and optional 
type annotations, and Guido is encouraging people to experiment with 
tools that do things with those type annotations, things like type 
inference, and if they become popular and useful, they may end up in the 
language itself.

As has been frequently pointed out, Python is not Java. Java is obsessed 
with the past, while Python is forward-looking.

http://cafe.elharo.com/programming/java-is-dead-long-live-python/

Thank goodness for that.


-- 
Steven