Andrew McNamara writes:
> As the module stands, we have a pair of address-without-mask classes
> called *Address, and a pair of address-with-mask classes called
> *Network. So, sometimes when you want to record an *address* you use
> a class called Network, and that class comes with a behaviours that
> make no sense in the context of a singleton network end-point (it can't
> "contain" other addresses, although it's .network can).
I'm going to consistently use "address" to mean a singleton and
"network" to mean a container in the following.
I still don't see why an address-with-mask is useful, except that the
network is deducible as {'network': address & mask, 'mask': mask}. Is
there *any* other way you would *ever* use that?
It seems to me that for some purposes (implementing dig(1), for
example), an IPv4Address can contain only the address (ie, a 32-bit
integer) as a data attribute, and (with methods for using that
attribute) that is the minimal implementation of IPv4Address.
However, there are other cases (eg, routing) where it's useful to
associate an address with its network, and I don't see much harm in
doing so by adding a 'network' attribute to the base class
IPv4Address, since addresses are hardly useful except in the context
of networks. Of course that attribute is often going to be None (eg,
in implementing dig(1) the remote nameserver is unlikely to tell you
the netmask). However, when iterating over an IPv4Network, the
iterator can automatically fill in the 'network' attribute, and that's
fairly cheap.
While to me neither the 'network' attribute nor the iterator behavior
just described seems amazing useful in the base classes, it seems to
me that precisely those behaviors will be reinvented over and over
again for derived classes. Furthermore they are natural enough that
they won't bother people who don't need them. (That's despite at
least one person (IIRC it was Antoine) firmly saying "an IPv4Address
should contain exactly one 32-bit int, no more, no less", so I could
be wrong.) It seems to me that the only good reason for not having a
'network' attribute that contains an IPv4Network instance or None is
efficiency: the space for the attribute and the overhead of filling it
in the iterator. I personally can't think of an application that
would care (from what I hear, Cisco has no interest in writing its
routers' IP stacks in Python, amazingly enough), but in theory ...
Finally, I agree that using IPv4Network as address-with-mask is a
confusing, undiscoverable abuse. In particular, I think that every
time I went a week without using that idiom, I'd get nervous when I
saw it again: "Are you *sure* that won't raise an error or silently
get the lower bits masked off?! If not now, in the next version?"
Obviously all the above applies to IPv6 classes, too.
_______________________________________________
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
