Underscore data hiding (was python development practices?)

Steve Holden sholden at holdenweb.com
Fri Nov 2 19:28:09 CET 2001

"Cliff Wells" <logiplexsoftware at earthlink.net> wrote ...
> On Friday 02 November 2001 04:19, Steve Holden wrote:
> > I don't see why. It's a documented part of the language, so a change
> > create backward incompatibility known to be anathema to the development
> > team.
> People keep insisting that the Python development team won't introduce
> changes that break backward compatability.  This may be true for the most
> part, but it is definitely not written in stone (or even Python).  From
> 2.0 docs for socket.bind():
> "Bind the socket to address. The socket must not already be bound. (The
> format of address depends on the address family -- see above.) Note: This
> method has historically accepted a pair of parameters for AF_INET
> instead of only a tuple. This was never intentional and is no longer be
> available in Python 2.0. "
This particular example was discussed endlessly when 2.0 came out. Guido
very clearly stated that the only reason he was introducing that particular
"incompatibility" was to enforce what had always been intended and, I
believe, documented. The 1.5.2 and prior implementations had been out of
spec, and some programmers had taken advantage of that fact. So breakage
only occurred when use had been made of a non-documented "buglet". It didn't
help that the library used it a few times...

> There are a couple of other places (which I don't recall at the moment)
> things were "fixed" in such a way that you would have to change existing
> code.  Granted this is a rather trivial example. However, I would
> be wary of making my code depend upon something like the name-mangling
> which is clearly a hack and actually seems a likely place to see a future
> change.

That's fair enough, and I'm not trying to argue that backwards compatibility
is a golden rule that will be enforced forever. Simply stating that, since
it *is* a documented feature of the language, there is likely to be
considerable thought and discussion before removing it or changing it in
ways that will introduce incompatibilities.

And I would agree that, since mangled names are explicitly intended to avoid
naming clashes, to actually assume that they would take a particular form
might be dangerous.


More information about the Python-list mailing list