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? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list