[Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

["Martin v. Löwis"]

Guido van Rossum wrote:
> I realize I'm late to this party, but this is just a naming issue, right?

Not really (AFAIU).

> For any network, there are two special addresses, one with the last
> bits all zeros, one with the last bits all ones. We can call them A
> and B, or network and broadcast, or zeros and ones, or whatever we
> care. But their definitions are two well-defined functions for all
> networks (assuming a network is defined as an IP address and a number
> of bits), even if in an extreme case the functions return the same
> value.

For the broadcast address, it's different, since you might also use
it in programming (i.e. when sending broadcasts).

Now, it seems that people will typically use undirected broadcasts
(INADDR_BROADCAST). However, I assume there are also applications
for directed broadcasts; in this case, it would matter to know the
broadcast address of a network.

> What is actually configured on a particular host to be the broadcast
> address is a separate issue, even if *by convention* in most cases it
> is given by one of the above functions -- the network object doesn't
> care, the configuration object is something else (and outside the
> scope of this PEP).

It's a little bit stronger than convention; there are RFCs saying
that the all-ones (-1) address has to be the broadcast address.

This is like saying that it is out of scope of the socket protocol
whether TCP is the IP protocol 6, and that individual hosts may do
it differently - yes, they may, but then everything stops working.

> IMO "real life examples" don't matter for the definitions of the
> functions

That I agree with.

> and I would personally be happy to name them network and
> broadcast, since I know their definitions and their typical uses and
> these match pretty closely. The expectation should be clearly set that
> these are pure functions though and do not imply knowledge of the
> configuration of any given host.

That I also agree with.

However, there is this issue of /31 networks, where an 8-year-old
RFC specifies how to do broadcasts on these. I think RFCs should
be considered wherever applicable.

Regards,
Martin