>> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
