[Python-Dev] PEP 3144 review.

[exarkun at twistedmatrix.com]

On 03:57 am, martin at v.loewis.de wrote:
>>>Finally, to Stephen's point about seeing the other side of the
>>>argument, I wrote this offlist a week ago:
>>>
>>>   I *understand* what you're saying, I *understand* that
>>>192.168.1.1/24 isn't a network,
>>
>>But you still want to treat it as one.
>>
>>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?
>
>It's fairly obvious to me why the library should support 192.168.1.1/24
>as an input, and return a network.
>
>End-users are likely going to enter such things (e.g. 
>82.94.164.162/29),
>as they will know one IP address in the network (namely, of one machine
>that they are looking at), and they will know the prefix length (more
>often, how large the network is - 8 or 16 or 32). So very clearly,
>end users should not be required to make the computation in their 
>heads.
>
>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.

And this is a rather classic example of a misfeature.  "(Non-developer) 
End users will type it in" is not argument for supporting a particular 
string format as the primary constructor for an object.  Constructors 
are for *developers*.  They should be made most useful for *developers*. 
The issue of dealing with user input (which may have many other quirks) 
is separate and should be dealt with separately.

Jean-Paul