Python 1.6 alpha 1 released

Tres Seaver tseaver at starbase.neosoft.com
Tue Apr 4 09:08:12 EDT 2000


In article <8cca93$9oh$1 at nnrp1.deja.com>,  <fredrik at pythonware.com> wrote:
>Tres Seaver wrote:
>> > it *breaks existing applications coded to the published interface*,
>
>not true.  the documented interface explicitly says that
>there is one single argument.  it does not mention optional
>arguments.

Your insistence that the "documented interface" consists only of the
description in the module reference, and not of the example on the next
page or of the way the API is actually used in the standard libraries
baffles me.

>
>(the example was broken, but so were other examples in earlier
>releases of the documentation.  see other messages in this
>thread for details)
>
>> 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!
>
>not true.  look again (doesn't matter if you look in the 1.5.2
>library or the 1.6 library -- what you just said is not correct
>in either case).

I just did, see below.  The only error I can see is that I falsely lumped
imaplib with the others as *exposing* a two-argument connect(), when in fact
it merely *uses* two-argument connect().

>
>> No Python module in the standard library uses the single-argument
>> connect, period.
>
>*all* python modules in the 1.6 standard library use
>single-argument socket connect.

Invalid argument -- nobody depends on the 1.6 library yet.

Here is a check from my (unfiddled) Python distro -- its the same on Windows,
too:

[/home/tres] $ python
Python 1.5.2 (#1, Sep 17 1999, 20:15:36)  [GCC egcs-2.91.66 19990314/Linux (egcs
- on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> ^D
[/home/tres] $ cd /usr/lib/python1.5
[/usr/lib/python1.5] $ grep "connect(" *.py
asyncore.py:            self.handle_connect()
asyncore.py:                    self.handle_connect()
asyncore.py:                    self.handle_connect()
ftplib.py:      Then use self.connect() with optional host and port argument.
ftplib.py:      # Optional arguments are host (for connect()),
ftplib.py:                      resp = self.connect(host)
ftplib.py:      def connect(self, host = '', port = 0):
ftplib.py:              self.sock.connect(self.host, self.port)
ftplib.py:              (this is read and squirreled away by connect())'''
ftplib.py:                      conn.connect(host, port)
gopherlib.py:   s.connect(host, port)
httplib.py:        if host: self.connect(host, port)
httplib.py:    def connect(self, host, port = 0):
httplib.py:        self.sock.connect(host, port)
httplib.py:    h.connect(host)
imaplib.py:             self.sock.connect(self.host, self.port)
nntplib.py:             self.sock.connect(self.host, self.port)
poplib.py:              self.sock.connect(self.host, self.port)
smtplib.py:            (code, msg) = self.connect(host, port)
smtplib.py:    def connect(self, host='localhost', port = 0):
smtplib.py:        self.sock.connect(host, port)
smtplib.py:            raise SMTPServerDisconnected('please run connect() first'
)
telnetlib.py:        self.sock.connect((self.host, self.port))
urllib.py:        self.ftp.connect(self.host, self.port)


The CVS log comment for the checkin you just made *six days ago* to
smtplib says:

  This fixes a bunch of socket.connect(host, post) calls.  Note that I
  haven't tested all modules -- I don't have enough servers here...

So don't tell me that the 1.5.2 library used one-argument connect().

>
>> This is *not* the same case as the list.append() one, where the
>> published interface was itself consistent.
>
>why not?  after all, there were many more uses of multi-argument
>append in the 1.5.2 standard library than uses of multi-argument
>socket calls.
>
>see my other post in this thread for the list of questions
>I ask myself for each change in Python.  if you use other
>criteria, which make it obvious to you that "append" is a
>good change, and "connect" is a bad one, please tell me what
>they are.
>
>(bogus facts or double standards doesn't count).
>
>after all, with tons of code all over the Python universe,
>I'm affected by *all* backwards incompatible changes in
>Python 1.6.  but for some reason, the "append" change is
>the only one that makes me worried.  what am I missing?

The append() change is hard to find, but fixes something that shouldn't work.
The connect() change could be equally hard to find (although I grant that the
call-through-a-differently-named-bound-pointer bit is much less likely)
but fixes something which *isn't* broken, *for no reason*.

In fact, I think one could make a reasonable case that the real bug here
is in the API doc:  single-argument connect() is unintuitive for AF_INET
sockets, and exists primarily to shoehorn orthagonality with AF_UNIX ones
(where a default port argument would do just as well.)

Still-haven't-seen-a-reasonable-defense-of-one-argument-connect()'ly,

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



More information about the Python-list mailing list