A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2009-September/091799.html below:

[Python-Dev] PEP 3144 review.

[Python-Dev] PEP 3144 review. [Python-Dev] PEP 3144 review.Andrew McNamara andrewm at object-craft.com.au
Thu Sep 17 05:27:43 CEST 2009
>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/
More information about the Python-Dev mailing list

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