Python 1.6 alpha 1 released

Tres Seaver tseaver at starbase.neosoft.com
Tue Apr 4 06:58:49 CEST 2000


In article <Pine.GSO.4.10.10004040035420.21084-100000 at sundial>,
Moshe Zadka  <mzadka at geocities.com> 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:
><snipped>
>
>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
doubt.

Rough-consensus-and-running-code-wins-every-time'ly

Tres.
-- 
---------------------------------------------------------------
Tres Seaver        tseaver at digicool.com     http://www.zope.org
Digital Creations



More information about the Python-list mailing list