[Python-Dev] PEP 3144 review.

[R. David Murray]

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