On Jan 22, 6:30 pm, Steven D'Aprano <st...@remove-this- cybersource.com.au> wrote: > On Thu, 22 Jan 2009 19:10:05 +0000, Mark Wooding wrote: > > Steven D'Aprano <st...@remove-this-cybersource.com.au> writes: > > >> On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote: > >>> Steven D'Aprano a écrit : > >>>> But if you have free access to attributes, then *everything* is > >>>> interface. > > >>> Nope. > > >> How could anyone fail to be convinced by an argument that detailed and > >> carefully reasoned? > > > Well, your claim /was/ just wrong. But if you want to play dumb: the > > interface is what's documented as being the interface. > > But you miss my point. > > We're told Python doesn't have private attributes. We're told that we're > allowed to "mess with the internals", we're *encouraged* to do so: Python > gives you the freedom to do so, and any suggestion that freedom might be > reduced even a tiny bit is fought passionately. When people ask how to > implement private attributes, they're often told not to bother even using > single-underscore names. When it is suggested that Python should become > stricter, with enforced data hiding, the objections come thick and fast: > people vehemently say that they like Python just the way it is, that they > want the ability to mess with the internals. > > You even argued that you disliked data structures implemented in C and > preferred those written in Python because you have more ability to mess > with the private attributes. 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. 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 Python culture encourages that behaviour (albeit the consequences are > milder: no buffer overflows or core dumps). > > Add to that the culture of Open Source that encourages reading the source > code. You don't need to buy a book called "Undocumented Tips and Tricks > for Python" to discover the internals. You just need to read the source > code. > > And then you have at least two places in the standard library where > _attributes are *explicitly* public: > > http://bugs.python.org/issue3152 > > Given this permissive culture, any responsible library writer must assume > that if he changes his so-called "private" attributes, he will break > other people's code. In principle it could break just as much code as if > he didn't even bother flagging them with a leading underscore, which is > probably why many people don't even bother with _names. > > In other words, if you make it easy for people to mess with your > internals, if you have a culture that allows and even encourages them to > mess with your internals, then you don't have internals. Everything is de > facto public. > > > You can tell that your claim is simply wrong by pushing it the other > > way. If everything you have free access to is interface then all > > behaviour observable by messing with the things you have access to is > > fair game: you can rely on cmp returning one of {-1, 0, 1} on integer > > arguments, for example. > > > But no: the Library Reference says only that it returns a negative, zero > > or positive integer, and /that/ defines the interface. Everything else > > is idiosyncrasy of the implementation, allowed to change at whim. > > And yet people still assume that cmp returns -1, 0 or 1. Even Guido > himself makes that mistake occasionally. Quoting from PEP 285: > > "...you might be tempted to believe that cmp() also returned a > truth value, whereas in reality it can return three different values > (-1, 0, 1)." > > http://www.python.org/dev/peps/pep-0285/ > > No, cmp() can return an infinite number of values. It just never does, at > least not yet, but it might. But when Guido himself says that cmp() can > return three values, can you blame people for acting as if cmp() can > return three values? > > Here's a thought experiment for you. You've suggested that the values > returned by cmp() are allowed to change "at whim". Okay, let's do it: > make a patch that changes cmp() to return -17, 0 or 53, and promise to > support it for at least three years. Try to get it accepted on python- > dev. What do you expect they will say? > > My money is on them saying "No, this will pointlessly break code for no > good reason. Rejected." > > -- > Steven
Needless to say, I agree with your post. My understanding is that the vast majority of Python software is provided as open source. Hence, I am a bit confused by all the talk about the need for freedom and openness in Python. If data hiding were enforced, and you need access to something marked as private, you can just change it to public in the source code. What's the problem? Note: that change would be much easier to make if a "private" (or perhaps "priv") keyword were used instead of the leading-underscore rule. The former would require a change in only one place (per attribute), whereas the latter would require a change of every occurrence of the attribute. So "enforced" access restrictions are trivial to work around with open source. But doesn't that mean that access restriction is pointless because it cannot be enforced anyway? Of course not. In a team project, the access restrictions will be enforced on the checked-in code. You can play around with the internals all you want in your own little world, but as when you are working with a team, you need to adhere to the interfaces they define (if any). -- http://mail.python.org/mailman/listinfo/python-list
