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
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