[Python-Dev] PEP 3144 review. (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Mon Sep 28 21:55:03 CEST 2009
- Previous message: [Python-Dev] PEP 3144 review.
- Next message: [Python-Dev] PEP 3144 review.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] PEP 3144 review.
- Next message: [Python-Dev] PEP 3144 review.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]