On 11:10 am, ncogh...@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 <e...@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
_______________________________________________
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
