is python Object oriented??

Steve Holden steve at
Sun Feb 1 20:53:55 EST 2009

Steven D'Aprano wrote:
> On Sun, 01 Feb 2009 12:31:27 -0500, Steve Holden wrote:
>> I think it's noticeable that the people who have been arguing against
>> what I might tipify as this "libertarian view" are those for whom the
>> consequences of programming error are serious to extreme.
> ...
>> Just the same, it still doesn't save them from the consequences of
>> interface miscommunication, as int he case of the Mars lander that
>> crashed because one module provided a (probably strongly-typed) value in
>> meters, and the recipient interpreted it as (probably strongly-typed)
>> feet, cutting the engine out too early.
> Of course. Nor will data hiding prevent off-by-one errors, or errors of 
> logic, or data corruption, or stray cosmic rays flipping bits in memory. 
> But it will prevent *some* errors. It's one tool in an entire toolbox for 
> writing correct code, not a magic bullet.
> Python already has enforced data hiding, but only for built-ins. 
> Consequently, anyone who uses a list can absolutely, categorically trust 
> that len(alist) will return the actual length of alist, and not some 
> mangled value stuffed into alist by some arbitrary piece of code 
> somewhere else.
Unless, of course, some piece of code masks (or worse still, replaces)
the len() function in __builtins__ with one of their own. There's no
such thing as a foolproof system. The minute you think you have one the
world comes up with a superior class of fool.

> (For those unaware, in CPython lists are arrays. They store the current 
> length as a private value inaccessible to Python code.)
> Short of cosmic rays flipping bits, any built-in list you receive from 
> anywhere is going to have a valid length, and no pure-Python code can 
> make it invalid. To read some of the posts in this thread, one would be 
> forgiven for thinking that this most be a disaster of the highest 
> consequences, unPythonic to the extreme, an example of unfree B&D 
> programming so unpleasant to work with that people hate every second of 
> it.
> Except of course it isn't. Nobody sensibly complains that they can't 
> mangle the length of a list, or move keys around inside dicts, or 
> whatever. This data hiding is a good thing.
> All I want is the ability to do with Python classes what I can do with C 
> extension types. I don't think that's an *unreasonable* ask, even if it 
> is *unpractical* given the current design of Python.
I think the whole issue has received far more attention than is good for
it. Your requirements seem quite reasonable to me, even though I doubt
I'd ever use them. But it isn't *me* you have to persuade to get them in
the language, is it?

Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC    

More information about the Python-list mailing list