Home Original page

[Python-Dev] PEP 3144 review.

"Martin v. Löwis" martin at v.loewis.de
Mon Sep 28 21:55:03 CEST 2009 
>> 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.

Still, people proposing that 192.168.1.1/24 should be rejected (I still
don't know whether anybody is actually proposing that) *have* to provide
a proposal how this should be input instead. Otherwise, such proposals
must be rejected, since there is a clear and evident need to support
such input somehow.

Regards,
Martin
More information about the Python-Dev mailing list