On Tue, 15 Sep 2009 at 19:20, Antoine Pitrou wrote:
R. David Murray <rdmurray <at> bitdance.com> writes:
I would find that acceptable but sub-optimal. Most of my use cases
(which involve manipulating router and firewall configuration files) would
then start by making a little class named AddressWithNetwork to hold the
tuple returned by your parse function, with attributes 'ip' and 'network'
and a representation that included the netmask.
If the AddressWithNetwork class has useful functionality of its own, then why
not (although I think that conceptually, this functionality should belong to the
Network class instead).
But it's not a network. It's an address that is explicitly associated
with a network.
It's useful functionality is parsing/validating an address+mask, rendering
as address+mask, and being able to get the associated IP and network objects
from it. It's a small class, but useful, IMO.
If, however, the AddressWithNetwork class is only a recipient for a tuple, then
it sounds useless. It's like having an AddressWithPort to hold things like
"127.0.0.1:8080". Building little featureless recipients like that isn't really
idiomatic Python, IMO.
I could see myself doing that, too, though I haven't had a reason to yet :)
Although I'd probably call it 'IPv4EndPoint' or some such, since it would
be representing one endpoint of a traffic flow...
An IPv4Address with 'network' and 'mask' attributes that could be
None would also not complicate the API, IMO, and would handle both
of these use cases.
But it would be confusing and conceptually bizarre, because an address (in
usually accepted terminology) doesn't have a network and a mask.
I think we should keep the API clean and reasonably logical, rather than try to
cover all use cases at the expense of weird shortcuts.
OK. I'll withdrawal that suggestion.
If AddressWithMask doesn't get added I won't be heartbroken; it is easy
enough to write in the programs where I need it (at least it would be
if the parsing/validation is in the library). However, I do not think
that the proposed API should accept, eg, IPv4Network('192.168.1.1/24')
as valid. That's just too confusing and error prone.
Oh, and if people don't like 'zero' as the name for the IPv4Address
at the beginning of the network IP range, how about 'network_ip' or
'network_address' instead of just network, to make it clearer that it
is an address?
--David
_______________________________________________
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
