>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/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
