Python 1.6 alpha 1 released

[Tres Seaver]

In article <8cdig3$s7f$1 at slb6.atl.mindspring.net>,
Aahz Maruch <aahz at netcom.com> wrote:
>In article <8cdg92$j0m$1 at nntp6.u.washington.edu>,
>Russell E. Owen <owen at astroNOJNK.washington.edu.invalid> wrote:
>>
>>But tuples seem a less than wonderful choice to me. Protocol flexibility 
>>presumably requires each protocol to have its own tuple with its own 
>>numer of fields in its own order. That's a lot to remember and try not 
>>to get mixed up.
>
>I second this.  I'd be happy with either dict or class, with a *slight*
>preference for a class.

I'd be quite happy with a set of address classes -- they could *add value*
in lots of ways that the tuple can't.  For instance, consider IPv6 dual-
mode issues -- an IPAddress object could know how to render itself
appropriately in either mode.  

Hmm, new proposal (for the Py3K timeframe):

Make class socket.socket into an abstract interface, and socket.socket()
into a factory which produces an appropriate derived instance, based on
family, type, and proto.  The derived type would then automatically know
how to interpret the *args to connect(), bind(), etc., and Do the Right
Thing [TM].

Such a scheme would make adding new families/types/protocols a matter of
plugging callables into the lookup table used by socket.socket(), and could
be therefore done in entirely separate modules (SOCK_RAW, anyone? or
AF_INET6/AF_IRDA?)

Why-propose-a-small-incompatible-change-when-BIG-ones-abound?'ly

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