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). 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. > 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. Regards Antoine.
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