[Python-Dev] PEP 3144 review.

[exarkun at twistedmatrix.com]

On 11:10 am, ncoghlan at gmail.com wrote:
>Steven D'Aprano wrote:
>>I've been skimming emails in this thread, since most of them go over 
>>my
>>head and I have no current need for an ipaddress module. But one thing
>>I noticed stands out and needs commenting on:
>>
>>On Wed, 16 Sep 2009 11:05:26 am Peter Moody wrote:
>>>On Tue, Sep 15, 2009 at 6:02 PM, Eric Smith <eric at trueblade.com>
>>wrote:
>>>>I completely agree. I don't know of any situation where I'd want a
>>>>network of "192.168.1.1/24" to be anything other than an error.
>>>when you're entering the address of your nic.
>>
>>Eric is talking about a network. Peter replies by talking about an
>>address.
>
>Martin explained it better in another part of the thread:
>>if you know your address is 82.94.164.162, how do you compute
>>what you should spell for 82.94.164.162/27?
>
>Or, to put it another way, given an arbitrary host in a network (e.g.
>your own machine or the default gateway) and the netmask for that
>network, calculate the network address.
>
>With a "lax" parser on IPNetwork this is a trivial task - just create
>the network object and then retrieve the network address from it.
>
>If, on the other hand, IPNetwork demands that you already know the
>network address before allowing you to create an IPNetwork object, then
>you're pretty much out of luck - if all you have to work with are the 
>IP
>strings then this is actually a tricky calculation.
>
>If the default IPNetwork constructor was made more strict, then this
>functionality would have to be made available another way (probably as
>an alternate constructor like IPNetwork.from_host_address rather than 
>as
>a boolean 'strict' option)

This seems to be the right solution to me, particularly the use of an 
alternate constructor rather than an ambiguously named flag.

Jean-Paul