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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4