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

[Mark Wooding]

Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes:

> I did? Where did I make that assumption?

I inferred it from the juxtaposition, apparently in error.  Sorry.

> What I said was that the model "The code is the whole team's ownership" 
> doesn't work well for large projects. *One* reason it doesn't work for 
> large projects is that you will invariably have cowboys who, given half a 
> chance, will code irresponsibly *if you let them* by encouraging the 
> attitude that, sure, that class written by the database backend team 
> belongs to everyone, never mind that you're in the UI team, go right 
> ahead and use whatever internals you like.

`Cowboys' will code irresponsibly anyway; they need reeducating gently
with a stick.

>> Such things need discussing, with some
>> appropriate level of formality, with the people most involved with the
>> relevant code -- which might be anything between a quick chat with the
>> bloke across the room or an agenda item on the next team meeting to a
>> written proposal.
>
> Yes, and when you have hundreds of developers working on the project,
> the chances are quite good that there will be twenty such agenda items
> every week, and then the project will bog down on arguments about what
> needs to be private and what doesn't, until the project manager just
> makes a blanket ruling No Access To Internals Full Stop.

Err... you've wandered off the track here.  The purpose of the proposed
changes is to expose the right interfaces so that people don't need to
fiddle with internals.  If I've discovered that I need to dredge
something out of the middle of your module, I have three choices:
(a) somehow get your module changed so that it hands me the information
I want through a documented interface, (b) suck your module's brains out
through a straw whether the interface lets me or not, or (c) lose.  The
agenda items are supporting (a), which I thought you were in favour of;
you certainly seem to be against (b), and (c) doesn't look appealing.

> And then, you know what, the project still manages to go
> forward. Instead of spending 15 minutes hacking the existing Foo class
> to do what they want, and then 15 hours dealing with the cascading
> bugs when the class changes, people simply spend 7 hours subclassing
> Foo to get what they want, and it's all good and not the end of the
> world.

Subclassing hardly fixes these sorts of problems well.  Hardly any class
libraries are documented sufficiently well enough to support subclassing
properly.  Have a look at the CLOS MOP specification

        http://www.lisp.org/mop/index.html

for a rare example of how to do it right.

> Besides, "better programmers" are in short supply. Sometimes you have
> to use who you've got, because Guido and the timbot are working
> somewhere else and you can't afford them. That's why we have languages
> like Python: so that *ordinary* programmers can be as productive as
> genius programmers in languages like C.

Why waste genius programmers on churning out C?  Just imagine how much
they could do with something like Python!

-- [mdw]