[Python-Dev] PEP 3144 review. (original) (raw)

R. David Murray rdmurray at bitdance.com
Tue Sep 15 21:48:07 CEST 2009

On Tue, 15 Sep 2009 at 19:20, Antoine Pitrou wrote:

R. David Murray <rdmurray 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

More information about the Python-Dev mailing list