>Another way to approach this would be for the Address object to >potentially have a 'network' attribute referencing a Network object. Yes - that's reasonable. >Then there are only two classes, but three use cases are covered: > >1) a Network > >2) a plain, network-agnostic Address with network == None > >3) an Address with an attached Network > >An Address could be constructed in three ways: > > Address(ip_number) > > Address(ip_number, network = <Network instance>) > > Address(ip_number, mask = <mask>) > # constructs and attaches a suitably-masked Network instance I think you still need to support the common notations: Address('10.0.0.1') # .network == None Address('10.0.0.1/255.255.255.0') Address('10.0.0.1/24') >We could also have some_network[n] return an Address >referring back to the network object it was obtained >from. Yes. (Of course, we're simplifying - there would really be classes for each protocol). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/
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