[Python-Dev] PEP 3144 review.
steve at pearwood.info
Mon Sep 28 02:13:38 CEST 2009
On Mon, 28 Sep 2009 03:53:27 am Peter Moody wrote:
> >> 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?
> this is pretty ridiculous. if in the last two months you haven't seen
> a single use case, then you haven't been paying attention.
No, I haven't read every single email in excruciating detail in this
extremely long thread. I'd bet most other people haven't.
I'm trying to understand why you want something which, in *my*
ignorance, seems patently ridiculous to me: allowing Network objects
which aren't Networks, particularly since in private email to me you
denied that there was a use-case for the requested (Address object +
netmask). But it seems to me that this is exactly what you have in the
current implementation, except you call it a Network object, and have
rejected the suggestion that the non-network bits of the address should
That is, you've rejected the idea of having:
as reducing functionality, presumably because the address 192.168.1.1 is
lost. Sounds just like an Address+netmask to me, with added
Some people have requested a way of explicitly calculating a network
from an Address and netmask, and you've been hostile to the idea. But
it seems to me that your API does exactly that.
I'm not the only person who thinks your API conflates two different
concepts into a single class, and I'm trying to see your side of the
argument. But your hostile attitude isn't making it easy.
More information about the Python-Dev