Peter Moody wrote:
On Wed, Aug 19, 2009 at 9:21 AM, R. David Murray<rdmur...@bitdance.com> wrote:
Possibly. Tino means exactly what he said: the broadcast address
does not _have_ to be the last IP, nor does the last IP _have_ to be
a broadcast, though in practice they almost always are (and using the
last IP as a host IP almost never works in practice in a heterogeneous
network). Check out the 'broadcast' option of the ifconfig command for
confirmation that the broadcast address can be any IP in the network.
Of course, for that to work all hosts on the network have to agree on
what the broadcast is, hence the normal convention that the broadcast
is the last IP in the network.
As for the 'network' attribute, if you call it 'network' IMO it should
be a network data type, which would make it rather redundant. What you
are actually returning is what I have normally heard called either the
'zero' of the network, or the "network number" or "network identifier";
but never just "network" (a network has to have at least an implicit
netmask to be meaningful, IMO).
Since you are dealing with networks as a list of addresses, perhaps
you should drop the 'network' attribute, make the 'broadcast' attribute
settable with a default equal to self[-1], and let the user refer to
the zero element to get the zero of the network if they want it.
making the broadcast address settable (with a default to self[-1])
might be reasonable, though it is different from just about every
other python implementation I've seen (IPy, ipv4.py, netaddr).
I'm not sure I understand your point about the network attribute.
what I'm returning with network is the subnet-id/base address of the
given network. Again, .network seems to be fairly standard for naming.
I think using .network and .broadcast are pretty well understood to be
the [0] and [-1] of the network address block. I don't think we want to
start creating new terms or access patterns here.
+1 on leaving .network and .broadcast as-is (including returning a
IPvXAddress object).
Eric.
_______________________________________________
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
