Python 1.6 alpha 1 released

[Russell E. Owen]

>The argument that the address object is spurious doesn't hold water.
>There are many places where it is convenient to hold an address in a
>single variable, and a tuple is the obvious way to represent this.
>(The alternative, a "host:port" string, seems too Perlish to me.)
>Note also that recvfrom() returns the address as a tuple (if it is an
>IP address) and sendto() requires the address to be passed as a tuple
>-- the canonical form of an address is clearly a tuple.

I was following along happily until now, but just got a bit lost.

I completely agree with you that:
- Holding an address in a single variable is a Good Thing
- It pays to support protocols other than IP
- A "host:port:" string would be dreadful

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.

The lightest weight alternative I can think of is a dictionary. Each 
protocol would require its own dictionary, but at least they are fairly 
self-documenting once they exist. (And presumably one could get some 
class or other to create a suitable dictionary for a particular 
protocol).

Another alternative is a hierarchy of classes: a network address base 
class with a subclass for each protocol. This could easily get 
heavyweight and clumsy, but I'm not convinced it needs to do so. Imagine 
connection calls that accept appropriate arguments (like file open 
calls) with named arguments (or dictionaries or tuples) and return an 
instance of the network class to be passed around for later calls.

Regards,

-- Russell