[Python-Dev] Fwd: PEP 3144 review.

[DrKJam]

>
> Antoine Pitrou wrote:
> > Peter Moody <peter <at> hda3.com> writes:
> >> the address with all of the hosts bits masked to zero is most commonly
> >> referred to as the network address. same as the address with all of
> >> the host bits set to one is called the broadcast address. calling it
> >> something like base_address or min_address will cause quite a bit more
> >> confusion.
> >
> > Quite a bit less IMO. I'm not a network specialist, but the "network
> address"
>
> Nah, network address is perfectly explicit - it's what you get when you
> bitwise and any host within that network with the netmask.
>
> Where it becomes confusing is that we have a property called "network"
> that returns an IPAddress object rather than an IPNetwork object.
>
> People that are network specialists would grasp that fairly easily, but
> we try to design standard library APIs so that they're novice friendly
> as well. And the above situation isn't novice friendly.
>
> To be honest, given the indexing behaviour, I'm -1 on the idea of giving
> the network address or broadcast address attribute names *at all*.
> Consider:
>
>  network_address = my_net[0]
>  broadcast_address = my_net[-1]
>
> The only way the network address could match the number of characters in
> the indexing method is if you just called it the network id (i.e.
> my_net.id). For the broadcast address, there is no name that even comes
> close to matching the indexing approach for brevity.
>
> And since IPNetwork is a container for IPAddress instances, the indexing
> approach means there is zero ambiguity regarding the return type.
>
> -1 from me. I'm happy to see indexing made available alongside specific
properties/methods that expose the network (without mask) and broadcast
addresses for a given network object, but not to remove them from the
interface entirely in favour of indexing alone.

While it seems like a good idea, in practice it just won't work or will at
least be sub-optimal and violates the rule of least surprise (for IP
libraries anyway). I struggled along with this approach in several early
versions of netaddr but had to cave in to pressure from users after repeated
questions about where to find the broadcast and network (without mask)
addresses!

Granted, there are decisions to be made about exactly what the
properties/methods should be named to avoid ambiguity, but they are
important enough to be given access to in their own right. Details in
docstrings help too ;-) 'network' and 'broadcast' are very much the
convention used pretty much everywhere (including libraries found in other
languages such as Ruby and Perl).

IPv6 doesn't support the notion of a broadcast address as part of a CIDR
network block at all. AFAIK, it is a perfect legitimate for the last address
in an IPv6 block to be used to configure a network interface. The IPv6
network object interface should possibly leave out the broadcast
property/method altogether although there are reasons to keep it in for the
sake of completeness and API consistency. The pros and cons of this need to
be considered.

BTW, has anyone considered use of the term *CIDR to refer to an address +
mask object? It would certainly be less controversial than *Network which
already has too many overlapping meanings elsewhere in the interface?
Obviously we'd still have the issue of what to do with the host bits to the
right of the supplied mask (keep or discard). This is not a clear cut choice
of one or the other as it is entirely based on context. For configuring
routes, you would likely always want to discard these bits (or at least
Cisco does when adding routes). For configuring a network interface you
would most certainly want to keep them!


> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> ---------------------------------------------------------------
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/drkjam%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090917/8f65edc7/attachment.htm>