On 03:57 am, mar...@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
_______________________________________________
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
