> > 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 | ncogh...@gmail.com | Brisbane, Australia > --------------------------------------------------------------- > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/drkjam%40gmail.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
