Python 1.6 alpha 1 released
Russell E. Owen
owen at astroNOJNK.washington.edu.invalid
Tue Apr 4 21:37:07 CEST 2000
>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
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.
More information about the Python-list