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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4