Python 1.6 alpha 1 released

Tres Seaver tseaver at
Tue Apr 4 00:58:49 EDT 2000

In article <Pine.GSO.4.10.10004040035420.21084-100000 at sundial>,
Moshe Zadka  <mzadka at> wrote:
>On 3 Apr 2000, John Aycock wrote:
>> I'm not going to take sides here, but I coincidentally just finished
>> reading something highly relevant:
>I beg to differ: it's not highly relevant. What Guido did was correct
>a *bug* in the implementation. That people depended on it is sad, and
>just goes to show it should be corrected ASAP before more people depend
>on it.

The point of this debate is that classifying it as a *bug* is, well,
debateable.  Years of socket programming experience makes:

  s.connect( host, port )

seem like a perfectly reasonable, sane interface;  disallowing it
may preserve "orthagonality," or some other academic purity, but
it *breaks existing applications coded to the published interface*,
with no appreciable real-world benefit (yes, I realize that the published
interface is inconsistent;  I do not accept the deprecation of the
examples as a reasonable argument.)  Consider that *every one* of the
protocol modules which offers a connect() method uses a two-argument
signature for it:  ftplib, gopherlib, httplib, imaplib, nntplib, poplib,
smtplib, telnetlib, urllib.  And they all *use* the two-argument connect
when invoking their underlying socket!  No Python module in the standard
library uses the single-argument connect, period.

This is *not* the same case as the list.append() one, where the
published interface was itself consistent -- I was quite surprised to
learn just this spring that multi-argument append was even possible.
But the socket module is one of the first I learned in Python, and I
have consistenly used the two-argument connect.  Constructing a spurious
"address" object (which has no behavior, and exists only to be torn
apart inside the implementation) seems a foolish consistency, beyond


Tres Seaver        tseaver at
Digital Creations

More information about the Python-list mailing list