ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> python-list
python-list
Re: Underscore data hiding (was python development practices?)
by Steve Holden other posts by this author
Nov 2 2001 6:28PM messages near this date
RE: Underscore data hiding (was python development practices?) | Re: Underscore data hiding (was python development practices?)
"Cliff Wells" <logiplexsoftware@[...].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
would
>  > 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
the
>  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
addresses
>  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)
where
>  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
definitely
>  be wary of making my code depend upon something like the name-mangling
scheme
>  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.

regards
 Steve
--
http://www.holdenweb.com/





-- 
http://mail.python.org/mailman/listinfo/python-list
Thread:
Peter Wang
Peter Hansen
Toby Dickenson
Tim Peters
Steve Holden
Steve Holden
Cliff Wells
Tim Peters
Martijn Faassen

Cliff Wells
Cliff Wells
Martijn Faassen
Martijn Faassen
Paul Rubin
Russell E. Owen
Barry A. Warsaw
Martijn Faassen
Peter Wang
Skip Montanaro
John Roth
David Bolen
Peter Wang
Peter Wang
Skip Montanaro
Chris Tavares
Darren Collins
David Bolen
Paul Rubin
Paul Rubin
Peter Wang
F Basegmez
Richard Jones

Richard Jones

Neal Norwitz
Graham Ashton
Peter Wang
Russell E. Owen
Skip Montanaro
Cliff Wells
Hung Jung Lu
Wade Leftwich
Peter Wang
Peter Wang


Peter Wang

Chris Gonnerman
Paul Rubin
Andrew Dalke
Paul Rubin
Luigi Ballabio
Paul Rubin
Tim Peters
John Roth
Paul Rubin
Richard Jones

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved