[Python-Dev] PEP 3144 review.

Scott Dial scott+python-dev at scottdial.com
Mon Sep 28 22:19:15 CEST 2009


Martin v. Löwis wrote:
>> Martin v. Löwis <martin <at> v.loewis.de> writes:
>>>> Could you explain what benefit there is for allowing the user to create 
>>>> network objects that don't represent networks? Is there a use-case 
>>>> where these networks-that-aren't-networks are something other than a 
>>>> typo? Under what circumstances would I want to specify a network as 
>>>> 192.168.1.1/24 instead of 192.168.1.0/24?
>>>>
>> [...]
>>> So Python code has to make the computation, and it seems most natural
>>> that the IP library is the piece of code that is able to compute a
>>> network out of that input.
>> The thing is, it doesn't create a network, it creates a hybrid "network plus
>> host" which retains knowledge about the original host (that is, 192.168.1.1
>> rather than simply 192.168.1.0, if you enter "192.168.1.1/24").
>>
>> That's what the OP meant with "networks-that-aren't-networks", and that's what
>> people are objecting to.
> 
> That's not the question that was asked, though - the question asked
> was "Under what circumstances would I want to specify...". I hope
> most people agree that it is desirable to be able to specify a network
> not just by its network address.

I can't help but feel that you and many others jumping on Antoine et al.
have skipped reading or only skimmed this topic of discussion.

Antoine Pitrou wrote:
> We just need a factory function which returns a tuple after parsing:
>
>     >>> addr, net = parse_address_with_mask('192.168.1.1/24')
>     >>> addr == IPv4Address('192.168.1.1')
>     True
>     >>> net == IPv4Network('192.168.1.0/24')
>     True

I still back this suggestion. I would also support a "loose=True" flag
for the IPNetwork constructor, which would allow host bits to be non-zero.

However, I will *never* support a proposal that includes retaining the
host address. I believe I am not alone in that. However, Peter has made
it quite clear that he will *never* change that about the IPNetwork classes.

I would be quite glad to not have ipaddr included in the stdlib. As I
can only imagine code that uses it being quite confusing to maintain
(e.g., "wait is that actually a network or is that someone using
IPNetwork to be an IPAddressWithMask?").

-1.

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu


More information about the Python-Dev mailing list