On 11:10 am, ncoghlan@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@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