[Python-Dev] PEP 3144 review.

[Nick Coghlan]

Peter Moody wrote:
> Steven D'Aprano wrote:
> 
>   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?
> 
> that pretty flatly states that my use case is invalid.

Looks like Steven was asking you to explain your use case to him rather
than stating that it didn't exist. (although I will grant that the
network definition use case had been well covered, I will also grant
that these threads have been somewhat interminable and I can easily
understand someone missing those use case definitions - the example of
being able to define a network given only the network mask and the IP
address of the host running the current application should be mentioned
explicitly in the PEP)

>> 1) if strict=False, mask off the bits described by the netmask when creating
>> an IPNetwork, such that the host bits are always 0.
> 
> I haven't heard anyone suggest auto-masking bits, but otherwise that
> would be strict=True.

Actually, that's exactly what I suggested in this thread - that
IPNetwork should lose the "ip" property and that the definition of
"network equality" should be based on the network address not on the
host address that happened to be used when constructing the network object.

The part that is confusing with the current library implementation is
the fact that we can have two IPNetwork objects, supposedly describing
the same network, compare unequal because they happened to be defined
differently. It would be analagous to having "Decimal('3.0') !=
Decimal('3.00')".

>> 2) add a single new function:
>>
>> def parse_net_and_addr(s):
>>  return (IPNetwork(s), IPAddress(s.split('/')[0]))
> 
> I've only heard talk of new classes and new methods, not new
> constructor functions. In fact, when I asked for explicit
> clarification of what was required, a new constructor function "ala
> IPAddress and IPNetwork (so the current classes remain largely the
> same and the various constructors enforce certain restrictions)", I
> was told, no, a new object AddressWithMask was actually required. I've
> no problem with a constructor like this, but this is not what people
> have been asking for.

No, AddressWithMask was merely defined as a concept separate from an IP
Network to indicate how the current IPNetwork class was being overloaded
with two distinct concepts and hence exhibiting unnecessary behavioural
quirks.

The use case for "given a netmask and an arbitrary host on that network,
give me the appropriate IPNetwork object" has been well established by
this discussion (although still isn't particularly well described even
in the latest PEP update). This is what "strict=False" covers, and I'm
now happy that practicality means this is appropriate default behaviour
for the IPNetwork constructor.

The use case for "create an IPNetwork object and have it *remember*
which particular host address was used to define it" is still not
established at all.

It is this latter use case which is covered by the AddressWithMask
concept (which may be perfectly validly represented as a simple
IPNetwork/IPAddress tuple, which was also mentioned when the concern was
first raised).

The main concern here is to take the "AddressWithMask" behaviour *off*
the IPNetwork objects. It interferes with their interpretation as
descriptions of networks because they maintain a piece of irrelevant
state and pay attention to it in comparison operations.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------